Why we held a hackathon for testers

This article will be of interest to those who, like us, are faced with the problem of selecting a suitable specialist in the field of testing.

Oddly enough, but with the increase in the number of IT companies in our republic, only the number of worthy programmers increases, but not testers. Many are rushing into this profession, but not many understand its meaning.

I can't speak for all IT companies, but we assigned the role of QA/QC to our quality specialists. They are part of the development team and are involved in all stages of development, from research to the release of a new version.

The tester on the team, at the planning stage, should consider all the functional and non-functional requirements for the acceptance of the user story. He should understand the performance characteristics of the product as well as programmers, and even better, and help the team not make wrong decisions even at the planning stage. The tester must have a clear idea of ​​how the implemented functionality will work and what pitfalls may be. Test plans and test cases are compiled by our testers themselves, as well as preparing all the necessary stands for testing. Testing according to the finished specification like a monkey clicker is not our option. Working within the team, he must help release a worthy product and sound the alarm in time if something goes wrong.

What we faced when looking for testers

At the stage of studying a lot of resumes, it seemed that there were specialists with suitable experience for us and there would be no problems with choosing a tester for our team. But, during personal meetings, we more and more came across candidates who were actually quite far from the world of information technology (for example, they could not tell the principles of interaction between a browser and a web server, security basics, relational and non-relational databases, had no idea about virtualization and containerization), but at the same time they evaluated themselves at the level of Senior QA. After conducting more than a dozen interviews, we came to the conclusion that the number of specialists suitable for us in the region is negligible.

Further, I will tell you what steps we took and what rakes we stepped on in order to find those very long-awaited fighters for quality.

How We Tried to Fix the Situation

Having suffered with the sourcing of ready-made specialists, we began to shoot at nearby areas:

1. We tried to apply assessment practices to identify among a lot of “quieters”, those from whom we can grow strong specialists.

   We offered a group of potential candidates with approximately the same level of knowledge to complete tasks. By observing their thought process, they tried to single out the most promising candidate.

   Among other things, we came up with tasks to test attentiveness, understanding the possibilities of technology and the features of multiculturalism:

   
   

2. Meetups were held for testers to expand the boundaries of understanding the profession among the existing contingent.

   I'll tell you a little about each of them.

   Ufa Software QA and Testing Meetup #1 is our first attempt to gather those who are not indifferent to the profession and at the same time understand whether what we want to convey to the public will be interesting. Basically, our reports were about what is the best place to start if you have already decided to become a tester. To help beginners open their eyes and look at testing "in an adult way." We talked about the steps that beginner testers need to take in order to join the profession. About what quality is and how to achieve it in real conditions. And also, what is automatic testing and where it is more appropriate to apply it.

   
   
   Then, with an interval of 1-2 months, we held two more meetups. The number of participants has already doubled. At Ufa Software QA and Testing Meetup #2, we dived deeper into the subject area. They talked about bug tracking systems, about UI / UX testing, touched on Docker, Ansible, and also talked about possible conflicts between the developer and the tester and how to resolve them.

   Our third meetup "Ufa Software QA and Testing Meetup #3" indirectly touched on the work of testers, but was useful in order to remind programmers in time of their technical and organizational duty: load testing, e2e testing, Selenium in autotesting, web application vulnerabilities.

   All this time we have been learning how to make normal light and sound broadcasts from our events:

   → First steps in testing – Ufa Software QA and Testing Meetup #1
   → UI/UX testing – Ufa Software QA and Testing Meetup #2
   → Security Testing, Load Testing and Autotesting – Ufa QA and Testing Meetup #3

3. And in the end we decided to try to hold a hackathon for testers

How to prepare and conduct a hackathon for testers

To begin with, we tried to understand what kind of “beast” this is and how it is usually carried out. As it turned out, events of this kind were held in the Russian Federation not so many times, and there is nowhere to borrow ideas. Secondly, I did not want to immediately invest a lot of resources in a dubious at first glance event. Therefore, we decided that we would do short mini hackathons, not for the entire QA work cycle, but for separate stages.

Our main headache is the lack of practice among local testers in the formation of intelligible test maps. They don't spend time researching before implementing user stories and creating clear acceptance criteria for developers on functional and non-functional requirements, UI / UX, security, workloads and peak loads. Therefore, we decided, for the first time, to go through the most interesting and creative part of their work - the analysis and formation of requirements on a pre-project study.

We estimated the potential number of participants and decided that we need at least 5 backlogs for MVP releases, 5 products and 5 people who will act as product owners, decipher business needs and make decisions on restrictions.

Here's what we got: backlogs for hackathon.

The main idea was to come up with topics as far as possible from all the daily work of the participants and give them room for a creative flight of fancy.

What mistakes did we make and what can be done better

The application of assessment practices, so popular in the field of reception of salespeople and lower managers, took a huge amount of energy, but did not allow us to pay enough attention to each participant and assess their abilities. In general, this selection option creates a negative image of the company, since quite a lot of people receive insufficient feedback and further form the effect of the employer's tyranny in themselves and others (communications in IT communities are very developed). As a result, we are left with literally two potential candidates with a very distant future.

Here mitaps are a good thing. An extensive base for elaboration is being created, the general level of participants is increasing. The company is becoming more and more recognizable in the market. But, the complexity of such undertakings is not small. You need to clearly understand that it will take approximately 700-800 man-hours to conduct meetups per year.

As for the hackathon of testers. Such events have not yet had time to get bored, since, unlike hackathons for developers, they are held much less frequently. The advantage of this idea is that in a non-boring manner you can exchange a large amount of practical knowledge and quite accurately determine the level of each participant.

After analyzing the results of the event, we realized that a bunch of mistakes were made:

1. The most unforgivable mistake was to believe that 4-5 hours would be enough for us. As a result, only the introduction and acquaintance with the backlogs took almost 2 hours.
   Working with product owners at the initial stage and the time to dive into the subject area took the same amount. So, the remaining time was clearly not enough for a comprehensive study of testing maps.
2. There was not enough time and energy for detailed feedback on each map, since it was already night. Therefore, this part was clearly failed by us, and was originally supposed to be the most valuable in the hackathon.
3. We decided to assess the quality of the work by simply voting all the participants, allocating 3 votes for each team, which they could give for the highest quality work. Perhaps it would be better to organize a jury.

What have you achieved

We partially solved our task and now we have 4 brave handsome men covering the rear of 4 development teams. A significant pool of potential strong candidates and tangible changes in the level of the city's QA community have not yet been noticed. But, there are some progress and this cannot but rejoice.

Source: habr.com