James Whittaker's Software Testing discipline (II.)

Excerpt from Exploratory software testing (note: The author has written a software test discipline that mimics the tone and content of the Ten Commandments of the Bible)

1. You apply a large number of input repeatedly temper your application

2. Thou shalt covet the application of thy neighbour

3. Thou shalt seek the wise prophet himself.

4. Thou shalt not worship the failure which cannot be reproduced

5. You should respect your model and automated testing

6. You should use the fault of the developers to oppose them

7. You should be addicted to the murder application (Celebrate blue screen bar)

8. You shall maintain the sanctity of the Sabbath (referring to the time of product release)

9. You should covet the source code of the developer

The following is mainly from the "exploratory software testing", I based on my understanding of some of the content has been slightly modified

3. Thou shalt seek the wise prophet himself.

As we all know, there are at least two parts of the test. First we use the input data, and then we check the results. We enter the data into the software, and then test whether the software responds to these inputs in the way it has been established. If we are unable to validate the results, the tests will not be effective.

With regard to the so-called wise Prophet, we are interested in "does the application run as intended after some tests have been applied?" ”。 This requires a clear understanding of the behavior of the program, given a particular combination of input and environmental conditions, by our Prophet (the benchmark for testing). (Bloggers understand that in order to know beforehand what the test you are going to expect, the blogger is more inclined to call this prophet the desired result.) If you don't know what you're expecting, you won't be able to tell if the program is returning the correct results. ）

Automating test baselines is a difficult thing to do, but it's worth the most, because it's not just about creating a valuable test tool, it's also a process of inspiring wisdom. By automating the activity, you get a smarter tester. Whether you end up successfully automating your test benchmark and forcing yourself to think like it, it's often more productive than anything else you might choose to do.

4. Thou shalt not worship the failure which cannot be reproduced

We've all been in this situation, haven't we? You encounter a flaw, which is usually a good flaw, but it cannot be reproduced. The better the defect, the worse you feel. I've seen a lot of good testers who have spent hours and days trying to recreate a flaw that they've only seen once.

Attempts to reproduce such a flaw are often heroic, but without the right tools, these attempts can only be a waste of time. What I saw was that time was wasted and the testers didn't realize it. I've seen a tester spend a whole day trying to remember the repro steps of a crash defect, but it didn't work. I prefer the tester to spend his time in other better places. Like any other tester, I fully understand the feeling of frustration, but the result of finding such a flaw is often the inability to make the best use of time.

The educational significance of this commandment is twofold. First, try your best to note and remember (or record) the test steps taken on the software, while remembering the application's response. Second, consider using a debugger to track actions and software status tools. This will remove a lot of guesswork when reproducing defects and prevent good testers from violating this discipline.

Bloggers understand: Throughout the full text, the educational significance of this commandment should be threefold, the last author mentioned earlier, but did not write in the final induction

1. Efforts to record steps and results

2. Use tool assist as much as possible

3. If it is too difficult to reproduce, do not waste too much time on it and devote your time to other more efficient tests. This is a better choice for the overall project.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

James Whittaker's Software Testing discipline (II.)