For the first time, I saw the concept of “de-QA” in an article. At that time, I looked at it casually without paying more attention.The second time I saw more senior colleagues in the QA community group talking about “de-QA”. At that time, in my little head, I felt that “de-QA” is still a little distance from me.
Never imagined! It didn’t take long for me to go to a project, TL told me that some of our projects did not have QA. There was a QA next door project team, but there was no special test stage in the entire development process.After listening, my eyes were staring like a copper bell (exaggerated rhetoric): But who will do the test strategy? What stage to test the card? When do we do an exploration test? TL took into account my dignity as QA, and immediately emphasized: “I think QA is still very important, I am opposed to them! It’s dangerous!” However, her kind comfort did not smooth my shock and dispel my thinking. This time I know that “de-QA” may really come.
What can I do in the “de-QA” project to provide value for the team? I came to the project with such thinking and got some of my own thinking.
Test strategy
To formulate a test strategy according to local conditions, this is a thing that QA must do when new projects must do. After understanding the context of the project, we need to do this in time, and its priority is very high. Test strategy is a very important guidance. It covers function, performance, Accessibility, compatibility, security, etc. What to test, and also clarify the question of how to test. In the agile development process, it is recommended that you refer to the “Four Elephant Limits of Agile Test” to think about designing your own test strategy.
If this project is not a new project, and already has a ready-made test strategy, we need to understand the current test strategy when joining the project. After a deeper understanding of the project background, technical architecture, and software functions, we will see whether need to improve the current test strategy. The test strategy of each project should actually follow the project changes.
Quality built-in
Why should QA promote quality built-in on the project?
First of all, do we think that the defect is tested? No, it is generated during the production process, so we need to improve the quality of the product during the production process and reduce defects.
In the process of agile development, we have the needs of demand analysis, architecture design, Kick off, Desk Check, and QA. The quality built-in is actually requiring us to do a good job of quality guarantee for each link, and to avoid defects.Discover defects, not to find all defects in the test session, and then repair it. The later the defects were found, the higher the repair cost. The more defects, the more likely, the more defects.
We need a quality assurance strategy at each stage, and everyone in the team needs to be responsible for quality. For example:
- In the demand analysis stage, writing cards need to abide by the INVEST principle, and the team needs to reach an agreement on the understanding of demand.
- In the development stage, we can use Pair, TDD, QA and Dev pair to write unit tests, clarify requirements in time, etc. to ensure the quality of the development stage.
- In the testing phase, we can find defects in time through adequate test design, exploratory testing, and more complete automated test coverage.
- In addition, The quality built-in also includes other aspects, demand management, risk management, and improving the team’s quality awareness.
Automated test
Develop an automation testing strategy and agree with the team. Build an E2E and API automated testing framework, write automated testing code, and often brainwash project partners (I am not, I don’t) about the importance of automated testing, and gradually improve the automation coverage of the project.
In addition to automated tests such as UT, E2E, and API, in fact, any frequently repeated actions can be automated, such as preparing test data and repeatedly filling in lengthy forms. Automated testing can reduce manual repetition and liberate part of the QA workforce, and the timely feedback of automated testing can make the team and customers more confident in product quality.
Test left shift
Requirements analysis is a very important part of the development process (not limited to agile development). QA should get involved in requirement analysis earlier, pay more attention to business requirements, and analyze the rationality of requirements and some boundaries from the unique perspective of QA. Scenes. In the demand analysis stage, communicate more with customers to understand their real demands. Work with BA to complete card writing and supplement business scenarios. And try to determine which testcases of this card need API automation coverage, which ones need e2e automation coverage, and which ones need UT test coverage before Kick off.
Before the story card enters the development stage, through various methods of face-to-face communication, ACs, and testcases (according to your own project situation), determine and clarify requirements and reach a consensus. Reduce problems caused by unreasonable requirements, insufficient requirements analysis, and inconsistent understanding of requirements.
Keep improve
At the beginning of a project or in a chaotic period, QA always has a lot of important things to do, as mentioned above, formulate test strategies, improve automation coverage, improve the quality awareness of the team, and so on. However, when the project enters a stable period, the team members already have a better quality awareness, and the test coverage rate has reached a higher standard. What can we do at this time?
First of all, we know that quality built-in is a continuous long-term concept. After everyone adapts to the quality responsibilities of each role in each process, QA needs to keep observing, remain sensitive to quality protection work, and continue to promote quality built-in;
In addition, after the release of the new version, collect user feedback through User Testing, or analyze the behavior of end users, collect and analyze data in the production environment, and continue to improve;
QA also needs to collect online questions and UAT questions, conduct defect analysis, and organize a team to jointly formulate a quality improvement plan. During the evolution of the project, we continue to think about whether we need to improve our quality assurance plan and testing strategy.
Quality built-in and highly automated testing occasionally make us seem to no longer need QA, but who will do the built-in quality? Who will output the quality assurance plan? Who will write the automated test? Who will do continuous improvement? It’s QA, or someone who plays the role of QA.
In conclusion
To sum up, in fact, there are many things that QA can do on the project, including but not limited to:
- Formulate test strategy, clarify test scope and test method, which is an important guidance for team test work.
- Built-in quality, built-in quality into each stage of development, leading team members to pay attention to and improve quality together.
- Automated testing, gradually build automated testing coverage at all levels, and improve the effectiveness of automated testing.
- Move the test to the left, advance the test activities to the requirements analysis stage, and reduce the quality problems caused by unreasonable requirements.
- Move the test to the right, pay attention to the quality of the production environment, analyze the data, problems and feedback of the production environment, and find more directions for quality improvement.
- Continuous improvement, maintain sensitivity to quality, continuously observe the areas that can be improved in the project, and continue to promote quality built-in work.
In addition to the above points, QA can also pay more attention to improving performance and facing customers.
In my opinion, the so-called “de-QA” just removes a single QA role in some projects, but there will always be someone wearing the QA hat, or everyone wearing the QA hat, and everyone has a high This is actually the Utopia of QA.