Category: Management

agile, BDD, Management, Specslist, Talent

Salary structure in an agency

Perks and benefits that save employees money in the long run are always a valuable addition to a paycheck. Addition being the keyword here.

Because no amount of pizza parties can supplement the 10% increase in salary that people could get at the other agency across the street. Except, that’s not the case, the statistics surrounding this, point in the exact opposite direction:

  • 32% of people polled in the US would take a 10% pay cut to work at a company where they like the culture
  • 58% of workers will stay at a lower-paying job if it means having a great boss
  • And 60% of workers would even take half of the potential paycheck if it meant working at a job they love

So if culture makes up for the differences in salary between your agency and the agency next door, how do you structure the salaries in your company to both attract and retain top talent?

  • Don’t buy stars, build them – Have a partnership with the local media and technical schools that provides internships and part-time positions for promising students. If you follow our onboarding tips and you build a functional onboarding program, after a couple of weeks, your time investment in onboarding them should already be paying you back. And in a few months? You might just have your hands on your newest superstar.
  • Have a clear progression path – be upfront and transparent with the salary structure. It will eventually become the biggest motivator for the employees in the lower tiers. If you split your progression path into layers where everyone gets paid the same, you can skip long management discussions like: ’’Is a Senior Backend Developer with 4 years of experience worth the same as a Senior Art Director with 5?’’ An example of how to structure your progression path could be:
  1. Intern > unpaid, but gaining real-life skills and experience from an agency by working on real projects
  2. Trainee > paid, part-time or full time; self-taught, certified or freshly graduated
  3. Apprentice > Same credentials as a trainee, but with some successful commercial projects
  4. Junior > Proven 1-3 years of experience with commercial projects
  5. Senior > 3+ years of experience with commercial projects and proficientwith project management and delegating tasks
  6. Management > If you’re doing linear progression, this step is simple. But if you want to do non-linear progression, it’s worth differentiating at management level. a. Senior members with multiple specializations and experience with managing teams b. Senior members with extra non-managerial responsibilities (product development, decision making, etc.)
  7. Equity tier > Management whose investment with the company is substantial enough to warrant equity in the company
  • Promotions, raises and employees who feel undervalued – if you adopt the aforementioned salary structure, your employees should have a clear overview of where they fall and what they need to achieve to move up to the next salary level. But as it goes with highly ambitious people, you will always have individuals who take on more than their fair share of responsibility and then don’t feel adequately compensated. The answer should be obvious. If the employee performs above the set expectations, has the data to back it up, and asks for an increase in pay, they should get one. Sadly, when working with more than one person, it will never be that easy. Ben Horowitz summed it up the best in his class on Y combinator – how to start a startup.

A point he brings up is: If you give that employee a raise, will you give everyone else who is also performing well a raise as well? What about the employees who are performing just as well, but their personality prevents them from asking directly?

Apart from being approachable overall, managers and senior agency members can adopt these two methods to focus these conversations and help employees feel more valued and heard:

1. Monthly walk and talk:A manager and employee go for a half-hour walk outside of the office, talking about current projects, plans for future projects, the progress of the employee and any problems they might be having

2. Yearly progress conversation: Performance reviews are usually seen as a negative process because of the negative associations that people usually have with them. Walk and talks remove the need for quarterly performance reviews at a scary meeting room table.

But a walk and talk is not really the place to sign contracts and obsess over spreadsheets. So how about a yearly progress review, close to the end of the year, talking strictly about the employee’s progression path and salary?

That way, both current problems can be addressed from month to month, and larger issues or achievements can be accumulated over time.

agile, BDD, Management, Specslist, Talent

Non-linear progression

When hearing the words ’’non-linear’’, if your mind immediately jumps towards video games, you already sort of get the point.

In a non-linear game progression system, you start at the same spot as every other player. But when you arrive at a crossroads, instead of going straight down the first path like you usually would, you get to choose if you want to go left, right, or even take a step back and see if you can get to your current position again, by taking another path. This progression helps you pick up new skills and new experiences that will make the path ahead much easier.

This is also how the current trend in career progression looks. Companies no longer expect people to stay in the same career path for decades, slowly working their way up the corporate ladder. This rings especially true for agencies, where skills from different career paths transfer almost seamlessly and complement each other with a broader outlook on the problems being solved.

As an example, if you have a frontend developer who discovered she likes designing more than she likes coding, you should give her a chance because:

  • She already knows the limitations that code can have on some designs
  • She can design with systems and reusable assets in mind
  • She can give better estimates on project length and the overall development time
  • If she wants to progress further into something like art direction, the added coding skills are always a plus when communicating to both clients and developers alike

If your agency has people who have invested in their craft to the point where they are considered experts, top talent, or masters, their progression will eventually hit a plateau.

And while just existing at the top and using your skills to their full potential is a fantastic feeling… ultimately, the need for self-improvement and innovation that got them to the top of the talent pool will make them want to progress further. But you can’t really go further up than the top, so where do you go?

This is where people start considering switching jobs or pursuing entrepreneurship because it seems like the only challenging way forward.

The classic solution to this “problem” is to promote them to the management level. Clearly, if someone is performing exceptionally well as a specialist they will automatically become an exceptional manager… Right?

The solution is not always that simple and pushing someone to become a manager (or a manager of a bigger team than before) is not for everyone. Some top talent enjoy being a specialist and would rather spend their time performing their tasks, than managing a team.

“In a hierarchy, every employee tends to rise to his level of incompetence.”

– Laurence J. Peter, Author of The Peter Principle

The previous quote refers to what is known as the Peter principle, a concept of management developed by Laurence J. Peter. The principle suggests that people tend to get promoted outside of their skillset and competence, based on previous success.

Meaning: Your best front-end developer is first and foremost… a front-
end developer. Having 10 award-winning projects under his belt does not make him an instant candidate for managing the next project. That requires knowledge of front-end and an additional management skill set, lack of which could lead to disaster down the line.

The modern solution to the problem is working with non-linear progression and promotion. Instead of the career path only going one way – towards management – you can set an alternative path. This could be anything from giving your top talent more influence on projects or a seat at the table when tough decisions are made to simply giving more freedom to perform tasks their own way. Once you start thinking outside the box you’ll be amazed at the possibilities there are for non-linear progression.

And the result?
Happier top talent that gets a truly unique position at your agency, which they won’t be able to find anywhere else.

At SQAEB, most of our junior employees start out in the SWAT department, helping our users with day to day issues. This helps them naturally and quickly get an overview of all the other departments, the products, and how everything fits together. Later they can choose to transition into newly opened positions in the company that they find interesting or get places in completely new positions based on their specializations.

