In one of the projects I worked on, there was a QA department, but over several months, I never encountered any of its members. I often jokingly referred to them as the Loch Ness Monster: a team that everyone had heard of, but no one had ever seen. While there was indeed a group of individuals designated for testing, their size was likely insufficient to handle the volume of issues. However, there were additional factors that prevented the team from fully utilizing their potential, and as a result, there was no pressing need to expand the team.
Software developer for everything.
Our developers are responsible for the code quality.
A statement made by a recruiter after inquiring about QA support
A recruiter’s statement during the software developer interview, when questioned about the QA team’s role in the project, raises a significant red flag. That’s not an answer to the question. While it’s evident that a software developer is responsible for the code they write, this statement could imply that the responsibility lies solely with the developer, overlooking the company’s processes for quality control and improvement.
Let’s begin by discussing the initial stages of coding, where the source of a developer’s work originates. We are in Jira system of a hypothetical company’s, with a QA team that exists in theory only. Tasks in Jira are often created by team leaders, who are usually the most experienced (and most overloaded) developers in their respective areas of the code, or by product owners. These individuals are aware of the bugs present in the system and the technical solutions that need modification or expansion.
At the beginning of a sprint, tasks are prepared. Product owners’ tasks typically involve changes to the business logic. They add a business description to Jira outlining the expected changes, but without providing any technical details. On the other hand, tasks created by team leaders mostly consist of a title only. During sprint planning, tasks are assigned to developers, and progress on implementation is expected. The estimation of developer time unfolds as follows:
- 20% Understanding the requirements and determining what needs to be done
- 10% Researching and identifying the appropriate approach for code execution
- 10% Investigating and devising the necessary changes
- 10% Analyzing potential impacts of the modifications on other technical components of the system
- 10% Analyzing potential impact of business rules on other business processes
- 5% Actively programming and implementing the code changes
- 10% Conducting thorough testing to ensure functionality and quality
- 5% Deploying the changes and performing post-deployment verification
- 20% Addressing any issues or bugs that arise during the deployment phase
Which elements do we typically anticipate to be a developer’s tasks? Points 3, 4, and 6. So, how much time do they actually spend on these? Merely 25%. It’s not uncommon to hear from company management about the constant shortage of software developers, particularly those who are experienced, talented, and consequently, quite costly. This concern becomes even more salient when you consider that an experienced software developer spends only a quarter of their time utilizing the specialized skills they’ve been trained in.
A common misconception and error in understanding QA work is the company’s intention to engage testers only after the programming phase. In our hypothetical company, at this juncture, all the business and technical knowledge needed to test the application resides within the software developer’s mind. If a software developer wishes for QA support at this stage, they must transfer their knowledge. This has two main drawbacks. First, it typically takes more time than if developers were to test the application themselves. Second, it lacks redundancy in task comprehension, both technically and business-wise.
The primary strength of testing is its ability to consider scenarios that the code’s author might not have thought of. In this manner, we diminish this strength and make the role of QA less impactful. That’s why, even if there is a shortage of QA engineers, they are not being fully utilized. This is due to the lack of preemptive integration of the QA team into earlier stages of the development cycle, where they could add the most value.
Let’s delve into the software process by examining two scenarios: modifying a business rule within the system and fixing a bug. We aim to answer the following questions:
- How can we alleviate the workload of software developers by delegating tasks to QA Engineers, particularly in areas where they possess greater competency and can execute the task more efficiently and rapidly?
- How can we enhance the outcomes of QA work by integrating them into the process at an earlier stage?
New features – modifying business behavior
Let’s concentrate on a scenario where our business process demands a change, necessitating new functionality within an application. The product owner, having gathered all the relevant knowledge about this modification from the business side, is now looking to implement these changes in the code.
Story refinement
At this stage, the team deliberates to ensure they possess all the necessary knowledge to complete the task. Any problems addressed here would certainly be more challenging and time-consuming in subsequent steps such as programming, testing, and deployment. The team contemplates all potential risks, problems, and the impact of changes on other parts of the system. The involvement of QA Engineers is crucial at this point. Their extensive understanding of the software’s functionality from a business perspective, coupled with their experience in thorough process examination across various options and configurations, makes them invaluable. They excel at identifying issues related to the impact on other software components. Furthermore, they can pinpoint potential difficulties in testing new functionalities, which can be addressed and resolved at this juncture.
Acceptance Criteria
At this stage, and crucially before the implementation phase commences, the QA team needs to formulate the Acceptance Criteria for the ticket. The Acceptance Criteria are test scenarios that delineate how the software should function. While a test scenario is inherently more general than a test case, it would be incredibly beneficial for the software developer to have access to a detailed test case, or multiple test cases, at this stage. This is particularly true when dealing with a large development team where members may not be familiar with the nuances of the application, or in situations where new developers, not yet fully versed in all the technical details and interrelations of the application, are involved. Thus, an experienced QA engineer becomes a valuable asset, offering both technical and business knowledge to the developers. Even if we choose not to craft a fully detailed test scenario, it could be extremely beneficial to provide a more thorough description of how to test the feature and the expected outcomes. They should unequivocally determine if a test has passed or failed. Moreover, they may encompass both functional and non-functional criteria, such as performance metrics. Ultimately, the Product Owner is responsible for approving these scenarios.
Test scenarios and test cases
Once the Acceptance Criteria are finalized, the implementation phase may commence. Software developers aim to write code that fulfills the Acceptance Criteria, while the QA team crafts additional test scenarios to delve deeper and manage potential edge cases. Based on the test scenarios, the test cases can now be prepared. Whether these cases are manually tested or automated either wholly or partially by QA Automation Engineers is a separate consideration at this point. The primary focus at this stage is to generate robust test scenarios that thoroughly cover the new business behavior.
Testing task
The developer has written the code, and the test cases are ready to be executed. However, the scenarios from the acceptance criteria list are failing. This is an unusual occurrence that warrants a check to ensure the software developer reviewed the acceptance criteria before marking the task as “Ready for Testing”. The software developer has the acceptance criteria listed in the task description, as it’s their responsibility to meet these criteria, and there are no excuses for non-compliance. Occasionally, the programmer may have reviewed the acceptance criteria, but due to discrepancies in their environment or the steps they took to conduct some tests, they may have seen the tests as passing, whereas the QA team identifies them as failing.
Occasionally, such situations arise and can serve as valuable lessons for future Acceptance Criteria creation. They underscore the importance of precision and the inclusion of any prerequisites that could influence the outcome of test execution.
While the execution of test cases is an important aspect, it falls beyond the scope of this article. Instead, let’s direct our attention to situations where some of the test scenarios are failing.
Defects
In an ideal world, the execution of all test scenarios would yield a perfect pass rate. However, the reality often deviates from this ideal, with some tests typically failing. At this juncture, the QA team proceeds to compile a list of bugs that need to be addressed.
I’ll delve into the details of handling bugs in code in the subsequent section, but let’s take a moment to consider the term “defect” that I’ve used here instead of “bug”. Indeed, what we’re dealing with is a bug in the code, but the code has not yet been released. From a team management perspective, and for the sake of metrics creation, there is a discernible difference between discovering a bug in the code we’re currently testing, and finding one in the code that’s already been tested and released.
Finding a bug in released software indicates that it slipped through our QA process unnoticed. This calls for an analysis on how to improve our tests and our Software Development Life Cycle (SDLC) to prevent such occurrences in the future. Conversely, a bug that has been caught suggests that the test scenario created by the QA Engineers has served its purpose effectively, and the area of improvement pertains more to the developers.
Bugs
Now let’s shift our attention to a different type of task that, regrettably, tends to occur more frequently than we would like. I am referring to those instances where the application’s behavior doesn’t align with the expected business rules.
Reporting a bug
Upon receiving information that something isn’t functioning as expected, the first steps we need to take are:
- Confirm that the issue exists.
- Determine whether it’s an actual bug or an unusual yet expected behavior.
- Figure out how to reproduce the situation that results in the bug.
Bug reports can originate from various sources, each presenting varying degrees of detail. It’s generally easier when an anomaly is detected by our in-house team during other testing procedures; they can provide comprehensive details which expedite the resolution process. However, there are instances where a bug might be reported by a client, potentially presenting challenges due to limited additional information that can be extracted. Sometimes, replicating a bug can be quite challenging, requiring numerous conditions to be met.
Those steps are primarily associated with understanding the system from the user’s perspective and discerning the expected business logic. Once again, the QA team, with their proficiency and experience in this area, may have an advantage over software developers, who are often more focused on technical details. Of course, when the bug is more technical in nature or originates from a log monitoring system, a greater level of cooperation from both sides will be expected at this stage.
We aim to deliver a ticket confirming that the bug exists, ideally with instructions on how to replicate it in our test environment.
Steps to reproduce
Much like the acceptance criteria is a critical part of a new feature ticket, the bug report should contain detailed steps to reproduce the issue. This includes information about the environment where the bug was encountered, specifics to identify the case in the database (such as customer details, product, occurrence time, and available error logs), as well as any prerequisites necessary for the bug to occur. As with the acceptance criteria, providing a step-by-step description—closer to a test scenario than a test case—can be extremely beneficial. Given that the QA Engineer already possesses all the knowledge needed to replicate the bug, it is counterproductive to expect software developers to repeat this investigative process.
Bugfix development and deployment
This section mirrors the development of a new feature quite closely. Software developers work on code modifications and database changes. If data was compromised by the bug, they also prepare remedial procedures. Concurrently, the QA team devises test scenarios that specifically address the bug. Once the necessary changes are implemented, these scenarios are executed by testers. Following the release of the bugfix, the QA team must confirm that the fix has not only resolved the issue but also corrected any damage it caused.
Similarly, if any defects are found in the work of software developers, the appropriate issues should be reported and fixed before release.
Separate Team vs Member of Existing Ones
A common query is whether QA engineers should be assigned to specific project teams or be part of a separate QA department. The formation of an independent team, with an experienced QA Engineer leading and fostering mutual support to enhance test quality and efficiency, seems beneficial. However, it’s essential to remember that onboarding a QA Engineer to a project can be as complex as onboarding a software developer. Acquiring business knowledge and understanding technical details require time. Therefore, in a multi-project company or large multi-team projects, do not anticipate the ability to seamlessly shift testers from one area to another. A QA Engineer should be assigned to a manageable number of development teams or projects. Often, that manageable number is one. If the development teams are small, then a QA team member may be able to handle multiple teams. This arrangement allows for focused and expedited completion of testing tasks when needed, such as performing regression tests before a new version release.
What’s crucial is to ensure that QA engineers remain informed about the project’s ongoing developments. If it becomes too overwhelming due to an excess of knowledge or meetings, and they start becoming outdated, it signifies that the QA engineer’s area of operation may be too broad.
Is software developer good for everything?
Of course not. As we’ve shown above, there are numerous areas in which a QA engineer outperforms a software developer. With their support and collaboration, the software developer can deliver better quality code more quickly, without the frustration of navigating unfamiliar territory. I hope this information helps improve your Software Development Life Cycle (SDLC) and makes your work a bit easier. If you disagree with any points I’ve made, I’d be happy to discuss them in the comment section. Likewise, if you feel that certain topics should be explored in greater detail, please let me know in the comments.
