Project management
Raiting:
3

Testing - this is not a search for bugs!


Many people believe that software testing is the search for the bugs. Sometimes, I say to testers, "Do not try to find as many errors as possible, try to miss as less as possible!” and they do not understand me. What's the difference?

There is a huge difference! In this article I want to tell you about that difference, and what tools you need to use for a useful troubleshooting.

What is troubleshooting?



I'm testing the product. My task is to get as many bugs as possible. It's logical! Locating bugs is always nice for a tester, this is apparent measurable work result, and more bugs I find, the more I am appreciated as the tester.

What areas will I test it in this case? First of all, I will test the most unstable. Often they are unstable, because they have the lower priority, but that does not matter, much more important is the number of bugs.

What would happen if I run into a replicable bug? ROI is calculated in the mind very quickly on its research. Why should I bother with it if I can find 3 less critical bugs for the same time?

What tests will I run in the first place? Of course, they are going to be the most irregular

I tell you a secret, sometimes, the testers during the interviews when they are asked to test a calculator, they rank interesting and practical tests, but there is not the most important one among them.

That's how a list of errors looks like – it has nothing to do with testing.

What is the testing?


I'm testing the product. My task is to miss as less as possible the priority bugs for the user. The fewer bugs I missed, the less customer dissatisfaction I get, and the more I appreciate its effectiveness.

What areas will I test it in this case? Naturally, I'll start with the highest priority for the user. Even if they are stable and work well, I'm still going to check the main user scenarios, in order not to miss the serious problems.

What would happen if I run into troubles? For example, I will be faced with the replicable bug or lack of understanding of the business process of user, or lack of requirements. If this is an important functional, then I'll find out what is wrong and how to fix it. It may take some time, but I will have more knowledge about the product architecture, and the users.

What tests will I run in the first place? Of course, they are going to be the most standard, for example, the functional. Only after that I will move to less standard scenarios.

Testing and troubleshooting results


In the case of troubleshooting in the short term, the results are above.

In the long term is not so good:
- Lack of knowledge about the product causes growth of % missed defects.
- Development team is busy correcting the terrible and unimaginable bugs obtained by clicking 144 times on the same button.
- There are released some horrible, nasty, and obvious bugs to the user.
- Number found bugs drops in the long term.

How to move from the troubleshooting to the testing?

To have the testing effective and useful in the long run, you need to follow the simple rules and use the key tools for the testing:

1. Product analysis and documentation of test

By clicking on the buttons, you can find a lot of bugs, but you cannot say that everything has been checked. The only solution is to document the tests. Doing detailed test cases takes a lot of time for the testers, and they are very rarely needed. But to make the checklists with the listing are really needed.

What they give:
- You analyze the product writing out key features, activities, and their parameters. Thus, it significantly reduces the risk of forgetting something.
- Checklists are a great reminder for the tester. Let’s say there is an unclear feature with inadequate description. How should it be tested? In testing without tests it is easy to say, "I'll get to that later" and never come back. On the other hand, the tests will remind you that something should be fixed.
- Checklists should be coordinated with the developers and the analysts. The whole team is involved in the process of testing, the testers will learn a lot of new about the product, and collective intelligence improves the quality of testing.

The key to success in keeping of the tests is the creation of guide that you will follow. The purpose is to cover the entire product. And please, do not give any excuses about the terrible resource intensity, because I covered the projects with millions of lines of the code in less than a month and a half.

2. Test evaluation

You should evaluate the effectiveness of testing. You need to analyze the missing errors and their reasons. That is very important!

There is always something to improve, and the lack of a continuous improvement process is the inevitable quagmire.

3. Team discussions about testing goals

Many people believe that the testing has some mythical goals, and they are always the same.

Certainly not!

In each project, the company and a team have their own goals. Do they all understand them in the same way? I really do not know.

To bring the maximum benefit, you must understand this benefit well. You do not be surprised if the views of developers will not match yours. You should not persuade them, but adapt to the current project goals!

4. Understanding of the users and their business processes

It is a mystery to me how this is possible, but nevertheless it is a fact. Often the testers check the product without knowing anything about the user.
- How is this product used?
- Why do we need it at all?
- What problems are solved by the product?
- What conditions are used by the users? And so on.

The testers should know their users well. Often, they are not provided with this information by the analysts. Think again! Without knowing the user, you cannot test the product well.

5. Technical skills and architecture understanding

Here is an example of a bug:
Go to the website of the testing product http:// ****.com in Firefox.
Enter username and password.
Then go from the same computer in Opera.
It asks to re-enter username and password, because it does not login automatically.

Such bugs are not just useless, but they discredit the testers and its industry as a whole! To handle these defects correctly, you need to understand the platform on which is written the testing product. If we are talking about web testing, then at least you can point an error code in a bug-reporter that was returned by the server, and then review the details using a firebug that will save a lot of time for the development!

Conclusion


Many developers do not like the testers. And it is rightly so!

However, the good testers are loved and appreciated by everyone!

You need to learn what is wrong, and what the development team members do not like. Make sure that you analyze the missing errors and never do them again. Your mantra should be "user happiness", "quality product" and "successful project"!

Good luck to you!
Siera 19 october 2012, 15:31
Vote for this post
Bring it to the Main Page
 

Comments

Leave a Reply

B
I
U
S
Help
Avaible tags
  • <b>...</b>highlighting important text on the page in bold
  • <i>..</i>highlighting important text on the page in italic
  • <u>...</u>allocated with tag <u> text shownas underlined
  • <s>...</s>allocated with tag <s> text shown as strikethrough
  • <sup>...</sup>, <sub>...</sub>text in the tag <sup> appears as a superscript, <sub> - subscript
  • <blockquote>...</blockquote>For  highlight citation, use the tag <blockquote>
  • <code lang="lang">...</code>highlighting the program code (supported by bash, cpp, cs, css, xml, html, java, javascript, lisp, lua, php, perl, python, ruby, sql, scala, text)
  • <a href="http://...">...</a>link, specify the desired Internet address in the href attribute
  • <img src="http://..." alt="text" />specify the full path of image in the src attribute