BDD, Management, Specslist, Talent

Are you having any fun?

Fun is a fickle thing. Everyone inherently knows what fun is, but if you had to define fun at the workplace, it would not be as easy as it first sounds. Looking up the definition of fun will also get you reprimanded by the dictionary, and there is no one sure way to define it. The only sure thing is that if the most interesting thing at the office on the first day is the photocopier, the new employee getting the tour will probably start looking for another job during the lunch break.

The overall feeling of fun at the workplace impacts productivity. And so it’s
a topic without any specific bullet points, but a topic to think about and discuss nonetheless.
If you want to have fun at the workplace but can’t manage to play chess
on one screen while maintaining your focus on coding… or your keyboard shortcut hand is also your balloon tying and juggling hand… you will probably need to interact with other people eventually. But there is only a limited level of friendship and camaraderie that you can build with people when talking about code and sending each other design files.

When was the last time someone asked a different water cooler question than: ’’So, how was the weekend/any plans for the weekend?’’ In most agencies, it has probably been a while. And that’s expected. If you work in a consistent and focused environment, there are only so many topics that can come to mind.

But if you change up the setting, if you do different activities together, you might build more than just classic coworker bonds. You might build friendships. And what could be nicer than looking forward to Monday morning at the office to see your friends?

But not everyone comes to work looking for friendship. Especially top performers who just want to put on their headphones and forget that they are in an office environment.

Sadly headphones run out of battery, the wifi goes down, and progress meetings exist. Eventually, even the most focused people have to talk to their coworkers. And since you spend most of your day at work, people would prefer to cut down on the dry, corporate jargon and instead discuss or do something… fun.

This again brings us to the topic of shared values. The job of a back-end developer and the job of a UX designer require different personalities. So if your agency wants to have a varied offering of skills and backgrounds, you will have to find values that connect with every group.

But not just the ’’standard’’ values that are put on the agency “about us” page. The values that make up the constantly evolving personality of your agency. If you do this, you will eventually have an agency full of like minded individuals that don’t need to act corporate 24/7 and might even joke around from time to time.

Sadly, there is a thin line between having fun at the workplace and being overly quirky and disrupting everyone’s work. Unfortunately, you can also never get full value-alignment with every person that has been hired. But an agency where people think of each other as nothing more than colleagues and only spend time together at work is an agency that will have trouble scaling and keeping up with the more friendly teams later on.

Your culture and environment both have an impact on the quality of your work.

agile, BDD, Management, Specslist, Talent

Talent Investment

You have to spend money to make money. And you have to invest in top talent to retain top talent. Achieving maximum focus in an office setting where a million things are gunning for your attention is tough.

All of that can be managed with a good work culture and processes. But if you don’t have the right equipment and tools, you’ll never be as efficient as you could be.

Maybe a chair is not comfortable. Maybe you can still hear your sales team in the other room, even with your headphones on. Maybe you found a SaaS tool that would save you hours upon hours of repetitive tasks.

If someone asks for a new keyboard, new tool, or new screen, it’s never a good idea to dismiss them right away. The person asking rarely brings up an issue like this on a whim, it has to be premeditated in some way, and that means that the problem they are facing is a recurring one.

“The way management treats
their associates is exactly how the associates will treat the customers.”

– Sam Walton, Founder of Walmart

A one-time investment, no matter how large, is actually pretty small when looking at it as a long term investment in focus and productivity. If an agency shows that it cares about its employees in all the ways that matter, the employees will return it multiple times over. Here are some small or large things in no particular order that could make or break an employee relationship with the company:

  • IT equipment. If you ask someone to work in front of a computer 8 hours each day, you better make sure they have the proper equipment to do their job. This includes everything from computer equipment to noise- cancelling headphones and online tools to do their job.
  • Chair and desk. This one is connected to the one above; spending a third of their day in uncomfortable working conditions will severely hurt their productivity and health.
  • Coffee, refreshments and snacks. We know it might not sound like much, but making sure that your employees have access to all the basics like coffee, cold water (or soda) and some fruit can drastically increase their productivity and improve health.
  • Indoor climate. The stereotype of a developer might be: someone sitting in a dark basement with a hoodie on – but nothing could be further from the truth if you want them to be productive. Proper lighting, some plants and good ventilation are all tiny details that have a huge impact.
agile, BDD, Management, Specslist, Talent

Talent Professional growth

A promotion: While most talented people love what they do, as they repeat the same tasks day after day, eventually, they will find ways of improving the process or get ideas for new ventures that the team should pursue. And there is only so much one can do from the bottom of the corporate ladder. Career growth is a key part of goal setting strategies for high performersand agencies need to provide these opportunities if they want to retain their top talent. Otherwise those people might look for those higher positions elsewhere. Please note, that a “regular” promotion is not always the best option; we’ll cover that later in our post “Non-linear progression”.

A raise: Usually going hand in hand with a promotion. However, while every promotion should come with a raise, not every raise has to come with a promotion. Many people are not after the responsibility that comes with
a promotion, they just like what they do, and so they take on more tasks, spend more time at the office or even work weekends. But maybe they aren’t looking to delegate their tasks to their would-be replacements. Maybe they just want to feel like their extra time is seen as valuable by the agency. And seeing as time is money, sometimes the answer is as simple as that.

While all of the above will probably make your agency employees happy and get your agency valuable, educated and dedicated employees for a long time
to come, there are also smaller ways to improve productivity faster.

agile, BDD, Management, Specslist, Talent

Talent Personal growth

Courses and conferences: There are always new books and courses popping up, covering the latest and greatest developments in the industry.

If your top performers ask about you helping fund their education, it’s one of the best ways to show them that you are counting on them in the future.

Maybe there is a developer conference coming up that would help them meet some like minded people and gather industry knowledge?

While it may seem like a big investment to send one or multiple developers away for a few days, the new knowledge and energy they bring back will pay dividends now as well as in the future. If they have valid arguments for going, why not give it a shot?

Schools and degrees: A similar approach to the one about courses and conferences, to an even higher degree (forgive the pun), should be taken if an employee asks about the possibility of returning to school.

Maybe they got this job straight after finishing their bachelor’s degree. Maybe they want to go for a manager position and think that an MBA would greatly improve their outlook.

Or maybe they want to slowly transition to another position, but wish to stay at the agency. Customer lifetime value and return on investment are some of the most important metrics that agencies need to keep an eye out. But try
to imagine the “employee lifetime value”, of someone who you helped put through school.

