“What do you want for a side dish for the tests?”

Original author: Michael Bolton
  • Transfer
It so happened that the completion of the translation of this article by Michael Bolton successfully coincided with the appearance on the hub of a note by Natalia Rukol, “Why is testing stupid and boring?” which caused quite a heated discussion. This article is intended to explain to some extent why testing alone seems boring, but for other people this is the most interesting activity in the world.

When I was about twenty years old, I decided to quickly learn how to cook deliciously. I found the book "Gourmet in 60 Minutes" by Pierre Freyney, and went to read.

It turned out that Mr. Freini did not describe the technique, but his philosophy of cooking.

Each recipe began with such an exciting introduction that I was more interested in the stories of Mr. Freyney and his knowledge of the dish than cooking. After reading just a few pages, I already learned a ton of new things. And soon I even began to recognize some patterns.

These stories taught me much more than the recipes themselves. Recipes focused on technology, and stories taught skills and made me think.

And Mr. Freini advised me to constantly try to prepare food in the process. Reading and immediately applying what I read in practice, after a few weeks I began to cook much better, even when I did not act directly according to the recipe.

By experimenting and trying the intermediate results, I received immediate feedback about the quality of my dishes.

But other cookbooks left much to be desired. They lacked the personality of Mr. Freyney and they did not convey his love and respect for food. Instead, they contained only recipes, often described very sparingly. Many approaches were heavy, they contained a lot of guidance, but few tips and life experiences. They taught technicians how to put together the ingredients, but not the skills necessary to become a better cook.

A few years ago, James Bach made me think about how testing skills differ from techniques. I thought that most people concentrate on techniques, not skills.

Testing without skills is like working at a counter in a hamburger stall.

You are given a procedure - a technique - which you must strictly follow. You will get the same hamburgers, just the ones you need for sales.

However, software development has never been such a controlled environment, so using a fast food production scheme is not acceptable here.

So what do we do if we don’t have the skills?

Learn :) A

tester without skills can easily test something, but will it have an excellent result? He pushes the buttons, enters some text or numbers in the dialog box, but if he doesn’t have a sense of the goal behind the tests and has no hypotheses about possible errors, he will most likely miss some boundary values ​​that are not so obvious.

He may remember the technique of constructing tests based on state diagrams, but he does not imagine how confusing a state diagram can be even for a simple-looking program.

He may remember about testing automation, but he’s more likely to get stuck on the calculation of test cases than to think about the real value of each of them.

He had heard about exploratory testing, but instead of a targeted search, he would just wander around pointless, and as a result would find the technique itself useless.

But if the tester has the skills:

1. He will begin testing by clarifying the purpose of his work. After that, he will begin to act independently, but in the right direction.
2. If the specification is unclear or unavailable, he will make reasonable conclusions about the product. Common sense has not yet been canceled.
3. He will select and develop tests that identify risks and sort them by importance.
4. It will not be limited only to the specification, but will be able to find other sources that will help identify problems.
5. He will pay attention to other quality criteria - usability, productivity, reliability, testability.
6. Instead of thinking about the abstract "user", he will create a set of different user profiles.
7. He will look at the product as part of a larger system and will think about the goals of testing quite widely.

This breadth is very important.

When thinking about coverage only in terms of code coverage or specification coverage, other important quality indicators can be missed.

Owning only a narrow spectrum of oracle predictors (oracle - the principles or mechanisms by which we recognize problems), you can either exaggerate the importance of some problems or completely miss some others.

Testing, as well as cooking, is what we do to meet the needs of others.

Well, so who do you want to be: a testing chef wisely using the available tools and ingredients, or an ordinary seller who flips “test burgers” on the stove while waiting for new customers?

about the author

Michael Bolton is one of the most active evangelicals of the school of context-oriented testing. He has over 20 years of experience in testing. Michael regularly speaks at conferences, conducts trainings and seminars, since 2005 he is a regular columnist of one of the most popular testing magazines Better Software (where the above article was first published) and has a wonderful testing blog www.developsense.com/blog. shtml

On November 17-18, Michael Bolton will conduct a two-day training session “Rapid Software Testing” in St. Petersburg, developed jointly with James Bach. Details here: habrahabr.ru/blogs/testing/105133

Also popular now: