paint-brush
QA Isn’t Just About Fixing Bugsby@mka342

QA Isn’t Just About Fixing Bugs

by Mohsen KhosroanjamJanuary 21st, 2025
Read on Terminal Reader
tldt arrow

Too Long; Didn't Read

Although testing the software is the main task that QA must take ownership of, it is not the only contribution that QA makes.
featured image - QA Isn’t Just About Fixing Bugs
Mohsen Khosroanjam HackerNoon profile picture

When you are thinking about QA, testing is the most likely action that comes to your mind. Although testing the software is the main task that QA must take ownership of, it is not the only contribution that QA makes. A company and the teams can benefit from QAs because they can make meaningful contributions in many aspects besides ensuring the quality of the products. In this article, I would like to introduce three collaborations with examples that can be done by QAs and the values they can bring to the companies and teams to enhance the processes and quality.


As you may know, software goes through 7 steps to be produced and delivered to the end user. It is known as the Software Development Life Cycle(SDLC):

Planning:

In the planning phase, the team will define goals and requirements based on the feedback that comes from the customers or market research team.

Feasibility Analysis:

In this phase, the team evaluates different situations that they might encounter while they are implementing the project. They may consider technical viability, costs, risks, and challenges.

System Design:

Software architecture is created in this phase to help the development team. This step may include preparing UI and compatibility requirements.

Implementation:

Based on the design specifications, the team is developing the software.

Testing:

In this phase, we identify and fix bugs, failures, and issues through various testing types to ensure the software operates as expected.

Deployment:

In the deployment phase, the software is released to end users.

Maintenance:

After we release the software, it is needed to monitor and support it. We will update and improve the features in this phase and if we find any issues or bugs, we will fix them by giving the users an updated version.


One of the contributions that can be made by QA is in the third step of SDLC, which is the system design stage (phase 3). In this step, the development team will conduct a comprehensive investigation to understand the requirements and find a solution to implement. When they have the solution, it is time to design the solution. This is where a QA can come in and make a meaningful contribution.

Why QA should contribute to solution design sessions:

  • Product and development teams come together to design the solution. As a result, solution design is a collaborative session where QA can participate in and engage with the other team members to foster effective communication and cross-functional collaboration. They can also be aligned with the other team members about what they are going to do and why.

    Before you participate in the design solution session as a QA engineer, you should read the user stories and find out the problem that we are going to solve. You can also read the business documents that are written by the product team to align on the problem and user’s need.

  • QA can provide valuable feedback in designing the software to make it tested and maintained more easily.

    To do this, you should consider the existing flows in the application and the changes that the development team is going to implement. Also, you should investigate the effects of the changes on the previous functionalities or flows. Imagine your team is going to develop an event that is published during a specific scenario. If it is impossible to reproduce the scenario, the efforts of the team will be ruined. QA could prevent the efforts from being wasted if they provided feedback on the possibility of the scenario.

  • QA can provide valuable suggestions to improve the usability and user experience of the software during solution design sessions.

    A QA engineer can leverage some tools such as Figam to identify usability issues. To do this, you should investigate the design in Figma that has been provided by the design team. Moreover, you should go through new flows on the design and see the potential failures, flaws, and errors that users can encounter. For example, imagine your team is going to add a new authentication method in the user’s authentication process. You can investigate the design in Figma and give suggestions to simplify the new method process.

  • QA can get ideas of the scope of testing and the data that is required in the testing process.

    The only action you should take is to listen carefully to the people in the meeting and make notes for yourself. You should pay attention to the new processes, new flows, how they can be tested, and what sort of data is required for testing activities.


When QA engineers get involved from the start point of the project, they ensure that quality is applied throughout the project. This proactive approach can prevent the team from encountering expensive problems later.


During the development phase of SDLC (phase 4), the team is developing the software task by task based on planning that is sprint planning in Agile methodologies which is held at the beginning of a sprint. In sprint planning the team members come together to determine the tasks to be completed during the next sprint. When we are planning the tasks, it is crucial to set clear goals and ensure that all team members are on the same page about which backlog items they are going to work on. This alignment helps the team stay focused on their goals and move forward efficiently. During sprint planning, the tasks are allocated to the team members based on their capacities and they estimate their assigned tasks. This is another point where QA must come in and take action.

The Role of QA in Sprint Planning:

  • Ensure that requirements and acceptance criteria are clear and mentioned in each task.

    As a QA engineer, you should read the documents that are related to the new feature and understand what the team is going to develop and how this new feature should work. Make sure that you understand the expected behaviors of the new feature. During the sprint planning session, you should check whether each task contains all the acceptance criteria.

  • Ensure that the tasks are well-defined and they are testable from the QA perspective.

    Consider how you can test the task. Will the development team give you a client version or an API collection to conduct testing?

  • Give realistic estimates for testing activities to keep a balance between underestimated and overcommitted.

    You can use testing management tools like Testrail to write our test cases for each feature. This is how you can estimate testing activities based on the number of test cases. In addition to that, you should consider the types of tests that are needed to be conducted.

  • Determine testing dependencies, such as test environments, test data, the devices that are needed, the types of tests that should be conducted, and so on.

    Think about the changes that will be done to the products and the scope of changes. Ask yourself if is it necessary to test them on different platforms. Will you need a specific dataset to test the changes? Is it necessary to do a regression test? Try to understand the changes and how they affect the products and flows.

  • Find the areas that can be automated and bring automation tasks into the sprint planning.

    Learn from the other’s experiences to find out where you can automate tests and how. Identify the areas for automation in your products to make test activity faster.


Sprint planning is vital to have a successful sprint. QA participation in sprint planning leads the team to have qualified outcomes and fewer issues. It also improves cooperation spirit in the team. Moreover, important quality aspects can be missed without QA and they prevent the team from experiencing delays and doing repetitive work later. For example, imagine if QA is not involved in the sprint planning session, the development team would give the estimation on testing activities. This would be an unrealistic estimation as the developers see testing from their point of view, not the end user’s view. This causes delays in releasing the feature because QA can not finish testing on the developer’s estimation. Another example is that, imagine your team is developing a new login method and they do not provide clear acceptance criteria for compatibility testing on different OS like iOS and Android. During testing, the QA should ask the team about compatibility criteria; it generates confusion and waits.


After we release the product, it is time to maintain, monitor, and improve (phase 7). In this phase, the team usually goes through retrospective sessions to share their ideas to facilitate teamwork, address obstacles, make the processes smoother, and foster continuous improvements. A quality assurance professional should join the retrospective meeting because they play a main role in maintaining the overall quality of the products and it can be spread to the quality of the processes.

QA’s Impact in Retrospectives

  • QAs can recognize the issues that were missed during the testing process, such as edge cases or uncommon scenarios.

    You should use defect-tracking systems like Jira to identify the bugs from the end users. Sometimes the QA can communicate to the call center agents to identify the missing scenarios because they are connected to the end-users.

  • They provide feedback on repetitive defects and the bottlenecks in the processes.

    Defect-tracking systems are also useful here. You can use them to see the tickets and determine what scenarios are reported many times.

  • Provide comments on how leveraging different testing tools or strategies can affect the sprint's results or they can share testing strategies/methods that worked well in the previous sprint.

    It is a good idea to have a tracking eye on the sprint progress. In this way, we can measure the velocity of the team and know the number of tasks that get done during the sprint. By analyzing the data, we can find obstacles and bottlenecks. You should use your experience to discover what testing strategies or tools can boost the velocity of testing activities. For example, if we have some repetitive scenarios that should be tested in every release, it is better we automate them to make the test faster. For another example, imagine we have some minor changes in the login process. We can choose risk-based testing to prevent from testing everything and the task will get done faster.

  • They can give suggestions on how to plan tasks in the future to prevent creating queues in the testing phase and use QA’s capacity more efficiently.

    During the sprint, you should keep track of your testing activities to identify how you progress your tasks day by day. This will help you to understand


By taking part in retrospectives, QAs would contribute to having efficient and effective working, testing, and software development processes. They also help the team learn, and understand testing challenges and QA concerns. For example, the team released the application in the previous sprint, and a bug is reported in the following sprints. QA can leverage testing management tools such as Testrail and defect tracking systems like Jira to identify why the bug has been missed and add it to the test cases for future maintenance. Another example, imagine you released a ride-sharing application and then some defects that are related to a specific area of the application happen repetitively. QA can find the exact scenario and suggest automating the area for future sprints.


In conclusion, QA is not about just getting the test done, it can go beyond it. It is about meaningful collaborations, confirming the quality, and helping the team throughout the software development journey. When QA comes into action in the early stage, they can bring profitable inputs that make the operation more reliable. They take care of the issues and address them before they become disasters and get the team into trouble. Quality assurance isn't just about finding bugs; it's about being a helpful team player and contributor to delivering amazing and user-friendly products. In addition to that, they can play a key role in finding effective solutions to the challenges as well as the user’s needs.


Resources:

https://www.atlassian.com/agile/software-development/sdlc


Image header by icomaker on Freepik