agile, BDD, Management, Specslist, Talent

Personal and professional growth

Every movie about an office work environment has managed to, in one way or another, demonize the monotony of sitting at a cubicle doing the same work every single day. And who can blame them? Doing the same thing over and over again is widely referred to as the definition of insanity.

No one wants to feel like they aren’t progressing in their job. And this rings especially true when we are talking about top talent. If someone wants
to stay at the top (where you probably want to keep them), they need to continually have an eye on the newest developments in their field.

The information gathering and processing is on them – allowing for an environment where they can test new ideas, that’s on the agency.

There are many ways to help talented employees fuel their passion for their work. Every person is looking for something different, but we have a few ideas that should be universally interesting for most people.

agile, BDD, Management, Specslist, Talent

Is ’’When and Where’’ Important?

Allowing for a full five-day remote work schedule is not something that can be implemented instantly, it’s something that agencies have to build towards over time.

For a large portion of agencies, a full week of remote work might not even make sense at all. But giving people the freedom to work from home as needed on special occasions can remove a lot of unnecessary stress. If a person needs to take care of some errands, look after the kids, or maybe they are not feeling well enough to drive to the office, but well enough to work, why not have the option of working from home?

Let’s say you have a single developer dedicated to taking care of your agency website. He has tasks that he doesn’t actively collaborate with anyone else on. He gets a mockup of the website, some copy, and gets to work. He might also be actively trying to sell his apartment. In most companies, this would mean that he has to run back and forth between the apartment and the office, sometimes multiple times a day, to deal with the buyers, real estate agents and contractors. But does he really have to?

Would it not be more comfortable for him to stay at home and work between meetings? And would it not make it easier for his team members and managers not to have to keep track of his travel schedule? And if the work gets done in the right time frame, does his physical presence at the office really matter? I’ll discuss this further in “Is it time to go fully remote?” post.

SQAEB TIP

At SQAEB, everyone has a setup that allows for secure remote work, and in case of sickness, family emergencies, schoolwork or other unforeseen events, they are always welcome to work from home. We give people the benefit of the doubt / assume positive intent, and so far, it has always paid off.

agile, BDD, Management, Specslist, Talent

Talent Freedom

Freedom is often hailed as the ultimate solution to happy employees. But most people have an easier time being creative when there are some restrictions in place.

Example: If your agency needs you to write as many slogans as possible selling pineapples in the next 10 minutes. When do you think you will produce more? A) If the 10 minutes is the only restriction. B) If you have a 10 minute restriction, you cannot use the word pineapple and all the slogans have to be under 10 words or less?

Studies show that B is the right answer – even though you have more freedom in A. Sidenote: We tried it at our office and we are currently considering a new venture in ’’Spiky yellow fruit’’ advertising.

So does this prove that freedom may not be the answer to an infinitely creative and productive workplace culture?

Of course not – because we had the freedom to choose those restrictions.

Client expectations and agency needs dictate the tasks that have to be solved. Every agency also needs to have some time and budget restrictions to prevent a project getting out of hand.

Other than that, the freedom to solve the problem in any way possible is one of the most significant benefits you can grant your employees:

  • The most efficient way to a problem takes all the learning and experimentation out of the process
  • Using less billable hours and achieving maximum efficiency will inevitably mean that the client should probably expect cookie-cutter deliverables instead of innovative solutions
  • If there is a framework, guideline or brand book for everything, proposing new solutions and approaches might be perceived as too much of a hassle to even suggest

If you find the perfect balance in the above, you should have the How and Why of task management covered. But freedom in the workplace is a complicated thing. The How and Why are questions that have to be answered or the work will never get done. But why not take more weight off of people’s shoulders by not having them stress over the When and Where as well?

agile, BDD, Management, Specslist, Talent

NURTURING AND RETAINING TOP TALENT

Hiring and onboarding new employees is one thing. But as we know, the costs of employee turnover is high. If you don’t work on having a great environment where your employees thrive, then it’s going to be very costly for you to keep replacing everyone.

Employees changing jobs is impossible to stop – especially in the tech industry – but there are things you can do to keep your turnover rate low.

This post could just be called ’’culture in the agency space’’ because that is the true key to acquiring and keeping top talent.

But what is company culture?

The 17-word, aka the short answer: Company culture is the combination of all the values, social interactions, and psychological behavior in an organization.

The 340-word, aka the long answer:Company culture is hard to define in specific terms, because unlike most essential things in business, it is entirely intangible, a feeling. Branding is closely intertwined with culture in every interaction that the company makes with any of its outside stakeholders. And if you want your brand to be consistent across all channels, you have to work towards a work culture that aligns with your corporate messaging.

A brand is a reflection of your company in the minds of your stakeholders.

That is why it takes on new forms in every piece of content shared on social media, every meeting with a possible client, and every shared lunch break with Debbie from the agency next door. A brand consists of many moving parts, some tangible, some not. The tangible can be boiled down to visual identity, messaging, and imagery, if need be. These can all be changed with a new set of guidelines, a new designer, or a new marketing department, but how do you control a culture?

Culture is not just a code of conduct, communication strategy, or a list of processes. Company culture includes all the small details:

  • The tone of voice the CEO uses to address a reporter while discussing a new acquisition
  • If your employees feel comfortable to talk about non-work related issues with their manager
  • If the new sales intern feels like waking up in the morning on his second week on the jobAnd that’s why culture is one of the hardest things to get right in an agency, as it can not be acquired, mandated or forced.

Culture has to be built and continuously monitored and maintained.

You can tell a lot about an agency culture:

  • In the way, your company treats employees, customers and the surrounding community
  • In the degree that your employees are committed to the company values and goals
  • By how comfortable employees are with innovating, making decisions and expressing their opinions
  • In how information is broadcasted from one department to another and from the higher-ups to the lower-level employees

agile, BDD, Management, Specslist, Talent

Day one onboarding

There are many things a person needs to know on their first day at a company. And there are a lot of things that they will definitely not remember. To prevent information overload, it’s preferable to keep some essential things for the rest of the week so the fresh hire will pick them all up eventually. So what should they know on their first day?

  1. Give them an “onboarding buddy”. This should be someone from their team, who they can ask any and all questions to, without feeling like you are bothering them
  2. The values or the ’’WHY’’ of the company
  3. The names of their closest coworkers
  4. The tech stack your department is using
  5. Where to find the best coffee machine in the building, as well as any other refreshments they can get (fruit, cold water, etc.)
  6. How the company intranet or CMS works
  7. The most efficient way to get to their desk
  8. The information and communication flow of your company (emails, chat, phone calls, etc.)
  9. Where the bathrooms are (you’d be surprised how often this is an issue)
  10. What task management solution your team uses to keep track of tasks
  11. When lunch is
  12. Their first real work-related task

