Why we conducted hackathon for testers
This article will be interesting to those who, like us, are faced with the problem of choosing the right testing specialist.
Strangely enough, but with the increase in the number of IT companies in our republic, only the number of worthy programmers, but not testers, increases. In this profession, many rush, but not many understand its meaning.
I can not say for all IT companies, but we have secured the role of QA / QC for our quality experts. They are part of the development team and are involved in all phases of development, from research to the release of a new version.
The tester in the team, at the planning stage, should consider all the functional and non-functional requirements for accepting a user history. He should be no worse than programmers, and even better, understand the operational characteristics of the product and help the team not to make wrong decisions at the planning stage. The tester should have a clear idea of ​​how the implemented functionality will work and what pitfalls can be. Our testers compile test plans and test cases themselves, as well as prepare all the necessary stands for testing. Test as a finished specification as a monkey clicker, not our option. Working within the team, he should help to launch a decent product and sound an alarm in time if something went wrong.
')
At the stage of studying a variety 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, in face-to-face meetings, we were increasingly confronted with candidates who were actually quite far from the world of information technology (for example, they could not tell the principles of interaction between the browser and the web server, security fundamentals, relational and non-relational databases, had no idea about virtualization and containerization), but at the same time they rated themselves at Senior QA level. Having conducted more than a dozen interviews, we came to the conclusion that the number of specialists suitable for us in the region is negligible.
Next, I will tell you what steps we took and what rakes we attacked to find those very long-awaited fighters for quality.
Having tormented ourselves with the sourcing of ready-made specialists, we began to focus on the nearby areas:
To begin with, they tried to understand what this "beast" 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 are no ideas to borrow. Secondly, I did not want to immediately invest in a lot of resources in a seemingly doubtful event. Therefore, we decided that we would do short mini hackathons, not for the whole QA work cycle, but for separate stages.
Our main headache is the lack of practice among local testers in developing intelligible test cards. They do not spend time on research at the stage before the implementation of user histories and the creation of clear criteria for developers of acceptance on functional and non-functional requirements, UI / UX, security, workload and peak loads. Therefore, we decided, for the first time, to go through the most interesting and creative part of their work - analysis and the formation of requirements for pre-project research.
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 play the role of product owners, decipher business needs and make decisions on restrictions.
Here's what we got: backlogs for the hackathon .
The main idea was to come up with topics as far as possible from the entire daily work of the participants and give them room for a creative flight of fancy.
The use of assessment practices, which are so popular in the field of reception of sellers and lower-level managers, took a huge amount of energy, but did not allow us to pay enough attention to each participant and evaluate his abilities. In general, this selection option creates a negative image of the company, since quite a lot of people get insufficient feedback and then form themselves and others in others, the employer's self-indulgence effect (communications in IT communities are very developed). As a result, we have literally two potential candidates with a very remote perspective.
Here mitapa good thing. An extensive base for development is being created, the general level of participants is increasing. The company is becoming more recognizable in the market. But the complexity of such undertakings is not small. It is necessary to clearly understand that about 700-800 man-hours will be spent per year for holding meetings.
As for the testers hackathon. This kind of event has not had time to get bored, because, unlike the hackathons for developers, they are held much less often. The advantage of this idea is that in a non-trivial manner one 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 there were a lot of mistakes:
We have 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 QA-community of the city have not yet been noticed. But there are some advances and this is good news.
Strangely enough, but with the increase in the number of IT companies in our republic, only the number of worthy programmers, but not testers, increases. In this profession, many rush, but not many understand its meaning.
I can not say for all IT companies, but we have secured the role of QA / QC for our quality experts. They are part of the development team and are involved in all phases of development, from research to the release of a new version.
The tester in the team, at the planning stage, should consider all the functional and non-functional requirements for accepting a user history. He should be no worse than programmers, and even better, understand the operational characteristics of the product and help the team not to make wrong decisions at the planning stage. The tester should have a clear idea of ​​how the implemented functionality will work and what pitfalls can be. Our testers compile test plans and test cases themselves, as well as prepare all the necessary stands for testing. Test as a finished specification as a monkey clicker, not our option. Working within the team, he should help to launch a decent product and sound an alarm in time if something went wrong.
')
What did we encounter when we were looking for testers
At the stage of studying a variety 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, in face-to-face meetings, we were increasingly confronted with candidates who were actually quite far from the world of information technology (for example, they could not tell the principles of interaction between the browser and the web server, security fundamentals, relational and non-relational databases, had no idea about virtualization and containerization), but at the same time they rated themselves at Senior QA level. Having conducted more than a dozen interviews, we came to the conclusion that the number of specialists suitable for us in the region is negligible.
Next, I will tell you what steps we took and what rakes we attacked to find those very long-awaited fighters for quality.
How we tried to rectify the situation
Having tormented ourselves with the sourcing of ready-made specialists, we began to focus on the nearby areas:
- We tried to apply assessment practices to identify among a lot of “uytivaytishnikov”, those from whom we can grow strong specialists.
A group of potential candidates, with approximately the same level of knowledge, we offered to perform the tasks. Watching their thinking process, we tried to select the most promising candidate.
In particular, we have invented tasks for testing attentiveness, understanding the capabilities of technologies and features of multiculturalism:
- Conducted meetings for testers to expand the boundaries of understanding the profession of the existing contingent.
I'll tell you a little about each of them.
Ufa Software QA and Testing Meetup # 1 - this is our first attempt to collect those who are not indifferent to the profession and at the same time it is interesting to see if the public will be interested in what we want to convey to them. Basically, our reports were about where to start, if you decided to become a tester. Help newcomers open their eyes and take a look at “grown-up” testing. We talked about the steps that novice testers need to do in order to join the profession. About what is quality and how to achieve it in real conditions. And also what automatic testing is and where it is more expedient to use it.
Further, with an interval of 1-2 months, we spent two more mitapa. Participants have already been two times more. At Ufa Software QA and Testing Meetup # 2, we plunged deeper into the subject area. They told about bug tracking systems, UI / UX testing, touched Docker, Ansible, and also told about possible conflicts between the developer and the tester and how to resolve them.
Our third meeting “Ufa Software QA and Testing Meetup # 3” indirectly related to the work of testers, but was useful in order to remind programmers about their technical and organizational duty: load testing, e2e testing, Selenium in self-testing, vulnerability of web applications.
All this time we have been learning to make normal light and sound in 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 - And at the end they decided to try to conduct a hackathon for testers
How to prepare and conduct hackathon for testers
To begin with, they tried to understand what this "beast" 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 are no ideas to borrow. Secondly, I did not want to immediately invest in a lot of resources in a seemingly doubtful event. Therefore, we decided that we would do short mini hackathons, not for the whole QA work cycle, but for separate stages.
Our main headache is the lack of practice among local testers in developing intelligible test cards. They do not spend time on research at the stage before the implementation of user histories and the creation of clear criteria for developers of acceptance on functional and non-functional requirements, UI / UX, security, workload and peak loads. Therefore, we decided, for the first time, to go through the most interesting and creative part of their work - analysis and the formation of requirements for pre-project research.
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 play the role of product owners, decipher business needs and make decisions on restrictions.
Here's what we got: backlogs for the hackathon .
The main idea was to come up with topics as far as possible from the entire daily work of the participants and give them room for a creative flight of fancy.
What mistakes we made and what can be done better
The use of assessment practices, which are so popular in the field of reception of sellers and lower-level managers, took a huge amount of energy, but did not allow us to pay enough attention to each participant and evaluate his abilities. In general, this selection option creates a negative image of the company, since quite a lot of people get insufficient feedback and then form themselves and others in others, the employer's self-indulgence effect (communications in IT communities are very developed). As a result, we have literally two potential candidates with a very remote perspective.
Here mitapa good thing. An extensive base for development is being created, the general level of participants is increasing. The company is becoming more recognizable in the market. But the complexity of such undertakings is not small. It is necessary to clearly understand that about 700-800 man-hours will be spent per year for holding meetings.
As for the testers hackathon. This kind of event has not had time to get bored, because, unlike the hackathons for developers, they are held much less often. The advantage of this idea is that in a non-trivial manner one 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 there were a lot of mistakes:
- The most unforgivable mistake was to believe that 4-5 hours would be enough for us. As a result, only introductory and familiarity with backlogs took almost 2 hours.
Working with the owners of the products at the initial stage and the time to dive into the subject area took as much again. So, there was clearly not enough time left for a comprehensive study of the testing cards. - There was not enough time and effort for detailed feedback on each card, since it was already night. Therefore, this part was clearly failed by us, and was initially assumed as the most valuable in the hackathon.
- We decided to evaluate the quality of the study by a simple vote of all the participants, allocating 3 votes to each team, which they could give for the highest quality work. Perhaps it would be better to organize a jury.
What have achieved
We have 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 QA-community of the city have not yet been noticed. But there are some advances and this is good news.
Source: https://habr.com/ru/post/455684/
All Articles