ASK ChapterBM "Enter the chapter number" chapter SEQ chapter \* Arabic \r 7
THIS PAGE LEFT INTENTIONALLY BLANK
|
Explain This is the third of four modules examining the MSF process model in detail. It examines the activities and deliverables that lead to the scope complete milestone. |
|
Explain At this point in the project, the team should have developed all features, but these features might not be stable. In other words, they might still have bugs. The product should be ready for the stabilizing phase, which means that there are no issues that could block testing. Emphasize This milestone offers customers, end users, operations and support personnel, and all other key project stakeholders the opportunity to identify any issues they want addressed before the product ships. Essentially, reaching this milestone means that no new code will be written. Only stabilization is left. |
At the scope complete milestone:
n &n 12212l1119m bsp; All features of the product should be in place, although they might not be fully functional.
n &n 12212l1119m bsp; The product should be ready for formal stabilization and should have no issues that could block testing.
n &n 12212l1119m bsp; Team members and key stakeholders should have agreed on what features to include and whether they have been developed.
n &n 12212l1119m bsp; Materials to support user performance should be baselined and ready for their own stabilization process.
|
Explain Until now, the team has focused on planning and preparation. During this phase the team focuses on execution. Emphasize Once again, all team members should be focused on identifying and managing risk. |
n &n 12212l1119m bsp; Product management drives the process of ensuring that customers expect what they will get and will get what they expect, while it executes on its communications plan. It also helps identify and solicit beta testers.
n &n 12212l1119m bsp; Program management tracks the project, managing plan variations and reporting progress to key stakeholders. It also plans and coordinates the beta testing process.
n &n 12212l1119m bsp; Development joins user education and testing in driving the developing phase, focusing on building the product described in the functional specification and working with testing to ensure product reliability from one internal release to another.
n &n 12212l1119m bsp; User education drives the developing phase by helping product development with such things as wizards and online help files, and creating such user support materials as manuals and reference cards.
n &n 12212l1119m bsp; Testing develops detailed test specifications and cases for each product feature and works with development to maintain product reliability and ensure the team knows all product usage issues.
n &n 12212l1119m bsp; Logistics management creates technical support documentation for the product, considers the logistical implications of the identified beta plan, and provides logistical support to the development team itself.
|
Explain Because the developing phase is all about building the product, the interim milestones measure the progress of that building. Developing is done in parallel and in segments, so the team needs a way to measure progress as a whole. Internal releases accomplish this by forcing the team to synchronize pieces at a product level. Emphasize Typically, internal releases are two to four months apart. The number and frequency of releases will depend on the size and duration of the project. Transition The next three slides offer more detail about internal releases, so avoid going into too much detail at this point. |
n &n 12212l1119m bsp; Because the developing phase focuses on building the product, the project needs interim milestones that can help the team measure the progress of that building.
n &n 12212l1119m bsp; Developing is done in parallel and in segments, so the team needs a way to measure progress as a whole. Internal releases accomplish this by forcing the team to synchronize pieces at a product level.
n &n 12212l1119m bsp; Typically, internal releases are two to four months apart. How many releases and how often they occur will depend on the size and duration of the project.
n &n 12212l1119m bsp; During the developing phase, the team should also try to achieve a visual design freeze and a database freeze, even though these are not interim milestones. The earlier the team accomplishes these freezes the better because user education needs screens to create documentation and all feature teams need the database.
|
Explain As the project team develops the product, it uses internal releases to incrementally add feature subsets until the product is complete. With each internal release the scope of development increases until the team has built the full product. Each internal release has a quality bar that the team must reach before it can achieve the internal milestone. Emphasize Each internal release has a stabilizing phase during which the team can bring the product up to quality standards and practice the stabilizing process. |
n &n 12212l1119m bsp; The project team uses internal releases to develop the product by incrementally adding feature subsets until the product is complete.
n &n 12212l1119m bsp; The scope of development increases with each internal release until the team has built the full product.
n &n 12212l1119m bsp; Each internal release has a quality bar that the team must reach before it can achieve the internal milestone.
n &n 12212l1119m bsp; Each internal release has a stabilizing phase during which the team can bring the product up to quality standards and practice the stabilizing process.
|
Explain The primary benefits of internal releases are that they make projects more understandable and more manageable and provide the team with early success. |
n &n 12212l1119m bsp; Breaking up large projects helps the team focus on more actionable project subsets that direct the team on a daily basis.
n &n 12212l1119m bsp; Internal releases are based on risk-driven scheduling, which means that the team first takes on those tasks that are riskier or more important to the customer.
n &n 12212l1119m bsp; Internal releases provide early visibility to the success and execution of the plan, which allows corrective action and early learning to occur.
n &n 12212l1119m bsp; Internal releases increase quality by providing a more stable base for new development and allowing the team to fix bugs closer to the time at which they occur rather than toward the end of the project.
|
Explain Development teams typically spend from two to four months on an internal release. For each release, they allocate time for developing, optimizing, testing, and stabilizing features. Beyond that, teams allocate approximately one-third of a release's total development time as buffer time for unplanned contingencies. |
n &n 12212l1119m bsp; To better understand internal releases, you can equate them to versioned releases, which are similar because they also involve incrementally adding functionality to a known baseline.
n &n 12212l1119m bsp; Addressing high-priority features early in the cycle helps ensure that the team can deliver these features at release. Addressing high-risk features early in the cycle allows for the greatest mitigation time and minimizes the potential for wasted effort.
n &n 12212l1119m bsp; A key aspect of internal releases is the need to get to a known state. Achieving a set quality bar provides that baseline.
n &n 12212l1119m bsp; Making releases cohesive and yet independent is important for ease of development, ease of testing, and a greater sense of closure. For example, delivering the print subsystem is more beneficial than delivering 30 unrelated features. Independent releases allow the team to see each subset as a product.
n &n 12212l1119m bsp; Reviewing the results of an internal release is a necessary part of turning the team into a learning organization that repeats best practices and learns from poor ones.
|
Explain The team might require other deliverables to achieve the scope complete milestone, depending on the nature and scope of the project, but these six are fundamental. They include a baseline of the product and the material to support user performance as well as the project documentation that is necessary to move forward. Emphasize This is by no means a comprehensive list, only a representative sampling. |
n &n 12212l1119m bsp; The revised functional specification reflects any agreed-to changes that occurred during the developing phase. This will identify new features that the team must test and document and delayed features that the team might consider for future versions.
n &n 12212l1119m bsp; The revised master risk assessment document contains not only preexisting risks but also newly identified ones. It also describes the plans for risk management and their progress to date.
n &n 12212l1119m bsp; The source code and executables represent a feature-complete, but unstabilized, version of the product. As such, the team should archive them so it can revert to a previous version if necessary.
n &n 12212l1119m bsp; Elements that support user performance range from in-product wizards to user documentation and classroom training materials. The team should baseline and archive them.
n &n 12212l1119m bsp; Testing elements are test plans, specifications, cases, and scripts that cover the full feature set of the newly baselined product. The team brings the scripts from automated testing forward into the stabilizing phase to ensure that product quality and state do not regress.
n &n 12212l1119m bsp; The revised master project plan and master project schedule reflect changes that occurred during the developing phase and describe what remains to be done and when.
|
Prepare Review the materials about this lab in the delivery guide segment for this module. Facilitate Break the class into small groups of four to six persons. After the groups have completed the exercise, ask the designated spokesperson for each group to share his or her group's results. Debrief Ensure the students are using MSF tools to address the issues in the scenarios. They should be doing due diligence and understanding the risks involved through risk assessment and then using the project trade-off triangle to balance the variables again |
The instructions for this lab are on the slide and in your lab manual. The instructor might also have additional instructions.
THIS PAGE LEFT INTENTIONALLY BLANK
|
Explain A zero-defect mindset is the team's commitment to achieve a quality product. Specifically, that means building the quality in at the time they do the work. Emphasize Having a zero-defect mindset does not mean developing a product with absolutely no defects. It is simply a goal to which the team can aspire. |
n &n 12212l1119m bsp; A zero-defect mindset is the team's commitment to achieve a quality product, with all team members holding themselves accountable for the quality of their own work.
n &n 12212l1119m bsp; A zero-defect mindset does not mean developing a product with no defects. It is simply a goal to which the team can aspire.
n &n 12212l1119m bsp; Zero-defect deliverables are not deliverables that have no defects. They are deliverables that have met a predetermined quality bar.
n &n 12212l1119m bsp; Zero-defect milestones are milestones that require the product to meet a predetermined level of quality before the milestone can be achieved.
|
Explain The central benefit to a zero-defect mindset is that it gives quality a high priority and high visibility in the project. Emphasize Because high quality is a basic customer need, a byproduct of the zero-defect mindset is a focus on meeting customer needs. |
n &n 12212l1119m bsp; Individual accountability pushes responsibility for avoiding and fixing defects onto the developer so that other team roles can focus on applying quality to their part in developing the product.
n &n 12212l1119m bsp; Writing clean code makes the product more stable because developers find and address bugs much earlier.
n &n 12212l1119m bsp; Building with high quality helps to minimize the time that the team will spend stabilizing the product. Because determining the length of the stabilization period is the most difficult phase, the overall project schedule becomes more predictable.
n &n 12212l1119m bsp; As the importance-of-planning graph illustrated, dealing with problems sooner rather than later is always less costly.
n &n 12212l1119m bsp; If quality is built in rather than "tested in," testers are free to spend more time looking at overall quality issues.
n &n 12212l1119m bsp; Focusing on quality rewards developers who do quality work, rather than those who work quickly, by letting them do more of the sort of work they enjoy.
|
Explain The key to implementing a zero-defect mindset is to understand that all work requires a predefined quality bar and that no work can be considered complete until that quality bar is reached. Transition The last bullet on this slide, referring to the importance of actions, sets up the next slide, which offers techniques for achieving a zero-defect mindset. |
n &n 12212l1119m bsp; Setting and communicating a work quality bar will set clear expectations about what level of effort is required from the team members.
n &n 12212l1119m bsp; Rewarding high-quality work fosters an environment in which people want to do high-quality work. Remember, the flip side of rewarding high-quality work is penalizing low-quality work. Beyond the natural penalties of poor work-getting stuck longer with the same code-some teams adopt formal penalties.
n &n 12212l1119m bsp; In striving for a bug-free product, remember that the ultimate definition of quality is meeting the needs of customers and end users by solving the business problem. A bug-free product that does not solve the business problem is not a quality product.
|
Explain This is a collection of specific techniques that contribute to a zero-defect mindset. We separated them from guidelines because they suggest specific things that teams can do, rather than just general approaches. Transition The last two bullets on this slide set up two especially important techniques-code reviews and daily builds. The next six slides examine those techniques in more detail. |
n &n 12212l1119m bsp; Developers should have a written test plan because it will be more thorough and comprehensive.
n &n 12212l1119m bsp; Assuming that the code is broken is crucial because then the developer must prove the quality of his work rather than the tester disproving it. Failure to find bugs doesn't mean that they are not there.
n &n 12212l1119m bsp; Fixing bugs before moving on places responsibility where it belongs and reduces the risk of defects compounding later on.
n &n 12212l1119m bsp; To get the best design, you can have two different teams independently develop a solution to the same problem and then accept the better design or use the best parts of each design.
n &n 12212l1119m bsp; Assigning bugs to someone other than the original developer to provide a new perspective can be a good problem-solving technique with code that cannot be stabilized.
n &n 12212l1119m bsp; Simply fixing bugs isn't enough. Developers should reassess the code to figure out why the bugs occurred so they can avoid repeating the mistake and can uncover other potential problems.
n &n 12212l1119m bsp; Documenting code prevents others from making wrong assumptions about it and introducing bugs, while it also supports the code by explaining the logic behind it.
|
Explain The two important points for this slide are that code reviews improve quality-for the code and for the team developing it-and that they take different forms. Code reviews are tools that teach the team to use good coding techniques and to improve the coding itself. Transition Remember that the next two slides will examine benefits and guidelines for code reviews. |
n &n 12212l1119m bsp; Code reviews, the systematic review of product or feature source code, are tools the team can use to increase code quality and educate other team members.
n &n 12212l1119m bsp; Comprehensive, formal reviews are usually facilitated, structured code presentations. They are generally used in large, complex projects and for educational purposes.
n &n 12212l1119m bsp; Casual, peer-based reviews have several purposes. They help achieve shared understanding among developers, they help mentor junior developers, and they help generate creative tension that produces higher quality code.
n &n 12212l1119m bsp; Third-party reviews give a fresh perspective to the code from people not biased by the developer's point of view. They also check that developers are adhering to project coding standards.
|
Explain Code reviews are beneficial because they're more efficient than testing and they help to identify defects earlier in the process. That, coupled with the educational benefits, makes them highly recommended practices for any team. For data backing up these benefits, read the section on technical reviews in Chapter 4.3, p. 73, in Rapid Development by Steve McConnell. |
n &n 12212l1119m bsp; Because code reviews can be implemented earlier in the development cycle, the cost of resolving defects is much lower.
n &n 12212l1119m bsp; Industry studies have determined that code reviews save a proportionately larger number of testing and maintenance hours later.
n &n 12212l1119m bsp; Code reviews make assumptions explicit by letting a developer's peers see what the developer is doing.
n &n 12212l1119m bsp; Code reviews can help enforce practices and standards by designating someone as code master to review the code for adherence.
n &n 12212l1119m bsp; Peer-based code reviews help to improve code quality by taking advantage of the natural competitiveness of developers who want only their best work reviewed by peers.
|
Explain Code reviews depend on team dynamics, culture, and size, which means that guidelines for them can't be prescriptive. Each team should find the approach that works best. These guidelines are at a high level and should apply across most or all types of code reviews. |
Scheduling reviews ensures that the team isn't tempted to drop them because of the pressures of development.
There are several reasons for using code reviews earlier in the process:
n &n 12212l1119m bsp; At that stage, team members actually have time to do them.
n &n 12212l1119m bsp; The defects are usually smaller and less costly to fix.
n &n 12212l1119m bsp; The team is new and requires the sort of guidance that code reviews provide.
n &n 12212l1119m bsp; Early reviews ensure that early development meets standards while it is moving forward.
|
Explain The daily build is a fundamental principle at Microsoft. Although it can be difficult to implement, it provides great benefits. For more information on the daily build process, read the daily build process in Chapter 5, p. 263, in Microsoft Secrets, by Michael A. Cusumano and Richard W. Selby. Emphasize "It's easy to be delusional when you're creating software but, in the face of the daily build, much potential for fantasy is harmlessly discharged." Jim McCarthy, Dynamics of Software Development. Transition The next two slides discuss the benefits of and guidelines for implementing daily builds. |
n &n 12212l1119m bsp; One of the strengths of a daily build is that it's available publicly to anyone who needs to assess the progress of the project.
n &n 12212l1119m bsp; The build is an indicator of progress because it identifies that the product is moving forward as a whole rather than as individual pieces. It's not enough for individuals to succeed. They need to succeed as a team.
n &n 12212l1119m bsp; The build provides the definitive status of the progress of the team and the product by looking at the product holistically with little room for interpretation.
n &n 12212l1119m bsp; As Jim McCarthy says in Dynamics of Software Development, the daily build serves as the heartbeat of the project. "If the daily build fails . the 'heartbeat' monitors start to screech insistently demanding emergency attention." He goes on to say that a weak pulse indicates a struggling project, whereas a strong pulse serves to reassure the team.
|
Explain The concept of a daily build has many benefits, but fundamental to them all is the fact that it gives the product life during the development process. |
One benefit of the daily build lies in just the act of putting the pieces of the product together.
n &n 12212l1119m bsp; The pieces turn into a product, which exposes the parts that aren't working properly.
n &n 12212l1119m bsp; Pieces that don't fit into the product highlight integration issues.
n &n 12212l1119m bsp; Building their pieces into the product forces team members to synchronize their efforts.
A second benefit lies in having the pieces of the product put together.
n &n 12212l1119m bsp; The team can use this testable entity to determine product status and quality.
n &n 12212l1119m bsp; Team and customer morale improve when they see that the product has a life.
A third benefit lies in how often the team puts the pieces together.
n &n 12212l1119m bsp; The source of a defect in the daily build is easier to find because it lies in the previous day's effort.
n &n 12212l1119m bsp; Frequent synchronization means that team members don't fall out of synchronization as easily.
|
Explain These are high-level guidelines that provide the broadest level of applicability. See the delivery guide for more information about the relationship between the build cycle and the potential for lost effort. |
n &n 12212l1119m bsp; Although conducting daily builds might seem unrealistic, failing to do so has risks. Defects within any build cycle have the potential to cost the team three times the effort that they have already expended during that cycle.
n &n 12212l1119m bsp; The scope of testing must increase as the scope of the product grows. Because build testing is typically automated, any new product functionality must be reflected in test scripts.
n &n 12212l1119m bsp; Attempting a build is not enough. If the build is broken, the team must stop to fix it. Not fixing it means that the team will propagate defects into future builds and will develop current code based on those defects.
n &n 12212l1119m bsp; The real issue is not what the penalty is, but that the penalty meets the team's needs for motivating excellence. For example, the culprit might contribute to a team morale fund or be responsible for the next night's build.
n &n 12212l1119m bsp; The team shouldn't let greater pressure later in the development cycle dissuade it from daily builds. The more pressure the team is under, the more it needs the benefits that the daily build provides.
THIS PAGE LEFT INTENTIONALLY BLANK
|
Explain Ultimately, the role of testing is not just to find bugs, but to assure quality. Because the ultimate definition of quality is meeting the customer's needs by solving the business problem, the testing process should support that by validating what needs to be done and verifying that it's being done correctly. Emphasize This slide, and the remaining slides in the lesson, are not about the testing role on the team, but rather about the role of the testing process in achieving quality. |
n &n 12212l1119m bsp; As explained earlier during the team module, the role of testing is to make sure that all issues are known. The testing process supports the testing role by uncovering issues.
n &n 12212l1119m bsp; On a well-functioning team, the testing process is more than just finding bugs. It is also applying quality assurance. Because the ultimate definition of quality is meeting the customer's needs by solving the business problem, the testing process should support that by validating what needs to be done and verifying that it's being done correctly.
|
Explain The testing process is not limited to the stabilizing phase. It is an integral part of the developing process as well. We have already covered internal releases, and we will cover the stabilizing phase in the next module. |
n &n 12212l1119m bsp; The testing process is not limited to the stabilizing phase. It is an integral part of the developing process as well.
n &n 12212l1119m bsp; At the project plan approved milestone, the team baselined the test plan and began work on the more detailed test specification that describes how the team will test individual features.
n &n 12212l1119m bsp; Test specification is complete at scope complete because at that point the feature set should not grow further.
n &n 12212l1119m bsp; Because scope complete represents a feature-complete baseline product, the team can consider the product to be in an alpha form.
n &n 12212l1119m bsp; Testing during stabilizing marks a shift from coverage testing to usage testing.
n &n 12212l1119m bsp; Testing first involves actual end users of the product during beta tests, which are conducted during stabilizing.
n &n 12212l1119m bsp; Tolerance for bugs decreases as testing progresses through the stabilizing phase.
n &n 12212l1119m bsp; Because the stabilizing phase is characterized by a focus on shipping, being able to successfully manage bugs is paramount.
|
Explain Testing has two basic categories-coverage, which looks to see if a feature performs as specified, and usage, which looks to see if the product meets the needs of the customers and end users. Transition The next two slides describe coverage testing and usage testing in more detail. |
n &n 12212l1119m bsp; Coverage testing involves testing features, whereas usage testing involves testing whether the product works as intended.
n &n 12212l1119m bsp; A fault is code that does not work and a failure is a program that does not work; therefore, the difference between coverage testing and usage testing is that coverage testing looks for faults and usage testing seeks out failures.
n &n 12212l1119m bsp; The transition between the developing phase and the stabilizing phase is characterized by the transition from coverage testing to usage testing.
|
Explain The following are examples of the types of coverage testing that might be done on a typical project. Unit and functional tests make up the majority of manual testing. Check-in, build verification, and regression tests tend to be automated because they are run repeatedly throughout the development process. |
n &n 12212l1119m bsp; Unit tests are done by developers with the goal of discovering bugs before testing finds them.
n &n 12212l1119m bsp; Functional tests focus on making sure that features are present and functioning properly.
n &n 12212l1119m bsp; Check-in tests are quick, automated tests that developers perform before checking code in.
n &n 12212l1119m bsp; Build verification tests are run after the daily build to verify that the product has indeed been built successfully.
n &n 12212l1119m bsp; Regression tests are automated tests that run after the daily build to ensure that the code has not regressed in quality.
|
Explain The following are examples of the types of usage testing that might be done on a typical project. |
n &n 12212l1119m bsp; Configuration tests confirm that the product runs on the target hardware and software.
n &n 12212l1119m bsp; Compatibility tests try to find bugs by looking at how the program interacts with other programs, potentially even previous versions of itself.
n &n 12212l1119m bsp; Stress tests try to find bugs by pushing the product to its limits. These include such conditions as load memory, full disks, high network traffic, and a large number of users.
n &n 12212l1119m bsp; Performance tests document how quickly the product performs. Configuration, compatibility, and stress testing may play a role.
n &n 12212l1119m bsp; Documentation and help file tests look for errors in documentation and help files. This could include defects in the content as well as deviations in the product.
n &n 12212l1119m bsp; Alpha tests are the first internal uses of the product as a whole by internal resources. Beta tests are trial uses by a subset of end users to discover issues that the product team did not find.
|
Explain Despite the widely held perception that all bugs are defects, they are not. Defects are a class of bug, but a bug is any issue that arises from using the product that is being developed. Emphasize A bug is anything that needs to be addressed and resolved before the product is released. |
Defect bug categories are:
n &n 12212l1119m bsp; Faults, which mean code that does not work, from the developer's viewpoint.
n &n 12212l1119m bsp; Failures, which mean programs that do not work, from the tester's or customer's viewpoint.
A bug is a fault or a failure, depending on the viewer's perspective.
Some bugs that are not defects are:
n &n 12212l1119m bsp; Enhancement requests.
n &n 12212l1119m bsp; Suggestions that are out of scope for the release.
n &n 12212l1119m bsp; Issues that arise over user preferences.
n &n 12212l1119m bsp; Unavoidable design consequences.
|
Explain Being determined to fix all bugs isn't enough. They have to be tracked and managed, so that the team is empowered to make necessary trade-off decisions during the stabilizing phase. Bug tracking processes encompass such issues as bug reporting, prioritization, assignment, resolution, and closure. Transition The next three slides examine bug tracking and bug classification in more detail, so avoid going too deep here. |
n &n 12212l1119m bsp; Exactly understanding the status of the product at all times is fundamental to the stabilizing phase. Bug tracking and its output is the process that will accomplish this.
n &n 12212l1119m bsp; A large part of stabilizing is managing trade-off decisions about what the team will fix and what it won't. The team must classify bugs in terms of their priority and their risk so that it can determine the proper form of resolution.
|
Explain Bug tracking starts with reporting, which is typically entered by a tester but might be entered by another team member. The development lead then determines the bug's priority and assigns it to a developer for resolution. After the developer has resolved the bug, a tester determines whether it has been resolved and whether it can be closed. |
n &n 12212l1119m bsp; Bug tracking starts with establishing some sort of bug repository, typically a bug database.
n &n 12212l1119m bsp; Newly found bugs are reported by entering them into the database. Typically a tester does this, although another team member, because of interaction with the product, might enter it. Newly identified bugs are automatically identified as active.
n &n 12212l1119m bsp; After bugs are reported, the development lead prioritizes and assigns them for resolution. Later in the stabilizing phase, the development lead might personally resolve bugs in those cases where the bug will not be fixed.
n &n 12212l1119m bsp; For those bugs that require a development-based resolution, developers typically resolve bugs through fixing them. Developers are required to test their fixes to ensure that the fix is correct and that no new bugs have been introduced. After a developer has resolved an active bug, the bug's status changes to reflect the method of resolution (that is, fixed).
n &n 12212l1119m bsp; After a bug has been fixed, testing must ensure the quality of the fix and that no new bugs have been introduced. If new bugs have been introduced, testing must enter them into the bug database, thus starting the cycle again. If the original bug has not really been fixed, the development lead changes its status from resolved to active. A successfully resolved bug is then closed.
|
Explain Bug resolution is all about priorities and risk. Classifying bugs provides a way of identifying both. Classifying bugs boils down to two important issues-severity, which addresses the impact the bug will have on the overall product if it is not fixed, and priority, which is the team's measure of the bug's importance to the stability of the product |
Typical severity level classifications are:
n &n 12212l1119m bsp; Severity 1: System crash. This class of bug causes the system to crash or to hang or otherwise stop working, with the risk of total data loss.
n &n 12212l1119m bsp; Severity 2: Major problem. This class of bug represents a serious defect in the software function, but does not necessarily risk total system failure or data loss.
n &n 12212l1119m bsp; Severity 3: Minor problem. This class of bug represents a defect in the function of the software, but not one with much risk of lost data or work.
n &n 12212l1119m bsp; Severity 4: Trivial. This class of bug represents what is primarily a minor cosmetic problem, which most users are unlikely to notice.
Typical priority level classifications are:
n &n 12212l1119m bsp; Priority 1: Highest priority. With this showstopping bug, the product can not ship and often the team cannot achieve the next interim milestone.
n &n 12212l1119m bsp; Priority 2: High priority. With this major bug, the product cannot ship, but the team may be able to achieve the next interim milestone.
n &n 12212l1119m bsp; Priority 3: Medium priority. The product can ship and the team can achieve interim milestones with medium-priority bugs. These bugs are low enough in priority that they tend to be fixed only if there is enough time at the end of the project and fixing them does not create a significant risk.
n &n 12212l1119m bsp; Priority 4: Low priority. Low-priority bugs typically are enhancement requests and bugs with such low priority that they are not worth fixing.
A typical quality bar for a product at Microsoft is that it cannot ship with known severity 1 or priority 1 bugs.
|
Explain Resolving a bug is not the final step in bug tracking. It's an interim step toward closure, which occurs only after a tester determines that fixing the bug did not create another problem. |
n &n 12212l1119m bsp; Resolving a bug is not the final step in bug tracking. It's an interim step toward closure.
n &n 12212l1119m bsp; Closure occurs only after a tester determines that fixing the bug did not create another problem and that the bug is unlikely to surface again.
n &n 12212l1119m bsp; Bugs are typically resolved as:
· &n 12212l1119m bsp; Fixed, which means the developer has fixed the bug, tested the fix, checked in the code, assigned the fix to a release number, and assigned the bug back to the tester who reported it.
· &n 12212l1119m bsp; Duplicated, which means the bug reported is a duplicate of another one that is already in the bug database. The new bug is resolved, closed, and linked to the original bug.
· &n 12212l1119m bsp; Postponed, which means the bug will not be fixed in the current release, but might be fixed in a subsequent one. This designation would be used when the team sees value in fixing the bug but does not have the time or resources to correct it.
· &n 12212l1119m bsp; By design, which means the behavior reported is intentional and is called out in the functional specification.
· &n 12212l1119m bsp; Can't reproduce, which means the developer can't verify the existence of the bug with any level of consistency.
· &n 12212l1119m bsp; Won't fix, which means the bug will not be fixed in the current release because the team does not think it's worth the effort.
|
Summarize Use these questions to reprise the essential learning points of the module. Seek out answers that show an understanding of the issues |
Now is the time to ask any further questions you might have about the material presented in this module.
THIS PAGE INTENTIONALLY LEFT BLANK
|
