Clever Geek Handbook

Fundamental testing problem

Introduction



Good afternoon, Khabrovsk residents. Here I was solving a test task for the QA Lead vacancy for one fintech company. The first task, to draw up a test plan with a complete checklist and examples of test cases for checking an electric kettle, is trivially solved:









But the second part turned out to be a question: “Are there any problems common to all testers that interfere with working with greater efficiency?”







The first thing that came to mind: to list all the more or less noticeable problems that I encountered during testing, weed out small things, generalize the rest. But he quickly realized that the inductive method would answer a question relating not to “everyone”, but, at best, only to the “majority” of testers. Therefore, I decided to approach from the other side, deductive, and that's what happened.







Definitions



The first thing I usually do when solving a new task is to try to understand what it is all about, and for this you need to understand the meaning of the words that it is posed. The keywords to understand are as follows:









Turn to wikipedia and common sense:

The problem (dr. Greek πρόβλημα) in the broad sense is a complex theoretical or practical question requiring study, resolution; in science - a contradictory situation, acting in the form of opposing positions in the explanation of any phenomena, objects, processes and requiring an adequate theory to resolve it; in life, the problem is formulated in a way that people understand: “I know what, I don’t know how,” that is, it is known what needs to be obtained, but it is not known how to do it. Comes from late lat problēma, from Greek πρόβλημα “thrown forward, set in front”; from προβάλλω “throw forward, set in front of you; blame".







There is not much sense, in fact, “problem” = “anything to deal with”.

Tester is a specialist (we will not divide into types, since we are interested in all testers), who takes part in testing a component or system, the result of which is:

The work of a tester is a set of activities related to testing.

Efficiency (lat. Effectivus ) - the ratio between the achieved result and the resources used ( ISO 9000 : 2015).

A result is a consequence of a chain (sequence) of actions (total) or events expressed qualitatively or quantitatively. Possible outcomes include advantage, inconvenience, gain, loss, value and victory.

As with the “problem”, there is little sense: something that came about as a result of the work.

Resource - a quantitatively measured ability to perform any activity of a person or people; conditions that allow using certain transformations to obtain the desired result. The tester is a person, and in accordance with the theory of vital resources, each person is the owner of four economic assets:

cash (income) - a renewable resource;

energy (vitality) - a partially renewable resource;

time - a fixed and fundamentally non-renewable resource;

knowledge (information) - a renewable resource, it is part of human capital, which can grow and collapse [1] .







I want to note that the definition of effectiveness in our case is not entirely correct, since the more knowledge we use, the lower the efficiency. Therefore, I would redefine efficiency as “the ratio between the achieved result and the resources expended”. Then everything is correct: knowledge at work is not wasted, but reduces the cost of the only fundamentally non-renewable resource of the tester - his time.







Decision



So, we are looking for global problems of testers that worsen the effectiveness of their work.

The most significant resource that is spent on the work of the tester is his time (the rest can be brought to him one way or another), and in order for us to talk about the correct calculation of efficiency, we need to bring the result to time.

To do this, consider a system whose viability the tester provides with his work. Such a system is a project whose team includes a tester. The project life cycle can be roughly represented by the following algorithm:







  1. Work with requirements
  2. Formation of technical specifications
  3. Development
  4. Testing
  5. Release into production
  6. Support (goto p.1)


At the same time, the entire project can be recursively divided into subprojects (features), with the same life cycle.

From the point of view of the project, the effectiveness of its implementation is the greater, the less time is spent on it.

Thus, we come to the determination of the maximum possible effectiveness of the tester from the point of view of the project - this is the state of the project when the time for testing is zero. A common problem for all testers is the inability to achieve this time.







How to deal with this?



The conclusions are quite obvious and have long been used by many:







  1. Development and testing should begin and end almost simultaneously (this is usually done by the QA department). The ideal option is when all the developed functionality by the time it’s ready is already covered by autotests organized in regression (and, if possible, pre-committing) testing using some CI .
  2. The more features in the project (the more complicated it is), the more time you will have to spend on checking that the new functionality has not broken the old one. Hence, the more complex the project, the more automation of regression testing is required.
  3. Every time we skip a bug in production and the user finds it, we have to spend additional time going through the project life cycle starting from step 1 (Working with requirements, in this case, users). Since the reasons for missing a bug are generally unknown, we have only one way to optimize - each bug found by users should be included in regression testing to make sure that it does not appear again.


More articles:


All Articles