Say if it is just a spelling mistake, you might as well just talk to the person who created the document and have it fixed. Again, it depends on the extent of damage a certain defect will do. The documentation requirement, or review comments, everything could be a defect. In every phase of testing, it could be requirement errors, or it could be an application error. The point of raising a defect and tracking it is the only way you can make sure that a change you would want to happen is actually address, so you first raise a red flag. Say you are reading your functional definition document and you found that something’s wrong with it, go raise a documentation defect and assign it to the person concerned. That is not just confined to the application it could be in a document also. You’re in the requirement analysis phase, and found the requirement that is just not right and you cannot test it, so do you raise a defect at that time? The answer is, you could, depending on the defect management process, product protocol, that you have defined in the project, you could raise a defect anytime you find a difference in the expected and actual, you should raise a defect. Basically one thing we need to get straight is, defects are going to be in every phase of testing. No matter how minor the role is until test execution, defects do come up in every phase of the testing. Although, it is predominantly where defects come into picture. A defect is not specific to the execution phase. We had several rounds of reviews, as in, when we move on from the testing phase, and anytime you find that there is something not quite right with the document, something that’s not quite right with the requirement, in that case also, most of the time, defects are raised. So let me ask you a question- when do we encounter defects? To be more specific, at what phase of testing, in what phase in the SDLC software test life-cycle, do we encounter defects? Predominantly, in the test execution phase, but that doesn’t mean it’s limited to the test execution phase. Basics of defectsĪ defect is nothing but, any deviation from the expected value. Most of the time this means a peer review or reviewing your own work. Anytime you write a document, we’ve gone through the formal review process, so desk-checking is another word for reviewing, it is a verification technique. Understand how software is tested at ĭesk-checking is nothing but reviewing. The defect life cycle is a part of risk management, which has several sub-topics to cover. To properly handle projects, you not only need to know how to deal with development and release, but you also need to know how to handle defects. In such cases, a closed defect will be re-opened.Just like the life cycle of a program, a defect cycle occurs from the time a defect is found to the point it is fixed. During the second upgrade release the same defect again re-surfaced. Consider a situation where during the 1st release of Flight Reservation a defect was found in Fax order that was fixed and assigned a status closed. If the test cases fail again, the defect is re-opened and assigned to the developer. In case, the Test Case passes the defect is closed.
0 Comments
Leave a Reply. |