About
TestThe normative and the importance, combined with the past experience, made a few simple thinking, is now recorded as follows
1, after the change of the bug, before the transfer test regression, the development of the internal to self-verification.
This is a tradition, but it is recommended not to rely solely on the existing readmine system (a company's bug management System), because its built-in process, only support one person audit problem, so often not accurate, it is possible to return to not pass. Therefore, it is recommended to use Excel to track, the key is to carry out two rounds or even many people audit, so that can reduce the probability of regression.
Here are 2 points worth summarizing, first of all, 2 rounds of audit process, followed by not relying on the existing bug management system. This is reasonable, if there is no bug management system, the bug is not tracking it? So any system is just a tool, play an auxiliary role, the key is the awareness of the bug tracking management
2, after the bug modification, in the DTS fill in the problem single processing process, should pay attention to the specification.
I'm not quite certain about this point, because I haven't realized the value of the specification filling out the questionnaire. But from another point of view, for the already relatively mature team, may not rely on this management tool. However, since our development team is still relatively young, these management tools are necessary. Regardless of the specification to fill out the questionnaire, to the bug management itself can bring much value, at least through the requirements of staff to fill out the questionnaire, can cultivate staff executive ability, which to promote the team's maturity is very helpful.
The more mature the team, the more tacit understanding, the smaller the cost of management, the less necessary management tools. Conversely, when the team is not mature, employees generally weak, these management tools are necessary
3, about the transfer test
Test documentation, including "Release Notes", "Installation/upgrade Instructions", "Test Recommendations", "Smoke test Results", "description of legacy issues"
These documents, related to the management of the transfer test process, seeTest-Driven development – we want more than "quality" (ext. 51testing)
4. Version release specification
It is mentioned in the version specification that an untested version is not allowed to be issued. This is critical and deserves to be written down separately.
Untested versions cannot be published, this principle is very simple, but can be extended
4.1, version A has been transferred to test, the test process found a problem, this time can not be replaced with Xxx.class it?
Certainly not, the so-called version, should be a complete package. If you replace the file directly, there is no guarantee that the integrity of the package, the replacement version, is equivalent to a new untested version. The test before the replacement is strictly equivalent to invalid. If you want to send it out, you need to test it again.
The right approach is to take this issue as a legacy, evaluate its impact, and write it in the list of legacy issues. The version is still issued normally, this problem can be modified later, the next version to be tested. If the problem is serious, is the version of the serious defects, not outgoing, then you can add a round of tests, the return after the release
4.2, version A to test, after the test, testing can be found to develop a new package, publish it?
No, because this new package is not guaranteed to be exactly the same as the tested version, then this new package, which is an untested version
The correct approach should be to send out the test version. That is: What version is the test, and what version is sent after the test is finished?
4.3, the site found a few problems, the development of the patch provided only a few files, you can not hit the label, sent directly to it?
No, the so-called version, in addition to "integrity", also requires an "identifiable", just like the primary key of the data, can uniquely identify a version. Without "identifiable", it is not a version. As soon as a version is released, there is a possibility of locating the problem and fallback. If you don't have a tag, you can't do it when you need to locate the problem, or you need to go back later.
The right way to do this is to make sure to label the code base as soon as it is issued. It can be labeled with a version number, such as b010,spc001, or it can be tagged with time, such as tag_20120719
After the tag, at any time, whether to build the scene of the mirror environment, or rollback, or compare two versions of the difference production upgrade package can be done
The standardization and importance of the testing process
