Create a testing department
Software development is impossible without quality control, and in this the key role is played by the testing process. It should be noted that testing is not the only and certainly not a sufficient measure for creating high-quality software, but absolutely necessary.
What is testing? Simplified, this is the process of verifying that the program meets all the requirements. Even more simply - testing is a search for errors. In this case, the program is usually considered as a “black box”, and the check is performed by repeated launch with different initial data and under different conditions.
We are convinced that full-fledged testing of a software product in a company can be performed only by a separate division - in fact, the testing department. Shifting the functions of testers to developers, business analysts or even managers is an inefficient way. In this article, we will describe how to build a testing department.
Test case - steps to achieve the expected result.
Test plan - scheduled and assigned test cases.
Run - the implementation of the test plan.
Regression test - a test of the old functionality of the program, the performance of which could be violated after the introduction of new functions.
')
The most important thing is to find the right people. The first thing you encounter is that they don't teach us testers, and finding a person is not so easy. You have two options: “make a tester” of one of your employees, or hire someone from your work experience.
Definitely, a person from the company already knows the characteristics of your product, the requirements of customers and the staff (this is also important). Probably (if you are already developing) that one of the programmers still tested their code and someone did it better and more thoroughly than others?
However, although the transition from programmers to testers is possible, one cannot be sure that your employees who like their work will agree to devote themselves to testing. I would suggest that they will not be enthusiastic about such an offer at all - they are too different professions. Therefore, hiring from the side also consider.
A good tester is not just a “test runner”, this is the person who will use your product every day and be the most loyal user of it. And to have such a person in a team is worth a lot.
Testing is a time consuming and time consuming process. One run of regression tests is worth something! Therefore, when testing is extremely important time planning. For example, you have a lot of projects, but only one testing department. There are many problems with simultaneous releases.
For the solution it is very convenient to use the google-calendar (I once wrote about using google services), that is, to create a calendar in which you can make planned releases, and share it with managers and testers. You can view the release dates in the project management system, for example, Redmine, but most clearly use a single calendar for planning.
Than to have a very “evil” test case, it is much more important to “run” it regularly and record the results. You can, of course, keep everything in your head or enter the results of tests in a notebook, but this is not effective. Use TMS (Test Management System). They allow you to use a systematic approach when testing - when we initially sit down and describe the plan of our tests so that it does not work out like this: we tested it here, there and, as a result, we cannot say what the status of the project / product is.
The most important thing when using TMS is to analyze the results obtained and identify the dynamics of the development of projects. We are starting to see from release to release, for example:
We use TMS Testlink. You can choose other systems. One of my colleagues told his experience and advice in an article . Take note - will help in difficult times. In TMS we enter all our tests, and then we review reports.
Manual testing is where it all begins. Tests are performed manually, without using special automation tools (except for TMS). The tester usually just follows a pre-written plan of action, fixing the result - whether the behavior was expected or not (in this case, it is written what went wrong).
In most cases, manual testing is functional testing, as well as software and hardware compatibility testing. Manual testing is most common for testing user interfaces — here automation is sometimes economically inefficient or impossible at all.
The employee for manual testing should be searched for painstakingly, inquisitive and patient, who is “on you” with the objects of testing - sites, mobile devices, SmartTV, etc.
The need for automated testing arises when the project is already large and is being actively developed. In order not to waste time on a manual test run, which you have to perform very often, you can use automated testing.
Often, autotest means only unit tests, although you can automate almost any type of testing. We believe that any testing of the code on the principle of “white” or “gray box” is the task of the developer, not the tester, therefore, we will not consider organization of unit testing here.
Tools for automating manual functional testing is quite wide. We ourselves use Selenium to test the web.
It often happens that the cost of maintaining autotests significantly exceeds the costs of manual testing. Therefore, we must act without fanaticism.
Requirements for the employee are almost the same as for the programmer-administrator. Why admin? Because autotesting is closely related to release engineering.
That is, we, as a rule, either collect packages for testing, or roll out a release into a test environment (staging environment or “quarantine” in our terminology). At a certain point, we come to the point that we need to minimize the time of testing before release.
About load testing will come up after the first peak of users. If everything slowed down and fell, then as soon as the sparks stop pouring out of your eyes, lifting the project, the developers themselves will begin to pronounce this mantra, and you will be lucky if you find the load figures that your project / product must withstand. Oddly enough, the customer himself often does not know what to expect from users. Usually these figures from the manager will be knocked out by the developers, and the manager by the otherworldly manager, that is, on the customer’s side.
What tool to conduct testing? We use yandex-tank.
Requirements for testing staff:
You will need this type of testing as soon as you start building fault-tolerant systems (for example, with redundant elements or with graceful degradation). Sad experience shows that in the event of failure of one element in such systems,in general, the entire behavior of the other elements is hardly predictable.
How do we conduct a failover test? We analyze the technical structure of the project, carefully plan the actions and in the hours of lowest load, we deduce some elements of the system from work, study the consequences, make improvements and adjustments. Then we repeat.
To summarize, what should be done to create a testing department:
What is testing? Simplified, this is the process of verifying that the program meets all the requirements. Even more simply - testing is a search for errors. In this case, the program is usually considered as a “black box”, and the check is performed by repeated launch with different initial data and under different conditions.
We are convinced that full-fledged testing of a software product in a company can be performed only by a separate division - in fact, the testing department. Shifting the functions of testers to developers, business analysts or even managers is an inefficient way. In this article, we will describe how to build a testing department.
Glossary
Test case - steps to achieve the expected result.
Test plan - scheduled and assigned test cases.
Run - the implementation of the test plan.
Regression test - a test of the old functionality of the program, the performance of which could be violated after the introduction of new functions.
')
People
The most important thing is to find the right people. The first thing you encounter is that they don't teach us testers, and finding a person is not so easy. You have two options: “make a tester” of one of your employees, or hire someone from your work experience.
Definitely, a person from the company already knows the characteristics of your product, the requirements of customers and the staff (this is also important). Probably (if you are already developing) that one of the programmers still tested their code and someone did it better and more thoroughly than others?
However, although the transition from programmers to testers is possible, one cannot be sure that your employees who like their work will agree to devote themselves to testing. I would suggest that they will not be enthusiastic about such an offer at all - they are too different professions. Therefore, hiring from the side also consider.
A good tester is not just a “test runner”, this is the person who will use your product every day and be the most loyal user of it. And to have such a person in a team is worth a lot.
Time planning
Testing is a time consuming and time consuming process. One run of regression tests is worth something! Therefore, when testing is extremely important time planning. For example, you have a lot of projects, but only one testing department. There are many problems with simultaneous releases.
For the solution it is very convenient to use the google-calendar (I once wrote about using google services), that is, to create a calendar in which you can make planned releases, and share it with managers and testers. You can view the release dates in the project management system, for example, Redmine, but most clearly use a single calendar for planning.
Testing is accounting and control.
Than to have a very “evil” test case, it is much more important to “run” it regularly and record the results. You can, of course, keep everything in your head or enter the results of tests in a notebook, but this is not effective. Use TMS (Test Management System). They allow you to use a systematic approach when testing - when we initially sit down and describe the plan of our tests so that it does not work out like this: we tested it here, there and, as a result, we cannot say what the status of the project / product is.
The most important thing when using TMS is to analyze the results obtained and identify the dynamics of the development of projects. We are starting to see from release to release, for example:
- The number of bugs increases, and you need to figure out what the problem is.
- One tester finds more bugs than others. How to raise the skills of testers?
- The time for running regression tests is steadily increasing with the development of the project, but we clearly see it and can plan it.
- …… in general, information for analysis is sufficient.
We use TMS Testlink. You can choose other systems. One of my colleagues told his experience and advice in an article . Take note - will help in difficult times. In TMS we enter all our tests, and then we review reports.
Manual testing
Manual testing is where it all begins. Tests are performed manually, without using special automation tools (except for TMS). The tester usually just follows a pre-written plan of action, fixing the result - whether the behavior was expected or not (in this case, it is written what went wrong).
In most cases, manual testing is functional testing, as well as software and hardware compatibility testing. Manual testing is most common for testing user interfaces — here automation is sometimes economically inefficient or impossible at all.
The employee for manual testing should be searched for painstakingly, inquisitive and patient, who is “on you” with the objects of testing - sites, mobile devices, SmartTV, etc.
Automated Testing
The need for automated testing arises when the project is already large and is being actively developed. In order not to waste time on a manual test run, which you have to perform very often, you can use automated testing.
Often, autotest means only unit tests, although you can automate almost any type of testing. We believe that any testing of the code on the principle of “white” or “gray box” is the task of the developer, not the tester, therefore, we will not consider organization of unit testing here.
Tools for automating manual functional testing is quite wide. We ourselves use Selenium to test the web.
It often happens that the cost of maintaining autotests significantly exceeds the costs of manual testing. Therefore, we must act without fanaticism.
Requirements for the employee are almost the same as for the programmer-administrator. Why admin? Because autotesting is closely related to release engineering.
That is, we, as a rule, either collect packages for testing, or roll out a release into a test environment (staging environment or “quarantine” in our terminology). At a certain point, we come to the point that we need to minimize the time of testing before release.
Stress Testing
About load testing will come up after the first peak of users. If everything slowed down and fell, then as soon as the sparks stop pouring out of your eyes, lifting the project, the developers themselves will begin to pronounce this mantra, and you will be lucky if you find the load figures that your project / product must withstand. Oddly enough, the customer himself often does not know what to expect from users. Usually these figures from the manager will be knocked out by the developers, and the manager by the otherworldly manager, that is, on the customer’s side.
What tool to conduct testing? We use yandex-tank.
Requirements for testing staff:
- knowledge of the technical structure of the project,
- quite good administration level in linux (I'm talking about large projects),
- programming skills.
Fault tolerance testing
You will need this type of testing as soon as you start building fault-tolerant systems (for example, with redundant elements or with graceful degradation). Sad experience shows that in the event of failure of one element in such systems,
How do we conduct a failover test? We analyze the technical structure of the project, carefully plan the actions and in the hours of lowest load, we deduce some elements of the system from work, study the consequences, make improvements and adjustments. Then we repeat.
Conclusion
To summarize, what should be done to create a testing department:
- Choose the right people - from the company or from outside;
- Create a planning tool for testing releases;
- Organize work with TMS to form test cases and record test results;
- Actually, regularly conduct tests and analyze the results;
- Start with manual testing and, if necessary, implement automation; As projects develop, add load testing and fault tolerance testing.
Source: https://habr.com/ru/post/240387/
All Articles