Homeopathic testers or chronic recruitment problems

Over the past ten years, development approaches have undergone major changes, the requirements for testers (QA, QE, quality engineers) have also changed. But not all testers are ready to step to a whole new level. Yesterday it was possible to come from the street to get into the profession. To become a sought-after specialist today, you need to be an engineer.

When I started my career, a presentation was shown at the courses justifying the need for testing. The signature to the slide read: "The sooner you find a bug in the product’s life cycle, the cheaper its fix." The testers' rates are lower than those of programmers. We hire testers → ensure quality and save on development. Profit!

Testers were bug hunters. Programmers write features, a release is being prepared, the release goes through the QA stage. At that time, the tester “put on the hat” of a real user and began to execute typical scenarios. It was believed that a person without a technical background would be suitable for this position.

The speed of developing modern projects has increased. The concept of CI / CD appeared. No one is surprised by the daily release projects. Companies realized that manual checks are not scalable. Testers were engaged in the automation of acceptance testing using Selenium or similar frameworks. The change in the insides is hidden, if only the frontend remains with the necessary locators.

And so it was. For managers, test automation is associated with one skill: working with Selenium. In pursuit of a silver bullet, they saw in him the answer to all questions. The market has adjusted to demand.

We have been looking for QA-automation for testing web services for a long time. I looked through a couple of hundred resumes and conducted dozens of interviews. If to summarize the impressions, three main problems can be distinguished, which often prevent one from hiring a person.

1. Testers have no idea about the architecture of the project

Here, by architecture, I mean a high-level description of the interactions of system components. Conventionally, through which “pipes” the data flows, where they are stored and how they are used.

During the interview, the candidate may object, they say, we do not need knowledge of architecture. We work with a black box. Why take care of the internal structure?

I do not believe that with such an approach the engineer will come up with all possible test scenarios. If you know the internal structure of the product and read the code, you can avoid duplication of tests at high levels of the testing pyramid.

Pyramid variant by Martin Fowler

In black box testing, there is the same trap as in security through obscurity . You cannot rely solely on this type of testing. The product can meet the stated requirements, while including a large number of hidden bugs. Then, by analogy with security through obscurity, the only guarantee of quality will be our ignorance of how the system is arranged inside.

The advantage of black box testing is that the tests are independent of implementation. Wow. But this artificial restriction should not interfere with understanding the insides. When the tester knows how the product works:

• Faced with a bug, it is able to localize the problem, and not build hypotheses.
• When discussing a new feature, he is ready to give feedback, because he understands how the new feature integrates with existing components.

Malevich agitates for testing the black box

Probably the same love for the black box led to the second problem.

2. Testers do not understand what is happening inside the browser

Often there is a situation where a candidate whose Selenium is indicated as the main tool in the resume does not understand how the browser and the HTTP protocol work. Testing for such automators is primarily the creation of scripts with user actions. A superficial approach that creates unnecessary restrictions.

Most applicants name examples of HTTP codes and types of HTTP requests. The next question is often baffling.

There is a login page. The user enters the correct data for authorization and clicks on the login button. What is happening in the browser at this moment? Why do not subsequent actions with the site require re-authorization?

If the tester did not answer these questions, a doubt about his competence creeps in. This suggests that the candidate:

• cannot test a product without a UI;
• Does not know how to use Developer Tools in a browser;
• I’m not used to finding out the cause of the bug (frontend or backend).

It will be easier for the developer to fix the bug if it is described with technical details.

3. Neglect of the test code

“My code will not get into production, why care about quality?”

I see this as an attempt to split the sandboxes. Let the developers take care of the cleanliness of the code, but we can.

Remember, in the cascade model after development there was a verification stage? During the time of the Waterfall methodology, the responsibility for quality was transferred to the testing department. It didn’t lead to anything good. Programmers did not think about the readiness of the feature, expecting QA to report problems. Ping-pong between departments led to a slowdown in development. This is the price for sharing responsibility.

With the advent of Agile, teams have consolidated. Missing "we" and "they." The team is responsible for the final result. And since engineering practices have become common, then the requirements for the test code should be put forward the same as for the product code.

To drop out candidates, we sent a test task without deadline:

   Java           http://todomvc.com/examples/react/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Type Error List

• Extra complications
  
  A pile of abstractions, wrappers over classes and boilerplate code inside the tests.
  
  Test methods are best made as short as possible. Helper functions and separating the setup from actions on objects and checks will help in this.

  
  
  
  
  
  
  

• Violation of conventions for naming classes, methods, variables
  
  CamelCase mixed up with underscores. So now they don’t wear it. Linter and IDE hints save.

  
  
  
  
  
  
  

• Hardcode paths to auxiliary resources

  
  
  
  
  
  
  

   String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath);
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

  The classic "works on my machine."

  
  
  
  
  
  
  

• Storage of binary files inside the repository
  
  There is git-lfs to solve this problem.

  
  
  
  
  
  
  

• Lack of consistency in methods
  
  In one solution, the candidate described methods for deleting and marking “done” like this:

  
  
  
  
  
  
  

   public void DeleteTask(String task) ... public void CompleteTask(int taskno)
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

  In the first method, the text of the task is transmitted, in the second, the index in the list. Using such an API is painful.

  
  
  
  
  
  
  

• System.out.println()
  
  
  
  for logging
  
  It does not provide supporting information in which class the event occurred.

  
  
  
  
  
  
  

• Using Thread.sleep
  
  
  
  
  
  To solve this problem there is an awaitility library. It helps to add feedback to the expectation of the fulfillment of the necessary condition.

  
  
  
  
  
  
  

• General exceptions instead of asert
  
  Example: a test adds several items to the list of tasks and marks all items as completed. The idea is that in case of problems, the findElement
  
  
  
  method will return a NoSuchElementException
  
  
  
  and the test will NoSuchElementException
  
  
  
  . If you later look at the results of the test run, NoSuchElementException
  
  
  
  will be misleading: it is not clear whether the test really fell or the code of the test curve. It is necessary to use an asert with a clear error message in case of a test failure.

  
  
  
  
  
  
  

• Abuse of Bertic Acerts
  
  assertTrue or assertFalse is used for everything in a row:

  
  
  
  
  
  
  

   assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1);
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  

  It is better to use assertEquals to have context when the test crashes.

  
  
  
  
  
  
  

• Parameterization of test run is not provided
  
  Example: The site URL for testing is nailed in code.

  
  
  
  
  
  
  

We should also mention working with git



. Most often, the task was sent in a single commit. Writing understandable commit messages and breaking a big task into several separate ones is a necessary skill, especially in team work.

conclusions

The problems described above are my personal experience and impressions after the interviews. According to observations, the candidate’s experience does not correlate with the number of gaps. Avoid homeopathic testers, invest time in pumping technical skills of employees. Testers have a lot to learn from developers and vice versa. May force come with those who build engineering culture and swim against the tide.

I will be glad to be mistaken and happy if everything is different in your hired company.