Quality build-in depends on the consciousness and ability of all team members. The ultimate embodiment of the tester’s value is team empowerment. It can be started from multiple dimensions and output continuously for different roles at different stages of the product life cycle, so as to form the scale of quality thinking and fundamentally achieve quality build-in.

“In the context of my project, there wasn’t much for testers to be able to do, and the time between the test and the launch was so long that testers felt worthless.”


“The test threshold is relatively low. No matter how good the technology is, the test is not as good as the development technology. What is the value of the tester?”


“Delivery is the end of the product life cycle, and testing is the end of the end. Good software gets everyone’s credit, but bad software gets put out the fire, which is unfulfilling.”


“Now that the big factories are laying off their testing departments, the testing work is being distributed or outsourced. Where is my core competence as a test?”


“Technology is changing, the testing industry is changing, and the requirements for the depth and breadth of knowledge of testers are increasing. How can I increase my value?

These questions come from different testers. If you’re reading this and you have the same questions, please join me on a journey of value discovery as a tester. Whether you’re in a waterfall or agile development model, testers can empower teams at three levels: requirements level, implementation level, and organizational level. Let’s explore them one by one.

Requirements layer: Tests are requirements

Why do you say “tests are requirements”? One of the practices of quality built in is to move testing to the left. In order to achieve lower defect repair costs, testing needs to be involved in the requirements introduction phase, that is, testing against requirements. In the whole process of requirement generation, testers can participate, output their own ideas, contribute their own business context and test thinking, and this behavior may have a direct impact on the final content or form of the requirement, so we can say “test is requirement” to some extent.

So how can testers help the requirements express themselves correctly throughout the requirements generation phase? There are many specific practices:

  • For example, when the demand is not clear, it can help the business or product to sort out the existing logic and put forward the expected demand.
  • During iteration planning meetings and card launches, help supplement acceptance criteria and supporting requirements, or suggest improvements to interface interactions and user experiences.

For a joke, imagine a scenario like this:

The girl friend said, “I’m thirsty.” It was a need that was put forward.


You: “Drink more water.” No desire for life (” Two golden orioles sing green willow, I have no girlfriend ~ “this situation is not discussed, the tester will also help to clarify the scope of the need)

If there were a tester, he would think, “Do you think she said she was thirsty, but she was really thirsty?” “And he would ask,” Under what circumstances did she say she was thirsty?” And at the same time the brain branches:

  • Case1: Really thirsty, just want to drink water. Drink plenty of water.
  • Case2: I’m a little tired of shopping. I just walked to the Starbucks. — Honey, a vanilla latte with a half sugar. (Not only meet the needs, but also understand the preferences, experience bonus)
  • Case3: I feel a little nervous before the interview. Come and have some mineral water (hands it over and unscrews the lid). My little fairy is the best.
  • Case4: You’re not together, and you know where she is. — You love to drink XX milk tea is already on the way, take good care of yourself, I’m busy to find you.
  • Case5: You’re not together, and you don’t know where she is. Negative desire for life, let her go.

After you reply to the context, the tester selects the appropriate path to return to you.

Let’s take a look at what the tester did during this process:

  • Requirements clarification – analysis of requirements background based on business context;
  • Analyze the existing logic — propose the irrationality of the existing logic;
  • Propose expected requirements and supplement acceptance criteria — for different acceptance criteria in different demand contexts;
  • Put forward supporting demand — hand over unscrew the bottle cap, order delivery service;
  • Focus on the user experience — just the right amount of empathy and guidance.

It’s a joke, but it’s a simple joke that illustrates the value of testers in expressing, translating, and delivering requirements. When he does this (sometimes even subconsciously, with the unique sensitivity of the tester), he not only helps the team avoid waste and rework caused by misunderstanding requirements, but also allows other members of the team to Get to the point that he cares about, thus gradually establishing the Sense of requirements testing. This helps the user or customer express exactly what functionality he or she wants, which demonstrates the enabling value of the tester at the requirements level.

Implementation level: Test as a Service

The term “Testing as a service” does not mean TaaS (Testing as a service) in the broad sense. In fact, to some extent, it is also called TaaS (Testing as a service), but it comes from the internal service. What “test as a service” means here is that the tester provides a test service, or test infrastructure, as a result of enabling it at the implementation level.

For example, when we want to implement the requirement card is:

During the card opening process, the tester may ask the following questions:

  • “Is there a status sign if a car has a safety seat? Is there a status indicator that an order has the baby travel option checked?”
  • “Does the card include a match for the vehicle you ordered? Does it include a display of order status updates?”
  • “How do you match nearby vehicles? What is the nearest matching algorithm, and what is the core computing logic?”
  • “During acceptance, please demonstrate that the vehicle matching fails, and whether the baby travel option is ticked when the system automatically reorders.”
  • “Please test all branching scenarios.”
  • …

Two days later, the developer finished the coding implementation and asked the tester, “I have written the code and want to test myself. How can I quickly generate the order?” The tester throws in a data generating SQL script/interface/tool that tells the developer how to build the test data, and reminds the developer to pass certain test cases, otherwise, it cannot be stuck.

During the card opening process, testers participated in technical discussions, supplemented unit test points, and provided acceptance use cases. After the implementation of the code (or at different stages), the test data, test cases, test scripts, or tools provided by the tester can help the developer to complete the test more easily and easily, and at the same time, it can also cultivate the testing awareness (never get stuck in the accident). This is where the value that testers enlist at the implementation level is reflected.

Organizational level: Tests are assets

This is easy to understand.

  • First, testers will conduct quality analysis, provide test reports, analyze the changing trend of software quality, analyze the development efficiency of the team, propose improvement items and follow up on unreasonable waste in the process, so as to make the team work more agile.
  • Second, testers will expose risks in advance, give early warning of risks, and put forward quality expectations based on objective conditions to help the team build quality confidence.
  • Third, testers accumulate a lot of business knowledge, both at the macro level and in the details of the business, testers know the products they have tested very well and are often more likely to become domain experts. Accumulation and precipitation in this process are both tangible and intangible assets to the organization. This is the value that testers empower at the organizational level.

Total knot

According to the Buddha, there are eight pains in life: “birth, aging, sickness and death, love and parting, not being able to seek, hatred and hate, and not being able to let go”. Isn’t all the pains caused by the inconsistency with the expected results? Is how to make a study to test engineer to this role, and the expected result is consistent, we can take all kinds of practice, the use of various tools, various roles, to help them better express expectations and achieve expected, verify the implementation of the results are consistent with the expected, and the process of record and we strive, settle our condenses the knowledge of wisdom. Just don’t be too valuable!

This article is dedicated to all struggling in the field of testing partners, let us the world of mortals company, happy enmity. I’m QA and I’m proud.

Question for Thought: What do you think is the ultimate value of testing? What is most important to you? Why is that?

Source: Sweet dream workshop of small round beans


Author: Yu Xiaonan


Disclaimer: The article was forwarded on IDCF public account (devopshub) with the authorization of the author. Quality content to share with the technical partners of the Sifou platform, if the original author has other considerations, please contact Xiaobian to delete, thanks.

June every Thursday evening at 8 o ‘clock, [winter brother has words] happy a “summer”. The address can be obtained by leaving a message “happy” on the public account

  • 0603 invincible brother “IDCF talent growth map and 5P” (” end-to-end DevOps continuous delivery (5P) class “the first lesson)
  • 0610 Dong Ge “Take you to play innovative design thinking”
  • 0617 “What is Agile Project Management?”
  • 0624 “Agile Leadership in the Age of Vuca”