Implementation of alpha testing and alpha lab in projects
In today's IT world, we must be ready to adapt and improve our process of delivering a high-quality product. Testing is an important and time-consuming part of the software development life cycle. There are many techniques and techniques that allow for efficient testing. But sometimes they do not save from the negative reaction of the customer. The customer remains dissatisfied and looks towards the competitor.
In my practice there are a couple of vivid examples. Let's consider them.
Several years ago we developed a feature for calls from a local PBX to mobile devices. The idea was that our customer got access to the functionality of PBX from his mobile device through the IVR menu. Time and effort we spent decently. After the official release, we were sure that the customer would cry up with emotion. What was to learn that our implementation seemed to him too difficult. Well, he did not want to wait 40 seconds until the “iron” lady explained to him that the next press - 1, 2 or 3. As a result, this functionality was being finalized and did not become popular with the customer.
Another vivid example is the name of the flags in our application. A Canadian of French origin, an American and a Russian, somehow gathered together and let's write names for the fields in the user interface. As a result, the British customer demanded to redo everything.
In both examples we spent extra time and effort.
')
What are we doing wrong? In my opinion, there are several main reasons: poor requirements, lack of expertise, ineffective test plans, a complex product, incorrect assessment, lack of processes.
How can we fix the situation? Each project applies certain standard practices. You can schedule additional time, additional tests in the QA team, conduct a strict review of the code. But they do not always lead to the desired result.
As a variant of the optimal solution, I consider the implementation of alpha testing in projects of any complexity. This is an effective way to conduct testing and increase team expertise.
Alpha testing is usually understood as imitation of real work with the system by regular developers or testers, or real work with the system by potential users / customers. Most often, alpha testing is carried out at an early stage of product development, but in some cases it can be applied to the finished product as an internal acceptance test. I want to make a reservation right away, I share QA testing and Alpha testing. I have programmers, testers, technical support, architects in the project, and there is a separate alpha testing team. The focus of this command is finding bugs during the daily use of our system. This team does not need to do 100 tests per day. They think about the quality of the product, and not about the metrics.
And now, from words to deeds. I propose to move on to building an effective alpha laboratory in your project. The beauty of alpha testing is that testing is ongoing. You and your colleagues use your software or hardware every day, simulating the behavior of a real user. But in order to conduct such testing effectively, you need to formalize this process.
I divided the practical part into 10 basic steps. Let's take a closer look at each step.
Step 1. The first and most important step is the definition of infrastructure. It is necessary to determine the feasibility of such labs, whether there is enough time for its deployment, why it is needed in your project, if you have the necessary funds. Well, we decided, then let's continue.
Step 2. I believe that the design and QA teams are responsible for the accuracy and adequacy of the requirements. Require architects to make requirements for each product and release, work with business analysts. Review in your team and send the requirements back if they are not clear. In general, take an active position in this matter.
Step 3. In step 3, you need to think about the future laboratory. Determine the list of necessary hardware and software, draw a diagram of the future laboratory, schedule the time.
Step 4. The process is necessary, because without it we will not be able to run our alpha tests. Therefore, roll up your sleeves, write how you will act. Consider how many users will participate in alpha testing, how many releases you will support, etc.
Step 5. It is required to coordinate your idea with the customer. The customer in this case may be either your immediate supervisor, his boss, or an external investor. Money for the laboratory and testing should be allocated.
Step 6. The next important step is to select the prime for this activity. Do not sleep and think three times. He should be calm, organized, sociable and inquisitive person.
Step 7. You have a prime time, it’s time to think about test strategies and tests. Use standard templates. It is necessary to think about: technical risks, activities, features for testing, tools, deadlines.
Step 8. Here we come to the test execution. Do this test run as efficiently as possible. I recommend using all sorts of testing techniques. For example, specification-based, usage-based, fault-based techniques.
Step 9. The report deserves special attention. You need it in order to draw conclusions about the test results and the quality of the product. We collect statistics on calls, conferences and features used. All found bugs also go to this report.
Step 10. We are at the finish line. We need any process to improve the quality of the software. Alpha Lab is an opportunity to be one step ahead and predict the reaction of the end user. It is very important to develop this laboratory from release to release. Therefore, do not be lazy, think over and plan the following: be sure to conduct a retrospective, review requirements for a new release, create new users.
Within our company, we have already implemented such a laboratory for one of our customers. And I can say that we see a very positive effect. We forced programmers to use their own code. Found 80 bugs in one year, began to better understand the requirements and desires of the customer, more constructive communication with technical support. An important result is that we have reduced the number of bugs found on beta testing and on customer sites.
In general, we tried and advise everyone. Dare!
In my practice there are a couple of vivid examples. Let's consider them.
Several years ago we developed a feature for calls from a local PBX to mobile devices. The idea was that our customer got access to the functionality of PBX from his mobile device through the IVR menu. Time and effort we spent decently. After the official release, we were sure that the customer would cry up with emotion. What was to learn that our implementation seemed to him too difficult. Well, he did not want to wait 40 seconds until the “iron” lady explained to him that the next press - 1, 2 or 3. As a result, this functionality was being finalized and did not become popular with the customer.
Another vivid example is the name of the flags in our application. A Canadian of French origin, an American and a Russian, somehow gathered together and let's write names for the fields in the user interface. As a result, the British customer demanded to redo everything.
In both examples we spent extra time and effort.
')
What are we doing wrong? In my opinion, there are several main reasons: poor requirements, lack of expertise, ineffective test plans, a complex product, incorrect assessment, lack of processes.
How can we fix the situation? Each project applies certain standard practices. You can schedule additional time, additional tests in the QA team, conduct a strict review of the code. But they do not always lead to the desired result.
As a variant of the optimal solution, I consider the implementation of alpha testing in projects of any complexity. This is an effective way to conduct testing and increase team expertise.
Alpha testing is usually understood as imitation of real work with the system by regular developers or testers, or real work with the system by potential users / customers. Most often, alpha testing is carried out at an early stage of product development, but in some cases it can be applied to the finished product as an internal acceptance test. I want to make a reservation right away, I share QA testing and Alpha testing. I have programmers, testers, technical support, architects in the project, and there is a separate alpha testing team. The focus of this command is finding bugs during the daily use of our system. This team does not need to do 100 tests per day. They think about the quality of the product, and not about the metrics.
And now, from words to deeds. I propose to move on to building an effective alpha laboratory in your project. The beauty of alpha testing is that testing is ongoing. You and your colleagues use your software or hardware every day, simulating the behavior of a real user. But in order to conduct such testing effectively, you need to formalize this process.
I divided the practical part into 10 basic steps. Let's take a closer look at each step.
Step 1. The first and most important step is the definition of infrastructure. It is necessary to determine the feasibility of such labs, whether there is enough time for its deployment, why it is needed in your project, if you have the necessary funds. Well, we decided, then let's continue.
Step 2. I believe that the design and QA teams are responsible for the accuracy and adequacy of the requirements. Require architects to make requirements for each product and release, work with business analysts. Review in your team and send the requirements back if they are not clear. In general, take an active position in this matter.
Step 3. In step 3, you need to think about the future laboratory. Determine the list of necessary hardware and software, draw a diagram of the future laboratory, schedule the time.
Step 4. The process is necessary, because without it we will not be able to run our alpha tests. Therefore, roll up your sleeves, write how you will act. Consider how many users will participate in alpha testing, how many releases you will support, etc.
Step 5. It is required to coordinate your idea with the customer. The customer in this case may be either your immediate supervisor, his boss, or an external investor. Money for the laboratory and testing should be allocated.
Step 6. The next important step is to select the prime for this activity. Do not sleep and think three times. He should be calm, organized, sociable and inquisitive person.
Step 7. You have a prime time, it’s time to think about test strategies and tests. Use standard templates. It is necessary to think about: technical risks, activities, features for testing, tools, deadlines.
Step 8. Here we come to the test execution. Do this test run as efficiently as possible. I recommend using all sorts of testing techniques. For example, specification-based, usage-based, fault-based techniques.
Step 9. The report deserves special attention. You need it in order to draw conclusions about the test results and the quality of the product. We collect statistics on calls, conferences and features used. All found bugs also go to this report.
Step 10. We are at the finish line. We need any process to improve the quality of the software. Alpha Lab is an opportunity to be one step ahead and predict the reaction of the end user. It is very important to develop this laboratory from release to release. Therefore, do not be lazy, think over and plan the following: be sure to conduct a retrospective, review requirements for a new release, create new users.
Within our company, we have already implemented such a laboratory for one of our customers. And I can say that we see a very positive effect. We forced programmers to use their own code. Found 80 bugs in one year, began to better understand the requirements and desires of the customer, more constructive communication with technical support. An important result is that we have reduced the number of bugs found on beta testing and on customer sites.
In general, we tried and advise everyone. Dare!
Source: https://habr.com/ru/post/311734/
All Articles