That’s about it, any other information would probably be too much, and
as we all know, if you go for a handshake tour with every department immediately, you forget the first person’s name while shaking the third one’s hand.

agile, BDD, Management, Specslist, Talent

Onboarding that rocks

Onboarding a new person to the team is a masterclass in taking your own medicine for a lot of agencies. Every good agency prides itself on an in- depth understanding of user journeys and user experience, but what is the experience of joining your agency like?

Placing someone behind a desk, giving them access to your password manager, and asking them to start developing right away is the equivalent of ordering a pizza and giving the delivery guy just your zip code. It takes so much more, and a good onboarding experience can make or break your company’s ability to foster new top talent.

agile, BDD, Management, Specslist, Talent

Interview a talent

Generally, tech companies started adopting ’’a multiple interview approach’’ that not only gives applicants a coding test or some homework, but also goes over their background and culture fit in the same depth. More and more agencies are now doing the same. This is where our hiring journey once again splits into two paths, this time, based on if you chose the internal hiring strategy or the headhunter/recruiter strategy.

The recruiter can take care of the searching, first impressions and the technical fit, but you should always have the most promising candidates meet the current team for a short and sweet meet and greet before you consider hiring them.

If the agency conducts the entire hiring process in-house, there is a lot of leeway in the process. Try new approaches and strategies, and eventually, you will find what works for you. But if you want a hint from a company that put culture first and has been doing so for 3 years, here’s how we do it at SQAEB:

  1. Collaborative effort to identify skills required. Once we are sure we need a new addition to a department, the team goes over the exact skills we are looking for. This ensures that the team knows which new skills are coming in, instead of a manager deciding it themselves.
  2. Job posting. When the manager has the final job posting ready, it is posted and shared online internally as well as externally. We know the value of a good network, so employees from all departments are asked to share it with anyone they might think is a good fit. To help gauge personality in the first screening process we usually ask for a short video introduction, along with a resumé, just to get an idea of who you are as a person even before we meet you.
  3. Screening of candidates. As soon as we have enough candidates, the first screening process starts. This consists of sorting out any that does not have the required skills or did not adequately show that they would be a good cultural fit.
  4. First interview. All candidates that pass our first screening are invited
    to a first interview. The purpose of the first interview is to get to know them as a person and figure out if they would be a good cultural fit. This includes having a current team member talk to them for 10 minutes one- on-one, without those involved with the hiring present. If the personality is a match to our culture, they are given homework and invited to a second interview.
  5. Homework. While the first interview is focused on the cultural fit, the second is about technical skills. And to judge that, each candidate is given homework to complete before the second interview. This consists of various work-related tasks where they have a chance to showcase their skills. The homework also includes writing a movie review. This is an added curveball to see how they approach problem solving of tasks they probably haven’t done since high school.
  6. Second interview. We have the second interview to go over the homework and technical questions. This is where their skills are assessed and the main goal is to ensure that the chosen candidate has the necessary skills to handle the tasks they would be given in the position.
  7. Hiring. After the second round of interviews it is often clear which candidate is the best cultural fit and whether or not they have the necessary skills.

Now that you’re done recruiting and have hired the right person, the real work starts: onboarding. Hiring the right candidate is one thing; but if you don’t manage to give them a proper onboarding experience they will not perform as well as they could. Onboarding is the first step towards nurturing top talent.
agile, BDD, Management, Specslist, Talent

Talent Career page

A good starting point for your ’’first point of recruitment’’ (not the first point of contact, because that’s probably your landing page) is to create a clear value proposition for the inbound job candidates. Until your agency reaches a certain size, you can’t cater to everyone’s wishes concerning work-life balance. Your hiring decisions should always be based on a cultural fit more than a technical fit.

While technical skills are clearly important, it’s much easier to improve a skill than it is to change
a personality. If we want to go into specifics, we can go back to the user experience analogy. When writing a value proposition on the careers page, you need to think about what kind of agency you really are.

’’We are looking for dedicated people to help bring the most innovative web solutions to life for our clients by day, and help us put up new shelves for all these awards by night…’’

That statement will attract a certain kind of people:

  • Fresh graduates with a lot of ambition looking for validation of their skills
  • Experienced professionals who want an environment for their talents to be utilized
  • People looking for a challenge and don’t even consider crunch time a negative word
  • Career-building professionals who are looking for a place that gets them more awards to their resume
  • People who live for their jobs and look forward to evenings and Saturdays at the office filled with pizza and fixing the kinks in the code

Then on the other side of the spectrum, you could have:

’’ You bring the talent, we bring the perks. At AUE Inc. (Agency Used as an Example), we value strategy and planning above everything else. And thanks to our in-depth research and planning, clients always get the solution they need, instead of the solution they think they want. This also means that our employees never have to worry about scope creep or staying at work past 5 PM. Oh, and did we mention possibilities of

working from home or the 4 day work week?”

A few sentences like this on your career page could go a long way towards attracting people that:

  • Love their jobs, but don’t want to sacrifice time with their family for work
  • Are perfect for the job, but would have had to relocate or travel multiple hours every day
  • Are motivated for the job, but also have other ambitions and are trying to run some sort of side-hustle or project on the side

Sections like ”International Workplace” or ”Fun Squad” shows that we care about an open and fun work environment, where your colleagues also become your friends.

agile, BDD, Management, Specslist, Talent

Personality vs. skills

Before we get any further it’s time to address the tiny elephant in the room:

What’s more important – personality or skills?

To answer that question, you only need to scroll back up a few pages to find our list of characteristics for top talent. Notice how there’s only 1 called skill, while the rest are primarily based on personality?

That’s no coincidence. While skill alone is incredibly important, it’s what makes them capable of doing their job after all, it’s not necessarily the thing that makes them top talent. If they are an amazing coder, but can’t be depended on to meet deadlines or have issues working together with their team, it’s hard to call them top talent.

At the end of the day it’s important to remember that skills can be taught and improved, but personality and culture can’t. And if you want your entire team to perform – not just the individual – it’s important to have the right mix of personalities and culture. If the right culture is there, you’ll see skills improve for everyone and soon you’ll have a team full of top talent that performs day in and day out.

SQAEB TIP

For 99 % of our job postings we use this to highlight our people- first focus:

