Intuitive testing. How to find a tricky bug?
“Ad hoc testing is a program used for software testing without planning and documentation”
')
I often hear from people close to software development, but far from testing phrases like: “all testers are zadroty”. This opinion was probably due to the fact that we, testers, have to do routine work most of the time, for example, compiling and analyzing hundreds of similar test cases and then passing them, at best, before each release, or conducting an acceptance test. every time a new build comes out. Such work is characterized by a clear definition of the testing process, i.e. took case number 1, reproduced the procedure, put a mark on the passage, took case number 2, etc. No creativity and self-step left-right = shooting.
Thus, this routine cannot fail to oppress the healthy and young brain of the tester, who, while getting a job, read on the Internet that “testers are creative people”, and then exploring comes to the rescue, namely ed hoke testing, the randomness of which is explained by the free search for bugs I want to click there, I want to come here, but I want to play around with the database, and at first glance, here it is creativity, but not everything is so simple. I think that any more or less experienced tester before testing any functionality in his head makes up a test plan and all the same test cases No. 1-100500, which otherwise would have been written, and only after that starts work. By this I explain the prefix "pseudo." Thus, the alternation of intuitive testing with the passage of test cases allows you to relieve stress from the brain.
Every tester should at least know his project. With the advent of the new tester, the question arises: “How can I teach him to know the project?”. In some companies, the tester is immediately thrown into the battle - they give a couple of hundred cases for execution. Indeed, why teach if everything is already written in the procedures. Thus, the company acquires a "monkey" for 3-5 months, until it passes most of the test kits. After this, the tester knows the project well enough to perform other functions besides playing back steps. Let's imagine that the same tester instead of passing cases, a week (40-50 hours) should randomly search for bugs where he wants, in parallel reading specs and dizdoki about objects of interest to him. Within a week, our tester will know 70% of what he would have learned while passing cases for 3-5 months.
For example, a player writes that his client has fallen after studying the “Habrahabr” spell. The simplest playback procedure will look like this:
1. go to the tower of magic
2. learn the spell "Habrahabr"
Expected result: the client crashed down.
Actual result: spell learned.
What to do if the bug is not reproduced, but we trust the player? You can ask to remember everything he did the last 15 minutes before the fall. 80% that he does not remember. Then only Ed Hoke remains. Under the motto: “reproduce at any cost” we open the client and storm the brain with all sorts of algorithms for user behavior. Total: after 2-100 hours, the bug is reproduced, and the player's ears are burning in proportion to the number of hours spent. And the bug turned out to be simple: a stable client crash on computers where Skype was installed, while receiving a message in icq6.
Advantages of intuitive testing:
1. "Pseudo-chaotic" testing
')
I often hear from people close to software development, but far from testing phrases like: “all testers are zadroty”. This opinion was probably due to the fact that we, testers, have to do routine work most of the time, for example, compiling and analyzing hundreds of similar test cases and then passing them, at best, before each release, or conducting an acceptance test. every time a new build comes out. Such work is characterized by a clear definition of the testing process, i.e. took case number 1, reproduced the procedure, put a mark on the passage, took case number 2, etc. No creativity and self-step left-right = shooting.
Thus, this routine cannot fail to oppress the healthy and young brain of the tester, who, while getting a job, read on the Internet that “testers are creative people”, and then exploring comes to the rescue, namely ed hoke testing, the randomness of which is explained by the free search for bugs I want to click there, I want to come here, but I want to play around with the database, and at first glance, here it is creativity, but not everything is so simple. I think that any more or less experienced tester before testing any functionality in his head makes up a test plan and all the same test cases No. 1-100500, which otherwise would have been written, and only after that starts work. By this I explain the prefix "pseudo." Thus, the alternation of intuitive testing with the passage of test cases allows you to relieve stress from the brain.
2. Forced training of new employees
Every tester should at least know his project. With the advent of the new tester, the question arises: “How can I teach him to know the project?”. In some companies, the tester is immediately thrown into the battle - they give a couple of hundred cases for execution. Indeed, why teach if everything is already written in the procedures. Thus, the company acquires a "monkey" for 3-5 months, until it passes most of the test kits. After this, the tester knows the project well enough to perform other functions besides playing back steps. Let's imagine that the same tester instead of passing cases, a week (40-50 hours) should randomly search for bugs where he wants, in parallel reading specs and dizdoki about objects of interest to him. Within a week, our tester will know 70% of what he would have learned while passing cases for 3-5 months.
3. The main advantage of the method is the ability to search for “cunning, insidious” bugs that are not only difficult to reproduce, but it is not known how to reproduce them.
For example, a player writes that his client has fallen after studying the “Habrahabr” spell. The simplest playback procedure will look like this:
1. go to the tower of magic
2. learn the spell "Habrahabr"
Expected result: the client crashed down.
Actual result: spell learned.
What to do if the bug is not reproduced, but we trust the player? You can ask to remember everything he did the last 15 minutes before the fall. 80% that he does not remember. Then only Ed Hoke remains. Under the motto: “reproduce at any cost” we open the client and storm the brain with all sorts of algorithms for user behavior. Total: after 2-100 hours, the bug is reproduced, and the player's ears are burning in proportion to the number of hours spent. And the bug turned out to be simple: a stable client crash on computers where Skype was installed, while receiving a message in icq6.
Source: https://habr.com/ru/post/102403/
All Articles