Recent Posts

QTP & Keyword Driven Testing

Tricky Questions in QTP

Asset Upgrade tool in QTP

New Features in QTP 10

Nov 20, 2008

Inspection Entry Criteria and Kick-Off Meeting

Subscribe the QA and Software Testing Newsletter
Post Your Queries | QA and Testing - Table of Contents

SPONSORED LINKS Reading: Inspection Entry Criteria and Kick-Off MeetingTweet this Post

Formalized Software Inspections are massively parallel communication forums, which are highly effective for defect detection, learning of best practices and supporting an open, yet disciplined company culture.


Figure 1: Below shows the sequence of events in a typical inspection process.

This month we will look at entry criteria and the kick-off meetings for inspections.


Entry Criteria


The pre-requisites for a successful software inspection process entry are:

  • Some product (document) to inspect. Candidate documents are requirements specifications, project management plans, design documents, contracts, test plans, test procedures, source code, technical documentation, user manuals and any other documentation relevant to a software system.
  • Senior Managements' understanding and support for the process.
  • Training of personnel who will be involved in the inspections.
  • Someone to champion the inspection process.


To be eligible for inspection, the product document itself must meet certain quality (entrance) criteria. The author will submit a document to an inspection moderator, who will randomly take one or two sample pages from the document and inspect these. If the defect density is too high, relative to the current prescribed company standard, the product will need to be re-worked and then re-submitted for entrance to the inspection process. The average reported defect rates for a specification is seven to twenty-two major defects per page of specification! Each major defect will result in approximately ten hours of down-the-line time wastage for project members who are negatively impacted by it.


This means that companies, that are mature enough to measure and report defect densities, have specifications which will cause re-work efforts of about one hundred and fifty hours per page prior to beginning a formal inspection process! Companies who are less mature or rigorous about their software development process will experience even greater inefficiencies.


Assuming the product passes the entry criteria, the inspector and/or the author may still decide to limit the number of pages to be inspected. Inspections take in the order of one hour per page of material per person. Don't stop reading now! Remember we can potentially save one hundred eand fifty hours of re-work per page inspected. If pages to inspect are reduced, then typically the pages that will be inspected will include higher risk or higher-business benefit areas of the system.


Kick-Off Meeting

The inspection moderator will now prepare the pages for inspection. Each selected page will have its lines numbered sequentially. This then forms a reference for reporting defects found. Inspectors simply quote the page and line number where each defect is located. This avoids time-consuming communication of the sort, "third paragraph, fourth sentence after the bulleted list".

In addition to the numbered pages for inspection, the moderator will supply input documentation such as the original user request for functionality, company standards, rules and checklists. The rules and checklists form a critical component of the inspection process. Each defect discovered is related to a rule, which has been broken. The rules are selected to help inspectors discover major errors in preference to minor errors. A major error is a defect, which, in the inspector's opinion would cause more than 10 hours of re-work in later project phases if left un-repaired.


This emphasis on finding major errors helps to prevent the inspection processes becoming trivialised. (There is a class of reviews where candidates do not properly prepare, and in order to report errors, pick on limited-value defects such as the format of the document, spelling errors, incorrect font size and types and other frustrating trivia). Inspection moderators take great pains to avoid such occurrences, and effective rules help inspectors to achieve technical relevance and value. Inspection rules are limited to a maximum of one A4 page per candidate role, and each rule is assigned a code.

In the next issue we will continue to discuss the kick-off meeting, identifying the participants of inspections, the assignment of roles, and the detailed private inspection process.



Wayne Mallinson (Original Source)

SPONSORED LINKS

Comments :

0 comments to “Inspection Entry Criteria and Kick-Off Meeting”

Software testing Metrices-Test Case Review

Metrics are the means by which the software quality can be measured; they give you confidence in the product.

 

Energize your test team

You're waist deep in your third month of late nights, weekends, and shipping stress; you can see and feel your team's energy waning.

 

The Value of Positive Testing

There is a school of thought in software testing that debunks the value of positive testing. This school basically states that any test that does not produce a defect is not a good test.

Impact Analysis Checklist for Req. Changes
___    Implications of the Proposed Change* Identify any existing requirements in the baseline that

The Process of Test Process Improvement

Software testing is still a pain-in-the-neck for many organizations. Because it is only marginally addressed in software process improvement models like CMMi

 

Software Defect-bug Management Philosphy

Imperfect processes cause most of the software defects. Thus to prevent defects, the development process needs to be overhauled.

 

Software testing Metrices-Test Case Review

Metrics are the means by which the software quality can be measured; they give you confidence in the product.

 

Energize your test team

You're waist deep in your third month of late nights, weekends, and shipping stress; you can see and feel your team's energy waning.

 

The Value of Positive Testing

There is a school of thought in software testing that debunks the value of positive testing. This school basically states that any test that does not produce a defect is not a good test.

Blog Archive