”We care about people. That’s why the most important qualification is your personality: who you are, what values you have and how you interact with other people. We are looking for people with passion and energy to be part of something bigger than themselves and who are willing to dedicate their time and skills towards building great products and services in collaboration with talented and friendly colleagues.”

agile, BDD, Gaming, Management, Specslist, Talent

Talent RECRUITMENT

Recruitment. Love it or hate it, this is where it all starts if you want to attract top talent for your agency. But there’s so much more to recruitment than job postings and hiring recruiters. It’s in the recruitment phase that the first bit of onboarding starts. While it is 100% the candidate’s responsibility to find out as much as possible about the agency he wants to join, why not show your values and culture even at the earliest stages and make it easier for them?

We are drawn to leaders and organizations that are good at communicating what they believe. Their ability to make us feel like we belong, to make us feel special, safe and not alone is part of what gives them the ability to inspire us

– Simon Sinek, Author of ’’Start with Why’’

It’s no secret that even the most basic one-page websites have an “about us” section. But imagine being a top talent developer or specialist looking for new opportunities. They might go through 50 “about us” pages every day. Does your mission and vision statement stand out of the crowd? Do you communicate having a culture that provides a constant stream of challenging problems to solve? Do you have a hilarious video of your founder switching places with your human-sized-rabbit-office-mascot and shooting confetti at your unsuspecting support staff?

SQAEB TIP

Do you want to show your values to potential clients? Then video is the way to go. It doesn’t have to be a big production – the only thing it has to do, is to show your company values and culture.

Letting your mission, vision and culture shine through in your recruiting process helps you immensely in not only standing out from the crowd, but also in attracting the right people for your company.

agile, Management

Test management

Test Organisation

Independent Testing

Testing tasks may be done by people in a specific testing role, or by people in another role (e.g., customers). A certain degree of independence often makes the tester more effective at finding defects due to differences between the author’s and the tester’s cognitive biases. Independence is not, however, a replacement for familiarity, and developers can efficiently find many defects in their own code. 

Degrees of independence in testing include the following (from low level of independence to high level):

  • No independent testers; the only form of testing available is developers testing their own code 
  • Independent developers or testers within the development teams or the project team; this could be developers testing their colleagues’ products 
  • Independent test team or group within the organisation, reporting to project management or executive management 
  • Independent testers from the business organisation or user community, or with specialisations in specific test types such as usability, security, performance, regulatory/compliance, or portability 
  • Independent testers external to the organisation, either working on-site (in-house) or off-site (outsourcing)

For most types of projects, it is usually best to have multiple test levels, with some of these levels handled by independent testers. Developers should participate in testing, especially at the lower levels, so as to exercise control over the quality of their own work.

The way in which independence of testing is implemented varies depending on the software development lifecycle model. For example, in Agile development, testers may be part of a development team. In some organisations using Agile methods, these testers may be considered part of a larger independent test team as well. In addition, in such organisations, product owners may perform acceptance testing to validate user stories at the end of each iteration.

Potential benefits of test independence include:

  • Isolation from the development team, may lead to a lack of collaboration, delays in providing feedback to the development team, or an adversarial relationship with the development team
  • Developers may lose a sense of responsibility for quality
  • Independent testers may be seen as a bottleneck
  • Independent testers may lack some important information (e.g., about the test object)

Many organisations are able to successfully achieve the benefits of test independence while avoiding the drawbacks.

Tasks of a Test Manager and Tester 

In this article, two test roles are covered, test managers and testers. The activities and tasks performed by these two roles depend on the project and product context, the skills of the people in the roles, and the organisation.

The test manager is tasked with overall responsibility for the test process and successful leadership of the test activities. The test management role might be performed by a professional test manager, or by a project manager, a development manager, or a quality assurance manager. In larger projects or organisations, several test teams may report to a test manager, test coach, or test coordinator, each team being headed by a test leader or lead tester.

Typical test manager tasks may include:

  • Develop or review a test policy and test strategy for the organisation 
  • Plan the test activities by considering the context, and understanding the test objectives and risks. This may include selecting test approaches, estimating test time, effort and cost, acquiring resources, defining test levels and test cycles, and planning defect management
  • Write and update the test plan(s) 
  • Coordinate the test plan(s) with project managers, product owners, and others 
  • Share testing perspectives with other project activities, such as integration planning 
  • Initiate the analysis, design, implementation, and execution of tests, monitor test progress and results, and check the status of exit criteria (or definition of done) and facilitate test completion activities 
  • Prepare and deliver test progress reports and test summary reports based on the information gathered 
  • Adapt planning based on test results and progress (sometimes documented in test progress reports, and/or in test summary reports for other testing already completed on the project) and take any actions necessary for test control 
  • Support setting up the defect management system and adequate configuration management of test-ware 
  • Introduce suitable metrics for measuring test progress and evaluating the quality of the testing and the product
  • Support the selection and implementation of tools to support the test process, including recommending the budget for tool selection (and possibly purchase and/or support), allocating time and effort for pilot projects, and providing continuing support in the use of the tool(s) 
  • Decide about the implementation of test environment(s) 
  • Promote and advocate the testers, the test team, and the test profession within the organisation 
  • Develop the skills and careers of testers (e.g., through training plans, performance evaluations, coaching, etc.)

The way in which the test manager role is carried out varies depending on the software development lifecycle. For example, in Agile development, some of the tasks mentioned above are handled by the Agile team, especially those tasks concerned with the day-to-day testing done within the team, often by a tester working within the team. Some of the tasks that span multiple teams or the entire organisation, or that have to do with personnel management, may be done by test managers outside of the development team, who are sometimes called test coaches.

Typical tester tasks may include:

  • Review and contribute to test plans 
  • Analyse, review, and assess requirements, user stories and acceptance criteria, specifications, and models for testability (i.e., the test basis) 
  • Identify and document test conditions, and capture traceability between test cases, test conditions, and the test basis 
  • Design, set up, and verify test environment(s), often coordinating with system administration and network management 
  • Design and implement test cases and test procedures 
  • Prepare and acquire test data
  • Create the detailed test execution schedule 
  • Execute tests, evaluate the results, and document deviations from expected results 
  • Use appropriate tools to facilitate the test process 
  • Automate tests as needed (may be supported by a developer or a test automation expert)
  • Evaluate non-functional characteristics such as performance efficiency, reliability, usability, security, compatibility, and portability 
  • Review tests developed by others

