QA 101: how to manage product quality right from the start
Being the only Quality Assurance (QA) manager on a project is challenging. If you are the only QA and the project is brand new — it may be an unbearable combo. Still, even such a project can pass smoothly if you know how to act and what to look at. You need a good action plan.
This post — based on the experience of QA engineer Olya Kolyada — provides a simple set of instructions to start a project and survive it. You'll also learn what blockers you may stumble upon in the process and how to avoid these obstacles.
QA at the start of the project
It’s common knowledge that it’s better to assign a QA to the project as soon as possible. The attentive eye and sharp mind of a QA engineer can greatly help the team from day 1. Here are just a few advantages:
- The QA will be introduced to the team and the customer right away and will be able to describe the QA's importance on the project.
- QA presence at the meetings to discuss design, deadlines, technical realization, and requirements will help to cover some controversial issues and take testing into account to set realistic expectations.
- QA will help with thorough preparation for future reviews and extensive testing. It will give more time to think over test cases and checklists, prepare complete test documentation and conduct requirements testing.
- In the early stages, QAs can organize their work based on their working routine. It’s an inspiring part of the job that tests their strengths by setting up QA processes, prioritizing test cases, and making choices in testing methods. Of course, if necessary, there will always be a mentor and PM nearby, so QA can safely turn to them for help.
As you can see, the advantages to introduce QA to the project early are numerous. So what exactly must your QA start with?
Organizing QA work
Set up and follow a list of steps to begin working on the project. It will help your engineers to be more confident and to better understand their work. Here’s the process we use:
- Stage 1: Learn and ask questions
- Stage 2: Document and plan
- Stage 3: Be prepared and think it over
- Stage 4: Test and show your results
🎁 Bonus — find the full step-by-step checklist at the end 🎁
Imagine you just joined the team, were introduced to your teammates, and learned the name of the project. Your next step is to review the existing documentation, understand the goals of the project, and start asking questions. The answers may be not needed at this exact stage of product development, but you will need them later during testing. Start with these steps:
1. Listen to a project manager’s (or PdMs, or BAs) presentation about the project. After the presentation, it will be way easier to navigate the project documentation and see what’s missing.
2. Review the existing requirements and other documents about the project. Such an information hunt will help you understand the product faster. Start with sources created right at the beginning of the project because they can provide you with context and the initial goals.
It’s important to check all the details, no matter if it's formal documentation, the product itself, or similar products and competitors. Note any inconsistencies in the information, so you can sort them out later. There is no need to plan how exactly the testing will take place yet! It’s more important to build initial models of what needs to be tested and what may be important to evaluate the quality of the product.
Later, these sketches can become the basis of the future QA vision. If you’re a visual person, you can present future testing ideas and various related blocks of the project in the form of mind maps with the help of services such as Miro or Mindmeister.
3. Get acquainted with the founders to show them what you are going to do on the project and find out their testing expectations. This step is optional but preferable.
To some founders, it’s important to meet the whole team, find out all the details for each stage of work, and delve into all the complexities. For others, brief reports are enough. Still, if you have the opportunity to meet them and briefly explain what exactly you will do on the project, be sure to use it.
Closer contact will allow you to clarify very important points for your work in the future such as priorities, testing deadlines, overall project deadlines, defects, and gaps in requirements. Speaking directly also helps you to avoid any possible miscommunication issues. Of course, if communication with founders is limited, you still will be able to receive all the details from PM and BA.
4. Discuss the project’s timeline, testing deadline limits, priorities, and possible risks.
Most likely there will be several meetings, and you, as a QA, will be protected by your team and allowed to skip some discussions. But if you have free time, it’s better to join the discussions to understand the full scope of the project.
In the second stage, the QA needs to work on project documentation.
5. Write a QA vision.
Let’s assume that from now on all the necessary information for the QA vision will be in your hands. If some issues on the project — exact priorities or deadlines — are not yet completely clear, you can add them later.
The main goal of the QA vision is to gather all the detailed information about the project to help choose the right approaches for organizing testing and working with the founder. The QA vision may serve as a full-fledged replacement for a test plan, if, for example, the project is short-term. Remember, once written, the document must be reviewed and approved by the PM and stakeholders.
6. Create a testing strategy and plan.
At this stage, you should have a good understanding of the project, its architecture, and its domain. It's time to understand how exactly you will perform tests. Return to your notes and decompositions that you made while studying the project documentation. Perhaps it will make sense to add and supplement something. Thanks to these entries, you will be able to compile and prioritize a list of modules that will be tested later or will be excluded from the scope of work. The allocated testing scope must be confirmed with the PM.
You will also need to form a testing strategy to determine the approaches, and the depth of testing to highlight the necessary techniques. Review and form the limitations and risks of the project, create strategies for their resolution, determine the criteria for starting and ending testing, and criteria for evaluating the results. This step may already be part of the next one, writing a test plan. However, if you are working on a short-term project, the test plan can be skipped.
Finalize the scope of work and strategy.
7. Write a test plan.
If you’re working on a long-term project, writing a test plan is mandatory. In the end, it will become the main document regulating the work of the QA team on the project. The purpose of the document is to provide a general plan to conduct testing, based on the system requirements, processes, and other important features of the project. Details of the plan may depend on the context of the project and the requirements of the customers.
Remember that the test plan is more dynamic than QA vision, and can be changed during the life cycle of the project. It is also subject to agreement with the PM, founders, and the whole team.
It’s finally time to prepare for the actual development stage!
8. Prepare all the necessary tools and environments for testing.
First of all, you need to prepare and verify all your management tools. Will you have Jira, Trello, or Linear? Then prepare the test management tools, and documentation tools (Sitechco or Notion?). Is there anything else you need? Are there any problems with access? Are all the documents you’ve created already placed in the right sections?
Make sure that you have installed the browsers and tools necessary for testing, such as Postman. You will also probably need a database, so set up your access in advance. Check that the test environment is stable and ready for you to actively use it.
9. Analyze and design all the necessary test cases and checklists.
Based on the priorities and strategy that you thought through and possibly described in the test plan, it should be easier to determine where to start and how to design tests. Depending on the duration of the project, its specificity, and other factors, you will need to choose the preferred format — test cases or checklists.
Remember to properly break tests into chunks and assign them the correct priority. In addition to checking the new functionality, you will need to generate test sets for Smoke, Basic, Regression, and Sanity tests (if this is relevant to your project).
If you find defects in the requirements when designing test cases, you need to report them in the bug tracking system in the same way as ordinary defects.
In addition to test documentation, you can work on a requirements coverage matrix that helps to trace test scenarios to functional requirements and ensures that all requirements have appropriate checks. However, the coverage matrix will only be relevant if the requirements are fully covered.
Everything is ready for the testing process. Always look into the documentation you've created, make changes when needed, and ask the right people the right questions. It’s all that matters to do it properly. The only step we need to cover more is reporting results.
10. Create reports on intermediate results and share them with the team and stakeholders.
At the very first stage, when meeting with stakeholders, it would be nice to clarify with them what kind of information they need from you and how often to provide it. Without waiting for an answer, you can initially offer a specific option yourself, for example, monthly or weekly QA reports, Regression statuses, and Root Cause Analysis of defects in production. Perhaps you will be asked to provide some information by the founders themselves.
If you are given the freedom of choice, then it’s better to decide first on which reports you will work on and how often. As a result, all QA Reports must be provided to the team and customers.
Possible difficulties and solutions
Problem 1: Not enough detail in the project documentation, and much is still unclear.
What do you do if some details of the project are clarified on the go? Follow the steps above, but perhaps in a slightly different order, or repeat some steps twice. For example, editing and adding something to the documentation when more details become available.
Be sure to write down all open questions and clarify them afterward. Do not forget to mark the current gaps in the project with the TBD (to be determined) comment, so that you can quickly find and add them later.
Problem 2: Founders have almost no contact with the team or contact the team rarely via PM only.
It’s better not to simply wait if stakeholders take a long time to answer important questions about deadlines, priorities, and requirements.
Check everything you can with the project manager. Voice your decisions on strategy, documentation, and reports to the team and mentor. Collect important questions in a group and send them to stakeholders to get answers to all questions at once — this option is always better than asking one question at a time.
Problem 3: No requirements or incomplete requirements on the project.
Rely on design and mockups for the test documentation. Also, your experience and logic can help you to solve this particular problem — you can probably guess what results to expect with specific checks. If you know the competitors, then you can analyze them to better understand the future logic of your project.
Problem 4: The project is complex and there is a fear of not figuring the testing out.
Always start with a self-study — find available information, make important notes, and mark all the questions to return to them later. It is also important to consult with developers and learn the details of feature implementation and integrations. Have a call with your PM, PdM, and BA to discuss technical requirements in more detail.
The main thing to remember is that you are not alone! Your team and your mentor are here to help you. There are no problems that can’t be solved.
It’s always important for a beginner QA to become confident on any type of project no matter when the QA is assigned to it. The bottom line is to read, listen and ask questions to get it done right.
To start working on the project, QAs can always follow these steps:
[ ] Listen to the project presentation made by PM/BA
[ ] Get to know your team
[ ] Get to know your founder/stakeholders
- [ ] briefly describe your work (if needed)
- [ ] agree upon the timing and content of QA Reports
[ ] Begin studying project information
- [ ] test requirements and study mockups
- [ ] decompose a system into logical chunks
- [ ] build a model of interactions for these chunks (if needed)
- [ ] participate in grooming with the team, and discuss the requirements with BA
- [ ] create a list of all unclear issues and questions being missed
- [ ] check similar projects and ideas
- [ ] sketch out a list of future test cases and checks
[ ] Participate in organizational meetings with a team
[ ] Write QA Vision
- [ ] send QA vision to the team, stakeholders, and mentor for a review
[ ] Form a testing plan and strategy
- [ ] discuss your ideas with the team, mentor, and customers
- [ ] write a test plan (if needed)
- [ ] send test plan to the team and stakeholders to review (if needed)
[ ] Prepare and configure the necessary tools for testing
- [ ] check if the testing environment is ready
[ ] Design all the necessary test cases and checklists
- [ ] group all checks into sets
- [ ] create a coverage matrix (if needed)
[ ] Prepare templates to use later for reports
- [ ] send reports to the team and stakeholders on time.
Thanks for reading and we wish you a great project start as QA!