It so happened that the completion of the translation of this article by Michael Bolton successfully coincided with the appearance on Natalya Rukol 's Habré article “Why testing is 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, I decided to quickly learn how to cook deliciously. I found the book “Gourmet in 60 Minutes” by Pierre Freini, and went to read.
It turned out that Mr. Fraini described not his technique, but his philosophy of cooking.
Each recipe began with such an exciting introduction that I was more fascinated by the history of Mr. Freini and his knowledge of the dish than cooking. After reading just a few pages, I have already learned a lot of new things. And soon I even began to recognize some patterns.
These stories have taught me much more than the recipes themselves. The recipes focused on technology, and the stories taught skills and made me think.
And Mr. Freyne advised to constantly try preparing food in the process. Reading and then applying what I read in practice, after a few weeks I began to cook much better, even when I did not act directly on the recipe.
Experimenting and trying intermediate results, I received immediate feedback on the quality of my dishes.
But other cookbooks left much to be desired. They lacked Mr. Freyney’s personality and did not convey his love and respect for food. Instead, they contained only recipes, often described very sparingly. Many approaches were heavy, they contained many guidelines, but little advice and life experience. They taught technicians how to put together the ingredients, but not the skills needed to become a better cook.
A few years ago, James Bach made me think about how testing skills differ from tech. I thought that most people concentrate on techniques, not skills.
Testing without skills seems to work behind the counter in a stall selling hamburgers.
You are given a procedure - a technique - which you must strictly follow. You will get the same hamburgers, just those that are needed for sales.
However, software development has never been so controlled environment, so the use of fast food production scheme is unacceptable here.
So what do we do if we don't have the skills?
A tester without skills can easily test something, but will he have an excellent result? He presses the buttons, enters some text or numbers in the dialog box, but if he doesn’t have a sense of purpose behind the tests and there are no hypotheses about possible errors, it’s most likely that he will miss several boundary values that are not so obvious.
He may remember about the technique of building tests based on state diagrams, but he does not imagine how confusing the state diagram can be for even a seemingly simple program.
He may remember about test automation, but will rather be stuck on the counting of test cases than he will think about the real value of each of them.
He had heard about testing with the method of free search (exploratory testing), but instead of targeted search, he would simply wander around meaninglessly and, as a result, would consider the technique itself useless.
But if the tester has the skills:
1. He will start testing with finding out the purpose of his work. After that, he will act independently, but in the right direction.
2. If the specification is unclear or unavailable, it will make reasonable conclusions about the product. No one has canceled common sense.
3. He will select and develop risk-finding tests and sort them by importance.
4. It will not be limited to the specification, but will be able to find other sources that will help identify problems.
5. He will pay attention to other criteria of quality - usability, performance, 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 purpose of testing quite widely.
This breadth is very important.
By thinking of coverage only in terms of code coverage or specification coverage, you can miss other important quality indicators.
Possessing only a narrow spectrum of oracle predictors (oracle - the principles or mechanisms by which we recognize problems), it is possible both to exaggerate the importance of some problems, and to completely miss some others.
Testing, like cooking, is what we do to meet the needs of others.
Well, so who do you want to be: a testing chef, intelligently using the available tools and ingredients, or a regular seller, who turns the “testburgers” on the stove over in anticipation of new customers?about the author
Michael Bolton is one of the most active evangelists of the context-oriented testing school. He has over 20 years experience in testing. Michael regularly speaks at conferences, holds trainings and seminars, has been a regular columnist for one of the most popular testing magazines in the field of Better Software since 2005 (where the above article was first published) and maintains a wonderful testing blog www.developsense.com/blog. shtml
On November 17-18, Michael Bolton will hold in St. Petersburg a two-day training "Rapid Software Testing", developed by him in collaboration with James Bach. Details here: habrahabr.ru/blogs/testing/105133