QA Engineer: Organizing a QA workflow

In this article I’ll share my experience as a QA Engineer organizing a QA workflow from scratch inside a project.

Here you can find answers for common questions like: What is the purpose of having a QA person in the project; what to do if you are the only QA Engineer in a project or how to organize a project’s QA process.

First, and not last, it’s always useful and recommended to ask the RIGHT questions to the RIGHT person. And the second point is to propose your solution, your vision of resolving problems that can be discussed earlier.

Questions to ask your boss can be like:

• What is the company structure, who is responsible for what.
• If the company hires a QA Engineer, what are their expectations about him.

Creating a QA Strategy

I·Introduction to Quality Assurance

A nice way to remind your team what does Quality Assurance (QA) mean is to ask them what does it mean to them. Trust me, there’s always someone who doesn’t understand the meaning of QA in a software development team. I experienced it myself: there was one guy who answered my “do you know what QA means?” question with “yeah, sure, it’s someone from the support team, the “Questions Answered” guy”. I was a little bit shocked. Really? He mistook Quality Assurance with Q&A, and he had 5+years experience as a developer 🙂

In this article I will use some quotes from common QA terms (source: Wiki, ISTQB, etc.).

As a QA Engineer you can make some points clear to your team, like:

Testing is a part of QA. It allows us to determine the level of quality of the feature(s) that we are assessing.It is not the sole responsibility of testers to carry out QA. The entire team can and should contribute to ensure a high level of quality of the products and services being delivered.

II·QA Strategy Explaining

As the second part, explain a QA Strategy Plan’s purpose to your team.

The Testing Strategy is an evolving document detailing the processes and ways we are going to ensure the quality of our product going forward.

This is a document that can be used in you day-to-day development cycle inside a project. At this point you can explain more about testing: Test Automation Strategy, Test Plans, Test Approach in bigger detail (defining the testing process, level of testing, roles, and responsibilities of every team member. For every test type defined in test plan (unit, integration, system, regression, etc.)).

III. Test Approach Explaining

So, what is Test Approach? To save your time from reading typical terms from internet, let me simplify this with a single phrase: Test Approach is how the testing will be carried out. To make it clearer, let’s compare these terms: Test Approach and Test Strategy. Test Strategy – is what we are going to test; what resources do we need and risks to avoid. On the other hand, Test Approach – is how we are going to test; a list of test scenarios to cover.

Typically used are these two approaches – Proactive and Risk-based:

Proactive — This means that the test design process is initiated as early as possible in order to find and fix the defects before the build is created.

Risk-based testing is the idea that we can organize our testing efforts in a way that reduces the residual level of product risk when the system ships. Risk-based testing uses risk to prioritize and emphasize the appropriate tests during test execution.

IV·Test Process Explaining

The typical Test Process include the next steps:

• Planning (determine the scope)
• Analysis and design (test conditions, design the tests)
• Implementation and Execution
• Reporting

To summarize all of the above, for a QA Engineer this translates to the next to-dos: begin with planning, then start working on the documentation, test cases creation, and process ends with execution, reporting, and retro.

Another point of the Test Process is to define who is responsible for each type of Test Level (e.x. It can be that developers are responsible for integration and load test, and QA cover end-to-end tests) and define the QA Automation Strategy.

Project Responsibilities is one of the important things affecting its success. In current software development projects everyone is a part of a big system. So, take into account the fact that each team member is a tester, and the QA Engineer is the main expert of the product’s functionality and the system’s stability. Main mission – prevent bugs and satisfy the final customer with a bugless and efficient final product.

Interaction between members – here one of the most useful techniques is the Three amigos agile approach.

Collaboration between Business, Development and QA

1. Business — What problem are we trying to solve?
2. Development — How might we build a solution to solve that problem?
3. Testing — What about this, what could possibly happen

V·Documentation

In the current realities, almost everyone is working on Agile Scrum methodologies, with 2 weeks Sprint iteration, etc.. So it’s very recommended to have a well done documentation where each step of day-to-day work is described. For example, detailed workflow, including definition of done of issues, QA workflows, common glossary of project terms, etc.

In conclusion I’d like to say that you should care about Documentation, all should be up-to-date. Also, communication is always the key, explain to your colleagues a wonderful world of testing, and don’t hesitate to ask them questions. That’s all folks 😉 Happy Testing.