People who work on test analysis, test design, specific test types, or test automation may be specialists in these roles. Depending on the risks related to the product and the project, and the software development lifecycle model selected, different people may take over the role of tester at different test levels. For example, at the component testing level and the component integration testing level, the role of a tester is often done by developers. At the acceptance test level, the role of a tester is often done by business analysts, subject matter experts, and users. At the system test level and the system integration test level, the role of a tester is often done by an independent test team. At the operational acceptance test level, the role of a tester is often done by operations and/or systems administration staff.

Test Planning and Estimation

Purpose and Content of a Test Plan

A test plan outlines test activities for development and maintenance projects. Planning is influenced by the test policy and test strategy of the organisation, the development lifecycles and methods being used, the scope of testing, objectives, risks, constraints, criticality, testability, and the availability of resources. 

As the project and test planning progress, more information becomes available and more detail can be included in the test plan. Test planning is a continuous activity and is performed throughout the product’s lifecycle. (Note that the product’s lifecycle may extend beyond a project’s scope to include the maintenance phase.) Feedback from test activities should be used to recognise changing risks so that planning can be adjusted. Planning may be documented in a master test plan and in separate test plans for test levels, such as system testing and acceptance testing, or for separate test types, such as usability testing and performance testing. Test planning activities may include the following and some of these may be documented in a test plan:

  • Determining the scope, objectives, and risks of testing
  • Defining the overall approach of testing
  • Integrating and coordinating the test activities into the software lifecycle activities
  • Making decisions about what to test, the people and other resources required to perform the various test activities, and how test activities will be carried out
  • Scheduling of test analysis, design, implementation, execution, and evaluation activities, either on particular dates (e.g., in sequential development) or in the context of each iteration (e.g., in iterative development)
  • Selecting metrics for test monitoring and control
  • Budgeting for the test activities
  • Determining the level of detail and structure for test documentation (e.g., by providing templates or example documents)

The content of test plans vary, and can extend beyond the topics identified above.

Test Strategy and Test Approach

A test strategy provides a generalised description of the test process, usually at the product or organisational level. Common types of test strategies include:

  • Analytical: This type of test strategy is based on an analysis of some factor (e.g., requirement or risk). Risk-based testing is an example of an analytical approach, where tests are designed and prioritised based on the level of risk.
  • Model-Based: In this type of test strategy, tests are designed based on some model of some required aspect of the product, such as a function, a business process, an internal structure, or a non-functional characteristic (e.g., reliability). Examples of such models include business process models, state models, and reliability growth models.
  • Methodical: This type of test strategy relies on making systematic use of some predefined set of tests or test conditions, such as a taxonomy of common or likely types of failures, a list of important quality characteristics, or company-wide look-and-feel standards for mobile apps or web pages. 
  • Process-compliant (or standard-compliant): This type of test strategy involves analysing, designing, and implementing tests based on external rules and standards, such as those specified by industry-specific standards, by process documentation, by the rigorous identification and use of the test basis, or by any process or standard imposed on or by the organisation. 
  • Directed (or consultative): This type of test strategy is driven primarily by the advice, guidance, or instructions of stakeholders, business domain experts, or technology experts, who may be outside the test team or outside the organisation itself.
  • Regression-averse: This type of test strategy is motivated by a desire to avoid regression of existing capabilities. This test strategy includes reuse of existing testware (especially test cases and test data), extensive automation of regression tests, and standard test suites.
  • Reactive: In this type of test strategy, testing is reactive to the component or system being tested, and the events occurring during test execution, rather than being pre-planned (as the preceding strategies are). Tests are designed and implemented, and may immediately be executed in response to knowledge gained from prior test results. Exploratory testing is a common technique employed in reactive strategies.

An appropriate test strategy is often created by combining several of these types of test strategies. For example, risk-based testing (an analytical strategy) can be combined with exploratory testing (a reactive strategy); they complement each other and may achieve more effective testing when used together.

While the test strategy provides a generalised description of the test process, the test approach tailors the test strategy for a particular project or release. The test approach is the starting point for selecting the test techniques, test levels, and test types, and for defining the entry criteria and exit criteria (or definition of ready and definition of done, respectively). The tailoring of the strategy is based on decisions made in relation to the complexity and goals of the project, the type of product being developed, and product risk analysis. The selected approach depends on the context and may consider factors such as risks, safety, available resources and skills, technology, the nature of the system (e.g., custom-built versus COTS), test objectives, and regulations.

Entry Criteria and Exit Criteria (Definition of Ready and Definition of Done)

In order to exercise effective control over the quality of the software, and of the testing, it is advisable to have criteria which define when a given test activity should start and when the activity is complete. Entry criteria (more typically called definition of ready in Agile development) define the preconditions for undertaking a given test activity. If entry criteria are not met, it is likely that the activity will prove more difficult, more time-consuming, more costly, and more risky. Exit criteria (more typically called definition of done in Agile development) define what conditions must be achieved in order to declare a test level or a set of tests completed. Entry and exit criteria should be defined for each test level and test type, and will differ based on the test objectives.

Typical entry criteria include: 

  • Availability of testable requirements, user stories, and/or models (e.g., when following a model-based testing strategy)
  • Availability of test items that have met the exit criteria for any prior test levels
  • Availability of test environment
  • Availability of necessary test tools
  • Availability of test data and other necessary resources

Typical exit criteria include:

  • Planned tests have been executed
  • A defined level of coverage (e.g., of requirements, user stories, acceptance criteria, risks, code) has been achieved 
  • The number of unresolved defects is within an agreed limit 
  • The number of estimated remaining defects is sufficiently low
  • The evaluated levels of reliability, performance efficiency, usability, security, and other relevant quality characteristics are sufficient

Even without exit criteria being satisfied, it is also common for test activities to be curtailed due to the budget being expended, the scheduled time being completed, and/or pressure to bring the product to market. It can be acceptable to end testing under such circumstances, if the project stakeholders and business owners have reviewed and accepted the risk to go live without further testing.

Test Execution Schedule

Once the various test cases and test procedures are produced (with some test procedures potentially automated) and assembled into test suites, the test suites can be arranged in a test execution schedule that defines the order in which they are to be run. The test execution schedule should take into account such factors as prioritizations, dependencies, confirmation tests, regression tests, and the most efficient sequence for executing the tests.

Ideally, test cases would be ordered to run based on their priority levels, usually by executing the test cases with the highest priority first. However, this practice may not work if the test cases have dependencies or the features being tested have dependencies. If a test case with a higher priority is dependent on a test case with a lower priority, the lower priority test case must be executed first. Similarly, if there are dependencies across test cases, they must be ordered appropriately regardless of their relative priorities. Confirmation and regression tests must be prioritised as well, based on the importance of rapid feedback on changes, but here again dependencies may apply.

