This article was first published in【Forest space】
“Working software is better than comprehensive documents, which is one of the agile values. Testing does not need so heavy documents, and test cases can not be written.” This is the view of Party A.
“How do you know what to test without test cases? How can you prove what you have tested without test cases? Writing test cases is one of the means to protect QA itself. You should write test cases.” Party B doesn’t think so.
I understand that the test cases mentioned here mainly refer to manual test cases.
01 real agile teams don’t need detailed test cases
Some people always tangle or discuss the form and granularity of test cases. Different teams and companies have different requirements for test cases. Some require particularly strict format, detailed description steps and expected results, while others can simply list checkpoints.
So, does agile QA need to write test cases?
1. Real agile team
I agree with Party A. I think a truly agile team does not need to write manual test cases strictly. This is because:
- QA of the agile team needs to participate in the relevant practice of the left shift of testing, including the intervention from the requirements analysis stage. The test analysis, design and implementation will be the same person. Through a series of practical activities, QA has made clear the points that need to be paid attention to in the process of constantly understanding and clarifying the requirements, which need not be presented in the form of strict test cases.
- A real agile team needs to do a good job in automated testing. There should be enough automated testing to ensure the return of functions. These tests may be unit testing, API testing or end-to-end functional testing. After the user story development is completed, it will not need a lot of manual testing, but more exploratory testing, which does not need to design test cases in advance.
2. Preparation of target driven test cases
Of course, there are very few real agile teams in reality. Is it true that test cases are not needed at all? For teams with low automated test coverage, if a large number of manual tests are still required, test cases may still be required. However, it is not recommended to put forward clear requirements for the steps and details of the test case. What should be written should be based on the requirements, that is, what the use case should be used for and how long its life cycle is. The design of test cases also needs to follow“Goal (demand) driven”Principle of.
According to the target requirements, the test cases can be divided into two categories:
- User story test case
User story level test cases are mainly used to help verify the implementation of user stories. They can be used in the startup, development, acceptance and testing stages of user stories. The life cycle is to complete the testing of user stories, and there is no need to reuse them later.
If the acceptance conditions of user stories are written in the way of instantiation and can basically be used as test cases directly, please refer to the previous article on whether the acceptance conditions can be used as test cases《Business requirements and system functions》。 If the acceptance conditions are not written enough, some edges and corners need to be added. Only some check points need to be added. Generally, it is not necessary to list the detailed operation steps.
Therefore, the user story level test cases do not need to be written too carefully. They can be realized by listing some checkpoints and directly attached to the user story. In this way, it saves time and effort, can briefly and clearly state what needs to be paid attention to, and is more convenient to reach an agreement with different roles.
A special case is that for new graduates, it is generally recommended to write test cases of user stories in detail at the beginning, mainly to practice and get familiar with the business. When you are familiar with a certain degree, you can no longer write very detailed use cases.
- regression test case
Regression test cases are usually not considered at the user story level, but at the feature level. Regression test cases need to be reused, and they usually need to be used by colleagues other than design cases. This requires that the designed use cases have good readability and can clearly express the real business information.
Regression test cases are suggested to be described from the perspective of business and in the form of user scenarios. Instead of describing the operation steps and page Jump of the system, they need to have a certain level of abstraction.
Regression test cases, whether used for automated or manual regression testing, can be described in the same form, and are best managed together, and can mark which cases have realized automated testing and which still need manual testing. Business based use case writing can refer to the article《Speaking of BDD, what do you think?》Description of use case scenarios in. In addition, my colleague Liu Ran has an article《Management of test cases》Introduce the of test cases in detail and recommend attention.
3. The test guide can be used as a supplement to the test cases
Test cases are used to verify the satisfaction of business requirements and the correctness of system functions. Some complex functions and features may also need some guiding documents to tell how to execute the corresponding test cases. For example, some regularly executed tasks have specific trigger conditions, and some data may need to be modified to trigger them during testing. For such features, in the absence of detailed test cases, test guidelines can be used to guide the development of testing.
The test guide here may be the introduction of business process documents related to features, system configuration requirements and other related contents, or some risk points, weak links requiring special attention, related businesses, etc.
Therefore, our team will prepare corresponding test guide documents for complex features and functions that need special configuration to be tested, which will be used in combination with test cases as a supplementary description of test case documents, so as to help colleagues who are not familiar with the context to perform tests more smoothly.
02 agile QA does not need protection
For Party B’s point of view, it’s actually quite ridiculous. Why should we protect ourselves through test cases? Can I say that I have designed enough test cases and passed the implementation, and the quality has nothing to do with my QA?
Anyone who has a bit of common sense will know that this is a fallacy.
- Testing is inexhaustible, and the quality is not guaranteed by testing. This is why we recommend quality built-in and adopt the practice of test left shift and right shift.
If you don’t know much about this, please refer to the following articles:
- On the other hand, in agile team, we always emphasize that the team is responsible for quality. In case of problems, we should not blame a role or person, but review the team as a whole, analyze the root causes of the problems, and discuss the weak links and feasible improvement actions of the team.
If you don’t know how the team is responsible for quality, please refer to the following articles:
- True agile QA should be a quality advocate. Agile QA should not think about how to protect itself, but should take the value goal as the direction, lead the team to assume their own responsibilities for high-quality delivery, and make the real team responsible for quality.
Do you want to write test cases?
I have given the correct practice of agile team, but I can’t give you a final conclusion on whether your team needs test cases, because it depends on many factors. Each team has its own different characteristics. The team will discuss the scheme suitable for itself together, and everyone can reach a consensus.
Of course, I would like to emphasize my suggestion again:
- The writing of test cases should be goal driven, and it is necessary to exist only when they are valuable;
- The preparation and execution of test cases should not be used as the performance evaluation index of QA. Once used as the evaluation index, it will inevitably bring side effects, just like any other evaluation;
- Agile teams should pursue as few (manual) test cases as possible.
Finally, my colleague Zhu Ping disclosed the truth and facts related to test cases in an article, which is highly recommended. Welcome to pay attention to:《Some “truths” and “facts” of test cases》。