Forge personnel: how testers learned and blacksmiths were tempered
We are looking for testers. Every IT company sooner or later faces the need to hire such specialists. Searches go long and often fail. Nothing can be done: the market is overheated, good testers instantly disassemble. Our universities do not train engineers for quality. It turns out that a tester is not a diploma, but a vocation, and it is impossible to predict a growth in the number of personnel. And our projects are “burning”, we urgently need people. In such circumstances, we decided on an extreme measure: to raise these people from scratch. Thus, the idea of ​​a testers school at Peter-Service emerged.
In this article we will share the experience of learning to test non-core specialists.
Like any project, the school of testers also has its life cycle. Pretty simple: preparation, training and the most fun - afterparty.
')
When preparing, first determine the goal. Think about what and why you want to teach. If you are training specialists "by yourself", then maybe there is no point in reading the standard course on testing? This is what we did: we focused on the types, techniques and testing tools that we use in our company. These include UI testing, database, automation, version control system, as well as continuous integration.
Also think about who you want to see among your employees. Estimate how many people, what age and social status you are willing to teach (unless, of course, you want to create a school for the sake of the school). In addition to these issues, it was important for us that potential schoolchildren have laptops, since we planned to use working laptops only in extreme cases.
Probably, it is no secret that it is the teachers who determine the result of the school. Our teachers are production department engineers, programmers and testers. None of us have ever taught before. And you know, do not force people to lead lessons. It is better to invite volunteers. Believe me, those who are ready to train completely free of charge after work will do it perfectly well. Most likely, such fans of their business will be able to “infect” with their enthusiasm and schoolchildren.
A retrospective on the basis of the school showed that during the preparation stage, training for teachers was very, very useful. Try to show future teachers the main tricks of good presentations and to keep the attention of listeners. In general, we were lucky: our schoolchildren themselves were very greedy for knowledge. But with the complete absence of teaching experience, such training provided us with good psychological support.
Also a good solution is mutual verification of lesson plans. First, teachers will master the whole course, not repeating and not breaking the context throughout the entire course of study. And secondly, the approval of colleagues will give them confidence and will not force them to think: “but what am I saying?”.
What we argued about when drawing up lesson plans was about the schedule. 4 days a week for 3 hours or 3 days a week for 4 hours? As a result, we took into account the experience of evening studies in universities and conducted classes 3 times a week for 3 astronomical hours. Our school came in the spring, so we excluded Friday from the schedule, the day when many leave for summer houses.
The learning process itself depends on your goals. And if the event is announced as a school with maximum immersion in the workflow, you will have to think through this very process well.
About a month before the start of classes, we seriously thought about workplaces and stands. The initial idea to use real infrastructure did not find support from the security service. How to bring the working environment as close as possible to the one used in the company and prevent students from accessing the internal network? It was necessary to develop a scheme for delivering applications (utilities, test frameworks, IDEs, libraries, etc.) to student computers, as well as to prepare servers for web applications and databases. To accomplish these tasks, we brought in our DevOps specialists, system administrators, an information technology department and a security department.
To create a universal student workplace, we chose vagrant technology, which we successfully tested on other projects. Vagrant allowed to create a virtual machine with everything needed for the school software, pack it in a “box” and deploy it in one click on the students' machines. Thus, we got the same and predictable workplace for different computers and operating systems, which could be easily restored in case of failure or breakdown, and most importantly, reproduced on any computer. However, keep in mind that the size of the “box” in this case turns out to be quite large, which means it also takes a lot of time for its initial delivery to the computer. Next time we will try to use jobs in the form of VDI.
We prepared servers with test applications using vmWare vSphere. Everything, as in real work: databases and application services are separated into different instances, nginx is configured, domain authentication is raised, a DMZ is allocated with access via OpenVPN. After the final configuration, we made snapshots of servers. During the training, real testing of the systems took place, the students specifically or unwittingly “broke” our applications, brutally force, applied the load, looked for vulnerabilities in the databases. We initially proceeded from the fact that refusal and failure could have been anything, so to restore the working environment at any time was not a problem for us - everything instantly rolled back and rose from snapshots.
For the organization of access to the network in the classroom, a separate wifi was raised. Students could get to the stand only through OpenVPN, which was automatically raised in the virtual vagrant environment. The student had a separate account. The services were connected to the domain, which simplified our authorization and made it possible to restrict access if necessary, although this was not needed - attempts to break were part of the training. We previously depersonalized the data in the databases, and the tested applications were not significant for production, so there was no risk of leakage of important data and code.
Oh, by the way, about the test application. Of course, it would be ideal to use your work projects. But, if this is not possible, try to find something more or less modern. Of course, an old desktop application with a bunch of bugs is suitable for testing. But will there be any interest in testing after it, does it smell of mothballs on schoolchildren? We, as a test application, took a real working prototype, which was not put into production.
In general, take for an axiom that everything can break at any moment. Then you will avoid many troubles and unnecessary stress. The only thing that we did not take into account - a power outage. And according to Moore's laws, this is exactly what happened in one of the classes. Therefore, you can never relax, it would seem, in a simple matter.
So, the training has begun.
Explain to the students what to do if they miss classes. Where do they get information. We prepared the handout with the main theses of the lessons - very convenient just for such cases. Well, if you can give away and presentations. Just do it centrally, for example, through the VK group.
As already noted, if training should be as close as possible to the working process, then practice is paramount. In any case, remember that it is the alternation of theory with practice that gives an excellent result. And try to give as many examples as possible from life, from your work. Then the students will have a sense of the reality of the profession, and they will “light up”.
We wanted to give universal knowledge about testing, so the introductory theoretical course was based on the basic level ISTQB training program. But as for the practice ...
Our company supplies complex multicomponent systems. For the production of individual components, as a rule, a dedicated team of developers and testers is responsible. We built classes in such a way as to lead students through the basic levels of the architecture of our applications. In the end, everyone could appreciate in which area he would be interested to work.
A web application with a three-tier architecture and a fairly standard implementation was chosen for practice: the client part — HTML, CSS, Javascript, and the server side — Java. The application was deployed on Apache Tomcat, Oracle was used for data storage. We moved from manual testing of UI through SQL and databases to automated testing of the REST API.
If your systems have a user interface, start practicing testing on it. People who are not familiar with programming and IT, it is much easier to deal with the usual input fields and buttons. Our first test practice was to test the finished plan and create reports on defects. To do this, we have previously created a project in JIRA and test scripts in TestRail.
Gradually complicate the program. For example, add error localization tools to simple manual testing. In the UI part, we looked at the possibilities of the Fiddler Web Debugger and the developer tools in the browser. In part of the database studied SQL. The initial information about the HTTP protocol has been extended with information about REST requests. At this point, the students were fairly well acquainted with the test application and were ready for its automatic testing.
Automation was performed using the Robot Framework, widely used in our company. We will not hide, I really wanted to get the wow effect by automating the UI. But because of the time constraints and the complexity of such automation, we had to abandon this idea in favor of the good old API. We wanted to ensure that every student eventually succeeded, and he felt like a real tester. With the automation of API tests, this is possible.
At this point, learning the basics of testing could in principle be considered complete. But it’s well known that auto tests do not make sense without autorun and should be built into the development process. Therefore, we decided not to stop, but to learn the practice of continuous integration with schoolchildren. Again, the tools used in the company were used as tools: TeamCity and BitBucket.
By the way, the decision to use one application for practice in all the lessons turned out to be very successful. Even non-functional testing (usability, load) was conducted on it. So we provided consistency and connectedness of knowledge.
Although the school of testers is called a school, we do not need at all that schoolchildren will be chinking the material. After all, we, in the end, want to hire testers from among them. Therefore, it’s okay if they don’t remember something, it’s much more important that they understand the essence. For the same reason, conduct a dialogue with the audience, ask questions, check their thinking. You do not just teach, you choose your employees. From the very first lessons, see if they are suitable for your projects.
A big plus in the lessons is the presence of an assistant. A better two. It is quite difficult for one for three hours to lecture, answer questions and help everyone with practice at once.
It is good if all the questions are asked in the classroom and the students go home with a full understanding of what is happening. But it's also good if you can provide them with remote access to training applications. We didn’t even think about homework - why in 25 years we should also load people with homework! But it turns out they were waiting and wanted. Therefore, consider the possibility of their implementation.
The final exam makes sense to develop at the planning stage of training. Then you need to decide on the evaluation criteria. We decided for ourselves that we will have two parts: a test of theoretical knowledge and a practical task.
For the test on each topic, we prepared 3 questions and a set of answers. Of course, the answers in a free form would give us a clearer understanding of the human mindset. But the complexity of the test in this case is quite high.
As a practical task, we suggested that students test one of the modules of the corporate web application. This module was not yet ready and was actually being tested. Here we killed two birds with one stone: we finally loaded the students into the work environment and helped our colleagues with testing (yes, they were satisfied with the result). Everything was fair: the guys searched for mistakes, determined their priorities and fixed them in Jira. The final assessment was influenced by three parameters: knowledge of the theory, the correctness of the description of the defect and the usefulness of the found defect for the project.
Nevertheless, the main role in selecting candidates for subsequent interviews for us was not played by the exam (it was rather held for the students themselves, in order to systematize their knowledge), but by personal impressions in the classroom. Even before the exam, we knew who and where we were going to interview. Although the exam has expanded the list of candidates.
If you plan to work with your students in the same team in the future, it would be good to relieve the situation a little. Since we created the school specifically for the purpose of hiring employees, the graduation party was devoted to going beyond the “student-teacher” framework. We played games, ate pizza and generally had fun. By the way, this evening helped us to partially evaluate the personal qualities of potential employees.
Well, then ... Then there were interviews in the working teams. And almost half of the former schoolchildren became our colleagues. When the school was just thinking, we dreamed of at least two new employees. At the time of the final test, it became obvious that there would be many more. Therefore, we declare that the school of testers has become for us a real source of personnel!
In this article we will share the experience of learning to test non-core specialists.
Like any project, the school of testers also has its life cycle. Pretty simple: preparation, training and the most fun - afterparty.
')
Goals and audience
When preparing, first determine the goal. Think about what and why you want to teach. If you are training specialists "by yourself", then maybe there is no point in reading the standard course on testing? This is what we did: we focused on the types, techniques and testing tools that we use in our company. These include UI testing, database, automation, version control system, as well as continuous integration.
Also think about who you want to see among your employees. Estimate how many people, what age and social status you are willing to teach (unless, of course, you want to create a school for the sake of the school). In addition to these issues, it was important for us that potential schoolchildren have laptops, since we planned to use working laptops only in extreme cases.
Teachers
Probably, it is no secret that it is the teachers who determine the result of the school. Our teachers are production department engineers, programmers and testers. None of us have ever taught before. And you know, do not force people to lead lessons. It is better to invite volunteers. Believe me, those who are ready to train completely free of charge after work will do it perfectly well. Most likely, such fans of their business will be able to “infect” with their enthusiasm and schoolchildren.
A retrospective on the basis of the school showed that during the preparation stage, training for teachers was very, very useful. Try to show future teachers the main tricks of good presentations and to keep the attention of listeners. In general, we were lucky: our schoolchildren themselves were very greedy for knowledge. But with the complete absence of teaching experience, such training provided us with good psychological support.
Also a good solution is mutual verification of lesson plans. First, teachers will master the whole course, not repeating and not breaking the context throughout the entire course of study. And secondly, the approval of colleagues will give them confidence and will not force them to think: “but what am I saying?”.
What we argued about when drawing up lesson plans was about the schedule. 4 days a week for 3 hours or 3 days a week for 4 hours? As a result, we took into account the experience of evening studies in universities and conducted classes 3 times a week for 3 astronomical hours. Our school came in the spring, so we excluded Friday from the schedule, the day when many leave for summer houses.
Workplaces
The learning process itself depends on your goals. And if the event is announced as a school with maximum immersion in the workflow, you will have to think through this very process well.
About a month before the start of classes, we seriously thought about workplaces and stands. The initial idea to use real infrastructure did not find support from the security service. How to bring the working environment as close as possible to the one used in the company and prevent students from accessing the internal network? It was necessary to develop a scheme for delivering applications (utilities, test frameworks, IDEs, libraries, etc.) to student computers, as well as to prepare servers for web applications and databases. To accomplish these tasks, we brought in our DevOps specialists, system administrators, an information technology department and a security department.
To create a universal student workplace, we chose vagrant technology, which we successfully tested on other projects. Vagrant allowed to create a virtual machine with everything needed for the school software, pack it in a “box” and deploy it in one click on the students' machines. Thus, we got the same and predictable workplace for different computers and operating systems, which could be easily restored in case of failure or breakdown, and most importantly, reproduced on any computer. However, keep in mind that the size of the “box” in this case turns out to be quite large, which means it also takes a lot of time for its initial delivery to the computer. Next time we will try to use jobs in the form of VDI.
We prepared servers with test applications using vmWare vSphere. Everything, as in real work: databases and application services are separated into different instances, nginx is configured, domain authentication is raised, a DMZ is allocated with access via OpenVPN. After the final configuration, we made snapshots of servers. During the training, real testing of the systems took place, the students specifically or unwittingly “broke” our applications, brutally force, applied the load, looked for vulnerabilities in the databases. We initially proceeded from the fact that refusal and failure could have been anything, so to restore the working environment at any time was not a problem for us - everything instantly rolled back and rose from snapshots.
For the organization of access to the network in the classroom, a separate wifi was raised. Students could get to the stand only through OpenVPN, which was automatically raised in the virtual vagrant environment. The student had a separate account. The services were connected to the domain, which simplified our authorization and made it possible to restrict access if necessary, although this was not needed - attempts to break were part of the training. We previously depersonalized the data in the databases, and the tested applications were not significant for production, so there was no risk of leakage of important data and code.
Oh, by the way, about the test application. Of course, it would be ideal to use your work projects. But, if this is not possible, try to find something more or less modern. Of course, an old desktop application with a bunch of bugs is suitable for testing. But will there be any interest in testing after it, does it smell of mothballs on schoolchildren? We, as a test application, took a real working prototype, which was not put into production.
In general, take for an axiom that everything can break at any moment. Then you will avoid many troubles and unnecessary stress. The only thing that we did not take into account - a power outage. And according to Moore's laws, this is exactly what happened in one of the classes. Therefore, you can never relax, it would seem, in a simple matter.
Training
So, the training has begun.
Explain to the students what to do if they miss classes. Where do they get information. We prepared the handout with the main theses of the lessons - very convenient just for such cases. Well, if you can give away and presentations. Just do it centrally, for example, through the VK group.
As already noted, if training should be as close as possible to the working process, then practice is paramount. In any case, remember that it is the alternation of theory with practice that gives an excellent result. And try to give as many examples as possible from life, from your work. Then the students will have a sense of the reality of the profession, and they will “light up”.
We wanted to give universal knowledge about testing, so the introductory theoretical course was based on the basic level ISTQB training program. But as for the practice ...
Our company supplies complex multicomponent systems. For the production of individual components, as a rule, a dedicated team of developers and testers is responsible. We built classes in such a way as to lead students through the basic levels of the architecture of our applications. In the end, everyone could appreciate in which area he would be interested to work.
A web application with a three-tier architecture and a fairly standard implementation was chosen for practice: the client part — HTML, CSS, Javascript, and the server side — Java. The application was deployed on Apache Tomcat, Oracle was used for data storage. We moved from manual testing of UI through SQL and databases to automated testing of the REST API.
If your systems have a user interface, start practicing testing on it. People who are not familiar with programming and IT, it is much easier to deal with the usual input fields and buttons. Our first test practice was to test the finished plan and create reports on defects. To do this, we have previously created a project in JIRA and test scripts in TestRail.
Gradually complicate the program. For example, add error localization tools to simple manual testing. In the UI part, we looked at the possibilities of the Fiddler Web Debugger and the developer tools in the browser. In part of the database studied SQL. The initial information about the HTTP protocol has been extended with information about REST requests. At this point, the students were fairly well acquainted with the test application and were ready for its automatic testing.
Automation was performed using the Robot Framework, widely used in our company. We will not hide, I really wanted to get the wow effect by automating the UI. But because of the time constraints and the complexity of such automation, we had to abandon this idea in favor of the good old API. We wanted to ensure that every student eventually succeeded, and he felt like a real tester. With the automation of API tests, this is possible.
At this point, learning the basics of testing could in principle be considered complete. But it’s well known that auto tests do not make sense without autorun and should be built into the development process. Therefore, we decided not to stop, but to learn the practice of continuous integration with schoolchildren. Again, the tools used in the company were used as tools: TeamCity and BitBucket.
By the way, the decision to use one application for practice in all the lessons turned out to be very successful. Even non-functional testing (usability, load) was conducted on it. So we provided consistency and connectedness of knowledge.
Although the school of testers is called a school, we do not need at all that schoolchildren will be chinking the material. After all, we, in the end, want to hire testers from among them. Therefore, it’s okay if they don’t remember something, it’s much more important that they understand the essence. For the same reason, conduct a dialogue with the audience, ask questions, check their thinking. You do not just teach, you choose your employees. From the very first lessons, see if they are suitable for your projects.
A big plus in the lessons is the presence of an assistant. A better two. It is quite difficult for one for three hours to lecture, answer questions and help everyone with practice at once.
It is good if all the questions are asked in the classroom and the students go home with a full understanding of what is happening. But it's also good if you can provide them with remote access to training applications. We didn’t even think about homework - why in 25 years we should also load people with homework! But it turns out they were waiting and wanted. Therefore, consider the possibility of their implementation.
Exam
The final exam makes sense to develop at the planning stage of training. Then you need to decide on the evaluation criteria. We decided for ourselves that we will have two parts: a test of theoretical knowledge and a practical task.
For the test on each topic, we prepared 3 questions and a set of answers. Of course, the answers in a free form would give us a clearer understanding of the human mindset. But the complexity of the test in this case is quite high.
As a practical task, we suggested that students test one of the modules of the corporate web application. This module was not yet ready and was actually being tested. Here we killed two birds with one stone: we finally loaded the students into the work environment and helped our colleagues with testing (yes, they were satisfied with the result). Everything was fair: the guys searched for mistakes, determined their priorities and fixed them in Jira. The final assessment was influenced by three parameters: knowledge of the theory, the correctness of the description of the defect and the usefulness of the found defect for the project.
Nevertheless, the main role in selecting candidates for subsequent interviews for us was not played by the exam (it was rather held for the students themselves, in order to systematize their knowledge), but by personal impressions in the classroom. Even before the exam, we knew who and where we were going to interview. Although the exam has expanded the list of candidates.
Afterparty
If you plan to work with your students in the same team in the future, it would be good to relieve the situation a little. Since we created the school specifically for the purpose of hiring employees, the graduation party was devoted to going beyond the “student-teacher” framework. We played games, ate pizza and generally had fun. By the way, this evening helped us to partially evaluate the personal qualities of potential employees.
Well, then ... Then there were interviews in the working teams. And almost half of the former schoolchildren became our colleagues. When the school was just thinking, we dreamed of at least two new employees. At the time of the final test, it became obvious that there would be many more. Therefore, we declare that the school of testers has become for us a real source of personnel!
Related Links
Source: https://habr.com/ru/post/307402/
All Articles