In some cases, various sequences of tests are possible, with differing levels of efficiency associated with those sequences. In such cases, trade-offs between efficiency of test execution versus adherence to prioritisation must be made.

Factors Influencing the Test Effort

Test effort estimation involves predicting the amount of test-related work that will be needed in order to meet the objectives of the testing for a particular project, release, or iteration. Factors influencing the test effort may include characteristics of the product, characteristics of the development process, characteristics of the people, and the test results, as shown below.

Product characteristics

  • The risks associated with the product
  • The quality of the test basis
  • The size of the product
  • The complexity of the product domain
  • The requirements for quality characteristics (e.g., security, reliability) 
  • The required level of detail for test documentation 
  • Requirements for legal and regulatory compliance

Development characteristics process

  • The stability and maturity of the organisation
  • The development model in use
  • The approach to test
  • The tools used
  • The test to process 
  • Time pressure

People characteristics

  • The skills and experience of the people involved, especially with similar projects and products (e.g., domain knowledge)
  • Team cohesion and leadership

Test results

  • The number and severity of defects found
  • The amount of re-work required

Test Estimation Techniques

There are a number of estimation techniques used to determine the effort required for adequate testing. Two of the most commonly used techniques are:

  • The metrics-based technique: estimating the test effort based on metrics of former similar projects, or based on typical values
  • The expert-based technique: estimating the test effort based on the experience of the owners of the testing tasks or by experts

For example, in Agile development, burn-down charts are examples of the metrics-based approach as effort remaining is being captured and reported, and is then used to feed into the team’s velocity to determine the amount of work the team can do in the next iteration; whereas planning poker, also called scrum poker, is an example of the expert-based approach, as team members are estimating the effort to deliver a feature based on their experience.

Within sequential projects, defect removal models are examples of the metrics-based approach, where volumes of defects and time to remove them are captured and reported, which then provides a basis for estimating future projects of a similar nature; whereas the Wideband Delphi estimation technique is an example of the expert-based approach in which a group of experts provides estimates based on their experience.

Test Monitoring and Control

The purpose of test monitoring is to gather information and provide feedback and visibility about test activities. Information to be monitored may be collected manually or automatically and should be used to assess test progress and to measure whether the test exit criteria, or the testing tasks associated with an Agile project’s definition of done, are satisfied, such as meeting the targets for coverage of product risks, requirements, or acceptance criteria.

Test control describes any guiding or corrective actions taken as a result of information and metrics gathered and (possibly) reported. Actions may cover any test activity and may affect any other software lifecycle activity.

Examples of test control actions include: 

  • Re-prioritising tests when an identified risk occurs (e.g., software delivered late)
  • Changing the test schedule due to availability or unavailability of a test environment or other resources
  • Re-evaluating whether a test item meets an entry or exit criterion due to rework

Metrics Used in Testing

Metrics can be collected during and at the end of test activities in order to assess:

  • Progress against the planned schedule and budget
  • Current quality of the test object
  • Adequacy of the test approach
  • Effectiveness of the test activities with respect to the objectives

Common test metrics include:

  • Percentage of planned work done in test case preparation (or percentage of planned test cases implemented)
  • Percentage of planned work done in test environment preparation
  • Test case execution (e.g., number of test cases run/not run, test cases passed/failed, and/or test conditions passed/failed)
  • Defect information (e.g., defect density, defects found and fixed, failure rate, and confirmation test results)
  • Test coverage of requirements, user stories, acceptance criteria, risks, or code
  • Task completion, resource allocation and usage, and effort
  • Cost of testing, including the cost compared to the benefit of finding the next defect or the cost compared to the benefit of running the next test

Audiences, Contents, and Purposes for Test Reports

The purpose of test reporting is to summarise and communicate test activity information, both during and at the end of a test activity (e.g., a test level). The test report prepared during a test activity may be referred to as a test progress report, while a test report prepared at the end of a test activity may be referred to as a test summary report.

During test monitoring and control, the test manager regularly issues test progress reports for stakeholders. In addition to content common to test progress reports and test summary reports, typical test progress reports may also include:

  • The status of the test activities and progress against the test plan
  • Factors impeding progress
  • Testing planned for the next reporting period
  • The quality of the test objects

When exit criteria are reached, the test manager issues the test summary report. This report provides a summary of the testing performed, based on the latest test progress report and any other relevant information.

Typical test summary reports may include:

  • Summary of testing performed
  • Information on what occurred during a test period
  • Deviations from plan, including deviations in schedule, duration, or effort of test activities
  • Status of testing and product quality with respect to the exit criteria or definition of done
  • Factors that have blocked or continue to block progress
  • Metrics of defects, test cases, test coverage, activity progress, and resource consumption.
  • Residual risks
  • Reusable test work products produced

The contents of a test report will vary depending on the project, the organisational requirements, and the software development lifecycle. For example, a complex project with many stakeholders or a regulated project may require more detailed and rigorous reporting than a quick software update. As another example, in Agile development, test progress reporting may be incorporated into task boards, defect summaries, and burn-down charts, which may be discussed during a daily stand-up meeting.

In addition to tailoring test reports based on the context of the project, test reports should be tailored based on the report’s audience. The type and amount of information that should be included for a technical audience or a test team may be different from what would be included in an executive summary report. In the first case, detailed information on defect types and trends may be important. In the latter case, a high-level report (e.g., a status summary of defects by priority, budget, schedule, and test conditions passed/failed/not tested) may be more appropriate.

Configuration Management

The purpose of configuration management is to establish and maintain the integrity of the component or system, the test-ware, and their relationships to one another through the project and product lifecycle. 

To properly support testing, configuration management may involve ensuring the following:

  • All test items are uniquely identified, version controlled, tracked for changes, and related to each other
  • All items of test-ware are uniquely identified, version controlled, tracked for changes, related to each other and related to versions of the test item(s) so that traceability can be maintained throughout the test process
  • All identified documents and software items are referenced unambiguously in test documentation

During test planning, configuration management procedures and infrastructure (tools) should be identified and implemented.

Risks and Testing

Definition of Risk

Risk involves the possibility of an event in the future which has negative consequences. The level of risk is determined by the likelihood of the event and the impact (the harm) from that event.

Product and Project Risks

