Strictly speaking, I am traditional Do not have much experience. From the test in 2006 are beginning to enter the game, my team is on the way to try to quickly change, after the success of Agile has more than a year. And this past year and a half's experience has given me a great impact on, let me on a daily basis A new understanding of and experience in this and previous years in college was for software development and Understanding are quite different.
At least in my view, the traditional software testing should be - we can sit the test sector-specific business area, waiting for product planning documents; receive a document prepared after the use case and look at the project plan; submitted in the programmer version of the product can be used for testing, and then submit bug found in bug management system; plans to release the final product before the changes have not yet come up with a few bug the temerity to argue that product was not ready ... ... but now, we do not and the product team and then there will be room for distance, not just look at the document to write use cases, no longer just submitted bug, a bug is no longer a debate whether the need to revise the agile development ... ... determined that we must be agile to respond to the test.
"Communication" has become one of the most important skills
Agile stresses declaration: individual and cross-over process and tools to customers than contract negotiations. In domestic demand, the developers of our customers. And I did after joining the team the first thing is to get developers to move next. Of course, it is being asked to do so. Still not meet the very beginning, after all, we had been separated from the pride of an independent test team, which is contrary to the traditional concept of the. But after a few test stage, the benefits of doing so reflected out.
The past, we have to wait until a formal version, we can start testing, or too much intervention will disrupt the development plans. Now, programmers sitting opposite me on the compartment, a rise he said: "Hey, X function well, I ran it again no problem, you give it a try?" As a result I have试了试, bug out the. Programmer response is: "Well, I'll change." - From the discovery of such a bug to the amendment, with a maximum of half an hour. The past, I have to wait until the formal submission version, and then build a good, and then up well, even after the bug was found by submitting bug management system, e-mail system to wait for programmers. If the programmer just forgot to open the mail, it may be more time.
In fact there is also more details. I believe the majority of testers and I have the same experience, and submit a bug found, we write a lot of text to describe the bug environment, bug the steps to reproduce; programmers bug amendment also confident The said that the bug has been amended. But when you review, they found that your bug is also known, and programmers fully understand what you said the wrong bug. Now, you need to do is to lift you head out the problem directly and programmers to communicate, so that he can accurately understand what you mean, even the bug you for the analysis. Then all very true.
In addition, there are really not so easy bug to reproduce, you need to tie in with the operation and programmers in order to find the clues. We are now the most common is to do a co-operative, of which I am to create the environment, according to the steps to reproduce, by programmers at the other end of follow-up debugging code, while communication side, it will be able to find very accurate, and can to be amended quickly.
Only a few words of communication can be a bug in the shortest time possible amendment, how much time it saves? All these are more convenient than ever before thanks to the communication. And we have done, but what position is moved to reduce the cost of communication between us, but greatly improved the efficiency of the development - I have lost count how many have not submitted the bug to be wiped out before the swap. But also for us to test a higher demand, although our previous communication skills are emphasized, but now because of the need for more frequent communication, we improve the communication skills have become more and more important, to become the most One of the important skills.
Having said that, in fact, we have to feel that the test's role has changed. As agile development, should be responsible for the quality of the entire team, this goal is no longer required to test the quality of an independent supervisory authority, but to integrate into the entire team to become an integral part of development.
Adjust the size of the test cases
Agile declaration also said that the software can work better than the exhaustive documentation, in response to changes in plan than to follow. Then we can not do not document the use cases do not have to write it. I think that if your project is a "Hello world multi-language version," so big. However, if the face of a large-scale, multiplayer, online, role-playing game, or forget it.
One of the older generation have told me that tests the skills of staff is the most important use case writing, through the use of test cases to express ideas. I think that even the agile era, this skill is still the first. However, if you write the use cases are too detailed and complicated, then began to respond to changes in the team, you will be caught off guard by.
I have really encountered such a situation, a design to achieve half of the time, because the effect is not good, are required to be amended. At this time the use case I have to be modified accordingly - fear that the. If this is a series of very fine particle size of use cases, often thousands, once changed, and time-consuming and laborious. But if I use-case of the particle size was not very fine, then I adjust them on more quickly.
As regards the size to what extent it is appropriate? It depends on the ability of individuals, whether or not strong enough to be able at any time in a complex and detailed the extent of use cases. I personally do not respect the use cases in great detail because some of the details of the place, there is no document can refer to. And we test the game, a lot of details there is no absolute right or wrong division. Even if there are some places where there is doubt, prompt and programmers to communicate and plan than to write a more detailed use cases to be much more effective. To know that our goal should be and all the team members, is a fun play and games, rather than exhaustive software test cases.
This article is reproduced from 51Testing Software Testing Network (see full text):
At least in my view, the traditional software testing should be - we can sit the test sector-specific business area, waiting for product planning documents; receive a document prepared after the use case and look at the project plan; submitted in the programmer version of the product can be used for testing, and then submit bug found in bug management system; plans to release the final product before the changes have not yet come up with a few bug the temerity to argue that product was not ready ... ... but now, we do not and the product team and then there will be room for distance, not just look at the document to write use cases, no longer just submitted bug, a bug is no longer a debate whether the need to revise the agile development ... ... determined that we must be agile to respond to the test.
"Communication" has become one of the most important skills
Agile stresses declaration: individual and cross-over process and tools to customers than contract negotiations. In domestic demand, the developers of our customers. And I did after joining the team the first thing is to get developers to move next. Of course, it is being asked to do so. Still not meet the very beginning, after all, we had been separated from the pride of an independent test team, which is contrary to the traditional concept of the. But after a few test stage, the benefits of doing so reflected out.
The past, we have to wait until a formal version, we can start testing, or too much intervention will disrupt the development plans. Now, programmers sitting opposite me on the compartment, a rise he said: "Hey, X function well, I ran it again no problem, you give it a try?" As a result I have试了试, bug out the. Programmer response is: "Well, I'll change." - From the discovery of such a bug to the amendment, with a maximum of half an hour. The past, I have to wait until the formal submission version, and then build a good, and then up well, even after the bug was found by submitting bug management system, e-mail system to wait for programmers. If the programmer just forgot to open the mail, it may be more time.
In fact there is also more details. I believe the majority of testers and I have the same experience, and submit a bug found, we write a lot of text to describe the bug environment, bug the steps to reproduce; programmers bug amendment also confident The said that the bug has been amended. But when you review, they found that your bug is also known, and programmers fully understand what you said the wrong bug. Now, you need to do is to lift you head out the problem directly and programmers to communicate, so that he can accurately understand what you mean, even the bug you for the analysis. Then all very true.
In addition, there are really not so easy bug to reproduce, you need to tie in with the operation and programmers in order to find the clues. We are now the most common is to do a co-operative, of which I am to create the environment, according to the steps to reproduce, by programmers at the other end of follow-up debugging code, while communication side, it will be able to find very accurate, and can to be amended quickly.
Only a few words of communication can be a bug in the shortest time possible amendment, how much time it saves? All these are more convenient than ever before thanks to the communication. And we have done, but what position is moved to reduce the cost of communication between us, but greatly improved the efficiency of the development - I have lost count how many have not submitted the bug to be wiped out before the swap. But also for us to test a higher demand, although our previous communication skills are emphasized, but now because of the need for more frequent communication, we improve the communication skills have become more and more important, to become the most One of the important skills.
Having said that, in fact, we have to feel that the test's role has changed. As agile development, should be responsible for the quality of the entire team, this goal is no longer required to test the quality of an independent supervisory authority, but to integrate into the entire team to become an integral part of development.
Adjust the size of the test cases
Agile declaration also said that the software can work better than the exhaustive documentation, in response to changes in plan than to follow. Then we can not do not document the use cases do not have to write it. I think that if your project is a "Hello world multi-language version," so big. However, if the face of a large-scale, multiplayer, online, role-playing game, or forget it.
One of the older generation have told me that tests the skills of staff is the most important use case writing, through the use of test cases to express ideas. I think that even the agile era, this skill is still the first. However, if you write the use cases are too detailed and complicated, then began to respond to changes in the team, you will be caught off guard by.
I have really encountered such a situation, a design to achieve half of the time, because the effect is not good, are required to be amended. At this time the use case I have to be modified accordingly - fear that the. If this is a series of very fine particle size of use cases, often thousands, once changed, and time-consuming and laborious. But if I use-case of the particle size was not very fine, then I adjust them on more quickly.
As regards the size to what extent it is appropriate? It depends on the ability of individuals, whether or not strong enough to be able at any time in a complex and detailed the extent of use cases. I personally do not respect the use cases in great detail because some of the details of the place, there is no document can refer to. And we test the game, a lot of details there is no absolute right or wrong division. Even if there are some places where there is doubt, prompt and programmers to communicate and plan than to write a more detailed use cases to be much more effective. To know that our goal should be and all the team members, is a fun play and games, rather than exhaustive software test cases.
This article is reproduced from 51Testing Software Testing Network (see full text):