Agile testing theory and practice-6

[This article is the sixth article of agile Testing Theory and Practice (Article 1, Article 2, Article 3, Article 4, Article 5, Article 6, Article 7 )]

 

 

2. Encoding phase:

After the requirement design stage is completed, it is necessary to beginEncoding phaseAlthough the development and testing needs to be synchronized, but the function has not been completed and cannot be synchronized for testing, but there is still something to do, that is, you can start to write test cases synchronously, this is usedDevtestTool.DevtestIt is mainly used to manage test cases and perform manual and automatic tests in different environments, at different times, and in different ranges based on test cases, you can also generate reports to evaluate the test quality and product quality.

 

 

Some people may have doubts that agile testing still requires test cases? My answer is"Yes"And"No",

 

First,"No"For agile testing itself, test cases are not used in actual test of new functions, but are completely tested according to the design documents. (Some people may ask about agility as if they do not need a test document, this is not mentioned here. For details, refer to my other article "Agile development with tools"). Therefore, test cases are not required at this time;

 

Why does it say"Yes"What about it? Because agile can be implemented in different companies in different situations, our company is not a project but a product, that is, like Microsoft's Windows, our company's products are also 1.0, and 2.0, which is now 9.0. During this period, there are more or less many functions available in different versions, especially the basic functions, to test whether the new functions destroy the original functions, we need to test whether these old functions work normally. Some people may say that I only need to test the old functions when testing the new functions, is the test case unnecessary? Yes, maybe your company doesn't need it, but for our company, especially for 9.0, the features of all previous versions are old functions, and there are hundreds of old functions, thousands. Can you test new features? Obviously, this is very difficult to achieve. When the new functions are completed, the tester usually checks whether they can work normally and whether they have no impact on some basic functions, as for other functions that do not seem to be cool, they are not very concerned, and they are not allowed in time. In this way, test cases are very important, because test cases are essentially about the functional points to be tested and how to test them, each function point of each version is saved as a test case. It is difficult to miss a test point during testing. Therefore, all the areas not tested during the test of new functions can be re-covered during the generation of test tasks using test cases. However, this step takes a lot of time due to the wide coverage of the test, therefore, in general, some test points will run away with automated testing tools, and the other part can only run manually only during the final system test.

 

Read this"Yes"And"No", We should know that our company's" agile testing "is actually combining agile testing with traditional testing, that isSpeed and quality considerationsSo sometimes we call it agile testing with the characteristics of our company.

 

When writing test cases, the tester needs to communicate a lot with the designer to thoroughly understand this function and prepare for the next practical test."Communication"Agile is an important principle. In actual work, we also really experience the benefits of agile. Only through communication can several departments have a high degree of unity of understanding about products, in order to design, develop, and test a good product. However, I think we can only experience it through practice. I have talked too much, but I cannot convince everyone.

 

3. agile testing stage:

 

Now that we have finished writing test cases and several functions of development, we can also start testing. We also talked about how to implement agile development with tools, our company uses scrum, so we will generate a lot of iteration cycles (sprints), and some story will be allocated from the backlog in each iteration cycle. What we test is the story, this is actually a feature.

 

This part of work mainly involvesDevtrackCompleted,

 

 

DevtrackIt is mainly used to develop and complete function point encoding and testers to complete agile testing. After the requirement design is complete, the Project Manager assigns development tasks to corresponding developers through devspec/devplan and generates agile test tasks. Once the function is developed, the corresponding agile test task will be hit in devtrack"Testable"Status. In this way, the tester starts the test. After the test is complete, the task is turned off. Even if the test is complete, the Project Manager checks whether the test task has been disabled to determine whether the function has been completed.

 

Since the testers have already written the functional points in the current iteration cycle as test cases, they have already been very familiar with the functional points they have prepared in theory. Therefore, the testing is just a breeze. Bugs will always be detected during testing, but there are severe and non-critical bugs. The principle for us to handle bugs now is, bugs that affect this function must be fixed in this iteration cycle and next iteration cycle. These bugs may include errors, and the function cannot work completely, it may also include the appearance of some pages, because our products will make regular evaluations for customers to see if the functions they have done meet their requirements, therefore, the customer must be able to use the desired functions at least, so what the customer will use most directly needs to be processed first. For other Common Bugs, devtrack will have a dedicated folder to save. These bugs will be fixed one by priority before release, some low-priority or incomplete tasks may be postponed to the next version or will not be repaired directly, because sometimes fixing a bug may lead to unexpected problems, if you can repair bugs that are not repaired, you do not need to repair the bugs that affect the product quality.

 

I wonder if you have noticed that the bug mentioned above needs to be fixed in this iteration cycle and the next iteration cycle. Why not fix it in this iteration cycle, because testing is always started after development. If a function is completed at the end of an iteration cycle, the test may not be completed in the time, however, the time of the iteration cycle cannot be changed. In this case, we will test this function point in the next iteration cycle. However, in general, we recommend that you do not delay the completion of the next iteration cycle, because after an iteration is completed, we will evaluate a build for the customer, if a function is not fully tested, there may be bugs that may affect the customer's use, which may have a negative impact on sales. Therefore, the solution is to test the function point immediately after the development is completed, and fix the bug immediately. If the function is completed at the end of the iteration, check
The in Code ensures that there are no serious bugs (mainly tables and the most basic use of this function). If there is no check in code, wait until the next iteration cycle to check in code, the test is also postponed to the next iteration.

 

In this way, the iteration cycle is in progress, and the Development has made functional points one by one, and then the tests are completed. In this cycle, the workload of development and testing will be recorded in devtrack, mainly the time spent and the remaining time, so as to get a progress trend chart of the product in the future, that is, the so-called burnout chart.

 

4. demand change:

Agility is welcome to change. Customers can propose improvements at any time if they have any ideas. Our company's products provide customers with a build on a regular basis for evaluation. Therefore, customers often require changes, it is a little better for functions that have not yet been tested, because you only need to modify the design documents, but what has been done or is being tested? The answer is of course we have to make changes, redo well, and test again. This may be hard to imagine for the waterfall model, but it is common for agility.

 

In practice, we may use a devspec function, which is relatively good, so I will discuss it separately. In some cases, if a function has been tested and the change has been completed, how can we notify the tester to test it again? Oral notification? Email? In fact, it is okay. In some cases, there are too many changes, too many people need to be informed, or users who do not know who to notify. What should I do? Devspec has a feature that automatically reminds developers and testers about this feature to let them know what has changed.

 

 

(To be continued)