Have you ever encountered a situation where the speed of development and testing is very fast, causing projects to be queued up, and when you intervene in testing, the first use case fails to run?
Have you ever encountered a situation where poor quality of development and testing resulted in repeated modifications, repeated testing, and repeated verification?
Have you ever encountered a situation where a modification affected a large number of old functions due to poor development and testing quality, thus putting the quality of the project in jeopardy?
Have you ever encountered a situation where the testing time was compressed in the later stages of the project to ensure project progress due to poor development and testing quality?
Have you ever encountered a situation where the developer promised that there would be no problem this time, but the test data failed to pass after a slight modification?
Whether you have encountered them or not, I have encountered them all.
Some people say that this development is too weak, why not self-test?
Some are indeed caused by the lack of self-test, but some developers did test themselves, but the results of the self-test are fine.
On the one hand, when developing self-tests, you usually conduct self-tests on the content you have modified. In this case, you often cannot find any problems. After all, you are too familiar with your own code.
On the other hand, when developing self-tests, most of them are based on debugging to see the effects. It is not a real user environment, not even a test environment, so the effect of this kind of self-test is very poor.
So is there any good solution?
Here are some operational suggestions for your reference:
1. Provide developers with the environment they need for self-testing
For example, our software is a Windows client, which often needs to cover different Windows system versions. Many developers do not have a comprehensive system version environment, so when testing, they will only conduct self-tests in an environment they commonly use.
Sometimes when problems arise, their excuses may be that they don’t have a ready-made environment, it takes too much time to build the environment, etc. Well, we can just provide the various ready-to-use environments they need. Anyway, we test It is also necessary to prepare for various environments.
In fact, after communicating with several developers, I found that they are quite happy to have these environments, so it may not be that they don't want to test themselves.
So since you can get the best of both worlds, why not.
2. Provide test cases for developers to self-test
After we received the test notification from the developer, the common dialogue was "Have you self-tested?", "I really did the self-test this time." When the result was smoke and there was still a problem, the developer came over with a shocked expression. Look, I'm sorry, we considered this scenario, but I did test myself. You can see that if the test data is changed to this, it will definitely be fine.
Yes, it’s not that there is nothing wrong with self-test, it’s just that the content of the test is different from what we expected, that is, everyone’s understanding of “self-test” is different, so we can clarify the detailed requirements for self-test.
At present, the method used by several students in our group is to directly throw them to the use cases for developing smoke tests. These use cases must be passed before they can be tested.
The developers are actually quite happy to do this. After all, the goal is clear and it can avoid repeated low-quality testing, so why not do it.
3. Provide pre-automated verification during test preparation
The two methods mentioned above are both manual intervention. Since it is manual intervention, it will involve human uncontrollability. In order to avoid problems caused by human factors, we have added the automation of some necessary checkpoints in the testing system. Detection logic.
For example, the inspection of file signature attributes, on the one hand, is a common inspection requirement for all files, and on the other hand, the inspection specification requirements are very clear, so this type is particularly suitable for automated implementation. If there is a problem with the inspection, the test will be directly blocked. , Reduce time waste caused by interaction.
Here is a reminder that all blocked items must be clearly explained to avoid the embarrassment of developers not knowing why they are blocked and not knowing how to modify them.
4. Provide automated use cases for smoke testing
In some projects with a relatively high degree of automation implementation, if there are already major use cases that have completed automated use case coverage, it is completely possible to integrate automated execution into the testing process. Automated use case inspection must be carried out before testing.
In this way, on the one hand, it can save time to develop and prepare the environment. On the other hand, the development focus on use cases can also be weakened. All results and problems can be improved in the implementation of automated use cases.
In fact, for some projects that require development and sufficient unit testing, none of the above worries are necessary, because the solutions we provide are included in the unit testing requirements.
However, based on the current situation in China, there are not many projects that can fully carry out unit testing, so the task of quality assurance falls entirely on the testers.
Some students may have some questions about the above method, such as whether there are too many tests. The requirements for testing quality are originally required by development. Now they can't do it, but they still ask the test to help them do so many extra things. , so unreasonable.
In fact, I thought so before, but later I discovered that the main job responsibility of test engineers is actually quality assurance, so testing can promote all things related to quality assurance. This is also the reason why many companies have derived SQA.
If you think about it from the perspective of quality assurance, are the above things necessary? They just preempt some things that testers need to do, but the benefits are much greater than the investment. After all, everyone knows that the cost of correcting problems when discovered early is much lower than the cost of correcting problems later.
Above, if you have any views and ideas about smoke testing, please leave me a message to discuss.
The following are supporting learning materials. For those who are doing [software testing], it should be the most comprehensive and complete preparation warehouse. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you!