Product risk involves the possibility that a work product (e.g., a specification, component, system, or test) may fail to satisfy the legitimate needs of its users and/or stakeholders. When the product risks are associated with specific quality characteristics of a product (e.g., functional suitability, reliability, performance efficiency, usability, security, compatibility, maintainability, and portability), product risks are also called quality risks. Examples of product risks include:

  • Software might not perform its intended functions according to the specification
  • Software might not perform its intended functions according to user, customer, and/or stakeholder needs
  • A system architecture may not adequately support some non-functional requirement(s)
  • A particular computation may be performed incorrectly in some circumstances
  • A loop control structure may be coded incorrectly
  • Response-times may be inadequate for a high-performance transaction processing system
  • User experience (UX) feedback might not meet product expectations

Project risk involves situations that, should they occur, may have a negative effect on a project’s ability to achieve its objectives. Examples of project risks include:

  • Project issues:
    • Delays may occur in delivery, task completion, or satisfaction of exit criteria or definition of done 
    • Inaccurate estimates, reallocation of funds to higher priority projects, or general cost-cutting across the organisation may result in inadequate funding 
    • Late changes may result in substantial re-work
  • Organisational issues: 
    • Skills, training, and staff may not be sufficient 
    • Personnel issues may cause conflict and problems 
    • Users, business staff, or subject matter experts may not be available due to conflicting business priorities
  • Political issues:
    • Testers may not communicate their needs and/or the test results adequately
    • Developers and/or testers may fail to follow up on information found in testing and reviews (e.g., not improving development and testing practices)
    • There may be an improper attitude toward, or expectations of, testing (e.g., not appreciating the value of finding defects during testing)
  • Technical issues: 
    • Requirements may not be defined well enough 
    • The requirements may not be met, given existing constraints 
    • The test environment may not be ready on time 
    • Data conversion, migration planning, and their tool support may be late 
    • Weaknesses in the development process may impact the consistency or quality of project work products such as design, code, configuration, test data, and test cases
    • Poor defect management and similar problems may result in accumulated defects and other technical debt
  • Supplier issues:
    • A third party may fail to deliver a necessary product or service, or go bankrupt
    • Contractual issues may cause problems to the project

Project risks may affect both development activities and test activities. In some cases, project managers are responsible for handling all project risks, but it is not unusual for test managers to have responsibility for test-related project risks.

Product Quality and Risk-based Testing

Risk is used to focus the effort required during testing. It is used to decide where and when to start testing and to identify areas that need more attention. Testing is used to reduce the probability of an adverse event occurring, or to reduce the impact of an adverse event. Testing is used as a risk mitigation activity, to provide information about identified risks, as well as providing information on residual (unresolved) risks. 

A risk-based approach to testing provides proactive opportunities to reduce the levels of product risk. It involves product risk analysis, which includes the identification of product risks and the assessment of each risk’s likelihood and impact. The resulting product risk information is used to guide test planning, the specification, preparation and execution of test cases, and test monitoring and control. Analysing product risks early contributes to the success of a project. 

In a risk-based approach, the results of product risk analysis are used to:

  • Determine the test techniques to be employed
  • Determine the particular levels and types of testing to be performed (e.g., security testing, accessibility testing)
  • Determine the extent of testing to be carried out
  • Prioritise testing in an attempt to find the critical defects as early as possible 
  • Determine whether any activities in addition to testing could be employed to reduce risk (e.g., providing training to inexperienced designers)

Risk-based testing draws on the collective knowledge and insight of the project stakeholders to carry out product risk analysis. To ensure that the likelihood of a product failure is minimised, risk management activities provide a disciplined approach to:

  • Analyse (and re-evaluate on a regular basis) what can go wrong (risks)
  • Determine which risks are important to deal with
  • Implement actions to mitigate those risks
  • Make contingency plans to deal with the risks should they become actual events

In addition, testing may identify new risks, help to determine what risks should be mitigated, and lower uncertainty about risks.

Defect Management

Since one of the objectives of testing is to find defects, defects found during testing should be logged. The way in which defects are logged may vary, depending on the context of the component or system being tested, the test level, and the software development lifecycle model. Any defects identified should be investigated and should be tracked from discovery and classification to their resolution (e.g., correction of the defects and successful confirmation testing of the solution, deferral to a subsequent release, acceptance as a permanent product limitation, etc.). In order to manage all defects to resolution, an organisation should establish a defect management process which includes a workflow and rules for classification. This process must be agreed with all those participating in defect management, including architects, designers, developers, testers, and product owners. In some organisations, defect logging and tracking may be very informal. 

During the defect management process, some of the reports may turn out to describe false positives, not actual failures due to defects. For example, a test may fail when a network connection is broken or times out. This behaviour does not result from a defect in the test object, but is an anomaly that needs to be investigated. Testers should attempt to minimise the number of false positives reported as defects. 

Defects may be reported during coding, static analysis, reviews, or during dynamic testing, or use of a software product. Defects may be reported for issues in code or working systems, or in any type of documentation including requirements, user stories and acceptance criteria, development documents, test documents, user manuals, or installation guides. In order to have an effective and efficient defect management process, organisations may define standards for the attributes, classification, and workflow of defects.

Typical defect reports have the following objectives: 

  • Provide developers and other parties with information about any adverse event that occurred, to enable them to identify specific effects, to isolate the problem with a minimal reproducing test, and to correct the potential defect(s), as needed or to otherwise resolve the problem
  • Provide test managers a means of tracking the quality of the work product and the impact on the testing (e.g., if a lot of defects are reported, the testers will have spent a lot of time reporting them instead of running tests, and there will be more confirmation testing needed)
  • Provide ideas for development and test process improvement

A defect report filed during dynamic testing typically includes:

  • An identifier
  • A title and a short summary of the defect being reported
  • Date of the defect report, issuing organization, and author
  • Identification of the test item (configuration item being tested) and environment
  • The development lifecycle phase(s) in which the defect was observed
  • A description of the defect to enable reproduction and resolution, including logs, database dumps, screenshots, or recordings (if found during test execution)
  • Expected and actual results
  • Scope or degree of impact (severity) of the defect on the interests of stakeholder(s)
  • Urgency/priority to fix
  • State of the defect report (e.g., open, deferred, duplicate, waiting to be fixed, awaiting confirmation testing, re-opened, closed)
  • Conclusions, recommendations and approvals
  • Global issues, such as other areas that may be affected by a change resulting from the defect
  • Change history, such as the sequence of actions taken by project team members with respect to the defect to isolate, repair, and confirm it as fixed
  • References, including the test case that revealed the problem

Some of these details may be automatically included and/or managed when using defect management tools, e.g., automatic assignment of an identifier, assignment and update of the defect report state during the workflow, etc. Defects found during static testing, particularly reviews, will normally be documented in a different way, e.g., in review meeting notes.