Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Doc 35 When is Software Ready to Ship

Doc 35 When is Software Ready to Ship



|Views: 285|Likes:
Published by Kapildev

More info:

Published by: Kapildev on Nov 29, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as RTF or read online from Scribd
See more
See less


Syntel CQA Forum When is the Software ready to Ship CQA Doc No 35
Deciding when software is ready to ship is a difficult one. You have pressure from allsides to release perfect software, with added features yesterday. The engineers havesaid that the code was complete months ago, but are still making code changes. Salespeople promised the software to major accounts months ago and are makingcommitments for the next release. The product manager wants a few more featuresadded and you want to release a zero defect software. Having no specific releasecriteria, many organizations wait for the manager to say "Ship it", not knowing whenor why the decision was made at that time. In other cases, there is a general groupconsensus to just push the software out the door because the tired and stressed groupwants to move out from the seemingly never ending cycles. You can never take all of the stress out of shipping good software, but by planningahead and setting up a good defect tracking repository, predetermining acceptablebug counts, properly testing the software and effectively triaging the defects you canalways know the current state of the software, but most importantly know when thesoftware is ready to ship.
Defect Tracking Repository
 The most important tool to determine the state of the software is the defect trackingrepository. The repository must include the following information:
A short descriptive name for the defect
A description of the defect
 The actual results if the testers test
 The expected results of the testers test
 The steps to recreating the defect
 The version in which the defect was found
 The module in which the defect was found
 The severity of the defect
Resolution notes The repository must be able to provide information required for the triage process. The team should be able to query the database and gather information such as defectcounts at various severity levels, and module levels, descriptions of the defects andsteps to reproduce them. The repository becomes the archive for the project and itbecomes important that correct and complete information be entered in order to usethis information for later projects as a planning tool.
Predetermined Acceptable Bug Counts
 The goal of shipping software with no defects cannot be achieved given the limitedtime and resources so, in the preliminary planning of the project exit criteria must beset up. The exit criteria should then be translated into the test plan outline, whichshould include acceptable bug count levels in order to ship the software. The exact acceptable bug count level is not some magic number that will insure asuccessful product, but more a target goal that the group can use to see that they aremoving forward toward a common goal. An acceptablebug count statement may look like this:
Showstoppers - There may not be any
High - There may not be any
Medium - There may not be any in specified core areas. There may not be any thathave a high probability of appearance to the customer
Low - There may be a minimal amount in specified core areas and all other areasmay have any amount.
Doc 35 When is Software Ready To Ship Page 1 of 3
Syntel CQA Forum When is the Software ready to Ship CQA Doc No 35
In order for the entire group to know the state of the software at all timesit would bepreferable to produce a weekly build grading procedure. The idea is that each weekthe build would be treated as if it were the software to be shipped and given a grade. The weekly grade keeps the team current on the software state and the team can seethe software progressively improve. This quantitative method takes a lot of the guesswork out of the equation.
Proper Testing
 The key to shipping quality software is finding and fixing all defects. The testersresponsibility becomes finding the defects and properly reporting them. In order forthe testers to find the defects the lead tester must set up in the test plan outline, thespecific stages of testing to ensure that the process is organized and covers allaspects of the software. The test plan may look as follows:
Phase 1- Test Case and Test Suite Planning
Phase 2 - Unit Testing
Phase 3 - Regression Testing
Phase 4 - System Testing
Phase 5 - Regression testing
Phase 6 - Performance Testing
Phase 7 - Release Candidate Testing The goal is to turn up as many defects as early as possible in order to make the fixeseasier on the engineers and to provide ample time for regression testing since everytime the code is altered there is a greater risk of creating more defects.As important as finding the defect, the tester must be able to correctly report it in therepository. This becomes extremely important in large projects where the defectcounts may rise in the thousands.
Effective Triage
 The Lead Tester and Engineer must sit down regularly to evaluate the reported defectsand drive the process forward in the most efficient manner for the engineers as wellas the testers. Much of the decision making here is based on queries from the defectrepository, which shows the importance of the accuracy and completeness of therepository. The creation of a "Hot List" which is a list of important bugs is a great tool to create. This list is a spreadsheet, which identifies the most important defects, their moduleand a brief description. The "Hot List" is great to use in triage to identify the defectaction items for the upcoming week.Defects that prevent further testing in a certain area must be given precedence andthe engineers can assist in the risk analysis of future modules to assist the testers intheir test case development. In the determination of what to fix next generally it isadvantageous to group and fix defects relating to the same module at the same timeeventhough there may be other important defects in other modules. Grouping of defects
Doc 35 When is Software Ready To Ship Page 2 of 3

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->