Can Testing guarantee Defect Free Delivery?

I am sending some answers which I had received from my friends.

Kindly have a look and if any more comments in addition then do let me

know...

1.     Based on the test cases and scenarios covered (passed) we can say or we can

guarantee that defect would not be there while performing the following

operations.

But there are hundreds and thousands of other scenarios which are not

covered in the test case. So we cannot say that a Testing guarantee Defect

Free Delivery. It is just a method of find out, whether in the test cases

written, we had defects.

2.     *Testing can't guarantee you a defect free Delivery. But with the help of

testing you can improve quality of your software. *

*If you find a bug at delivery phase (or any Later Phase). then the cost of

fixing that bug is very high as compare to cost of fixing same bug at any

previous stage (i.e. designing phase or coding phase). The main mission of

testing is to find Bug. In this way testing will help you to find bug in

early stages of development cycle, which in turn improve quality of

software and also decreases the chances of failure of that software in Real

world. *

* *

*With the help of testing you can't guarantee a defect free Delivery but you

can guarantee a more stable* product.*

*More Stable: Less Bugs, Risk of failure is nearly Zero, Good performance,.*

3.     Positive:

If testing is done keeping high risk areas in my mind and by proper

planning and analysis then we can ensure that delivery is defect free.

Negative:

Exhaustive testing is not possible because a system can take infinite

number of possible inputs combinations. So, we can ensure that after the

testing our product is defect free.

4.     Testing is an never ending process and can never confirm defect free

delivery, unless the object in test is too simple. The more you dig, the more

you get.

According to me, testing can just give confidence to the customer/vendor

by improving the product in test to an acceptable level of quality.

'Acceptable level' again depends on the criticality of the object in test.

5.     Yes testing *can *guarantee delivery of defect free software provided ALL

THE DEFECTs have been detected and revealed by testing, fixed by

Developers AND ALL retested by testers again. However, this is only

possible when Exhaustive testing is carried out, which is not possible

to carry out in real life scenarios. Because it involves huge costs and

large time scales in performing exhaustive testing which is not practically

possible and not feasible in real scenarios.

6.     No Testing Can never guarantee defect free delivery.

Testing is only a risk reduction process but not risk

removal process. Therefore, the number of defects in the software or

system can be reduced but cannot be removed totally at any point of time.

7.     Testing cannot give guarantee of defect free delivery, because 100 %

testing is not possible, there could be defect in any phase. Defect show the presence of defect not show the defects are present.

8.     Testing wouldn't guarantee for Defect Free Delivery, but of course will

definitely improve the confidence of the customer that he would get right product in a right way.

Highest ideals we need to practice in our daily life

The mind can act as a bridge leading man from the tangible to the intangible, from the personal to the impersonal. Cleanse the mind and mould it into an instrument for loving thoughts, for expansive ideas. Cleanse the tongue and use it for fostering fearlessness and friendship. Cleanse the hands; let them desist from injury and violence. Let them help and lead, heal and guide. This is the highest spiritual practice.

Estimating Defects by Function Point

There is a strong relationship between the number of test cases and the number of function points. As expected there is a strong relationship between the number of defects and the number of test cases and number of function points.

The number of acceptance test cases can be estimated by multiplying the number of function points by 1.2. Like function points, acceptance test cases should be independent of technology and implementation techniques.
For example, if a software project was 100 function points the estimated number of test cases would be 120. To estimate the number of potential defects is more involved.
Estimating Defects
Intuitively the number of maximum potential defects is equal to the number of acceptance test cases which is 1.2 x Function Points.

Preventing, Discovering and Removing Defects
To reduce the number of defects delivered with a software project an organization can engage in a variety of activities. While defect prevention is much more effective and efficient in reducing the number of defects, most organization conduct defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects.
Defect Removal Efficiency

If an organization has no defect prevention methods in place then they are totally reliant on defect removal efficiency.

1. Requirements Reviews up to 15% removal of potential defects
2. Design Reviews up to 30% removal of potential defects
3. Code Reviews up to 20% removal of potential defects
4. Formal Testing up to 25% removal of potential defects

In other words, if your organization is great at defect removal the maximum percentage of defects your organization can expect to remove is 90%. If a software project is 100 function points, the total number of maximum (or potential) defects could be 120. If you were perfect at defect removal your project would still have up to 12 defects after all your defect discovery and removal efforts. The far majority of organization would receive a B (medium) or even a D (poor) at defect removal efficiency.

Activity	Perfect	Medium	Poor
Requirements Reviews	15%	5%	0%
Design Reviews	30%	15%	0%
Code Reviews	20%	10%	0%
Formal Testing	25%	15%	15%
Total Percentage Removed	90%	45%	15%

Defect Discovery and Removal

Size in Function Points		Totals Defects Remaining
	Max Defects	Perfect	Medium	Poor
100	120	12	66	102
200	240	24	132	204
500	600	60	330	510
1,000	1,200	120	660	1,020
2,500	3,000	300	1,650	2,550
5,000	6,000	600	3,300	5,100
10,000	12,000	1,200	6,600	10,200
20,000	24,000	2,000	13,200	20,400

An organization with a project of 2,500 function points and was about medium at defect discovery and removal would have 1,650 defects remaining after all defect removal and discovery activities. The calculation is 2,500 x 1.2 = 3,000 potential defects. The organization would be able to remove about 45% of the defects or 1,350 defects. The total potential defects (3,000) less the removed defects (1,350) equals the remaining defects of 1,650.
Defect Prevention

If an organization concentrates on defect prevention (instead of defect detection) then the number of defects inserted or created is much less. The amount of time and effort required to discover and remove this defects is much less also.
1. Roles and Responsibilities Clearly Defined up to 15% reduction in number of defects created
2. Formalized Procedures up to 25% reduction in number of defects created
3. Repeatable Processes up to 35% reduction in number of defects created
4. Controls and Measures in place up to 30% reduction in number of defects created
Imagine an organization with items 1 and 2 in place. A project with 100 function points would have a potential of 120 defects, but since they have preventative measures in place, they can reduce the number of potential defects by 48 (40% = 25% + 15%). That makes the potential number of defects 72 compared to 120 with no preventative efforts. Assuming that an organization was medium at defect discovery and removal they could remove 45% of the remaining defects or have 40 remaining when the project rolled to production.

Defect Removal	Max Defects	Prevention	Medium
100	120	72	40
200	240	144	79
500	600	360	198
1,000	1,200	720	396
2,500	3,000	1,800	990
5,000	6,000	3,600	1,980
10,000	12,000	7,200	3,960
20,000	24,000	14,400	7,920

The above table represents the number of defects that an organization that does items 1 and 2 above and is medium at discovery and removal.
The problem for estimating defects is multidimensional. First the total number of defects must be estimated. Second the impact of defect prevention needs to be understood and the estimated number of defects adjusted. Third an assessment needs to be done to understand how many defects can be discovered and removed by an organization.
Clearly, the fewer number of defects that an organization must discover and remove the better. The way this is accomplished is by better process, a more stable organization and repeatable processes. The focus of software organizations needs to be on defect prevention instead of defect detection.

Check list for Conducting Unit

• Is the number of input parameters equal to number of arguments?
• Do parameter and argument attributes match?
• Do parameter and argument units system match?
• Is the number of arguments transmitted to called modules equal to number of parameters?
• Are the attributes of arguments transmitted to called modules equal to attributes of parameters?
• Is the units system of arguments transmitted to called modules equal to units system of parameters?
• Are the number of attributes and the order of arguments to built-in functions correct?
• Are any references to parameters not associated with current point of entry?
• Have input only arguments altered?
• Are global variable definitions consistent across modules?
• Are constraints passed as arguments?
• When a module performs external I/O, additional interface tests must be conducted.
• File attributes correct?
• OPEN/CLOSE statements correct?
• Format specification matches I/O statement?
• Buffer size matches record size?
• Files opened before use?
• End-of-file conditions handled?
• Any textual errors in output information?
• improper or inconsistent typing
• erroneous initialization or default values
• incorrect (misspelled or truncated) variable names
• inconsistent data types
• underflow, overflow and addressing exceptions
• Has the component interface been fully tested?
• Have local data structured been exercised at their boundaries?
• Has the cyclomatic complexity of the module been determined?
• Have all independent basis paths been tested?
• Have all loops been tested appropriately?
• Have data flow paths been tested?
• Have all error handling paths been tested?

Web Testing Checklist Part 3

General

• Pages fit within the resolution(800x600)
• Design works with liquid tables to fill the user's window size.
• Separate print versions provided for long documents (liquid tables may negate this necessity). Accommodates A4 size paper.
• Site doesn't use frames.
• Complex tables are minimized.
• Newer technologies are generally avoided for 1-2 years from release, or if used alternative traditional forms of content are easily available.

Home vs. Subsequent Pages & Sections

• Home page logo is larger and more centrally placed than on other pages.
• Home page includes navigation, summary of news/promotions, and a search feature.
• Home page answers: Where am I; What does this site do; How do I find what I want?
• Larger navigation space on home page, smaller on subsequent pages.
• Logo is present and consistently placed on all subsequent pages (towards upper left hand corner).
• "Home" link is present on all subsequent pages (but not home page).
• If subsites are present, each has a home page, and includes a link back to the global home page.

Navigation

• Navigation supports user scenarios gathered in the User Task Assessment phase (prior to design).
• Users can see all levels of navigation leading to any page.
• Breadcrumb navigation is present (for larger and some smaller sites).
• Site uses DHTML pop-up to show alternative destinations for that navigation level.
• Navigation can be easily learned.
• Navigation is consistently placed and changes in response to rollover or selection.
• Navigation is available when needed (especially when the user is finished doing something).
• Supplimental navigation is offered appropriately (links on each page, a site map/index, a search engine).
• Navigation uses visual hierarchies like movement, color, position, size, etc., to differentiate it from other page elements.
• Navigation uses precise, descriptive labels in the user's language. Icon navigation is accompanied by text descriptors.
• Navigation answers: Where am I (relative to site structure); Where have I been (obvious visited links); Where can I go (embedded, structural, and associative links)?
• Redundant navigation is avoided.
• Functional Items
• Terms like "previous/back" and "next" are replaced by more descriptive labels indicating the information to be found.
• Pull-down menus include a go button.
• Logins are brief.
• Forms are short and on one page (or demonstrate step X of Y, and why collecting a larger amount of data is important and how the user will benefit).
• Documentation pages are searchable and have an abundance of examples. Instructions are task-oriented and step-by-step. A short conceptual model of the system is available, including a diagram that explains how the different parts work together. Terms or difficult concepts are linked to a glossary.

Linking

• Links are underlined.
• Size of large pages and multi-media files is indicated next to the link, with estimated dowload times.
• Important links are above the fold.
• Links to releated information appear at bottom of content or above/near the top.
• Linked titles make sense out of context.
• If site requires registration or subscription, provides special URLs for free linking. Indicates the pages are freely linkable, and includes and easy method to discover the URL.
• If site is running an ad, it links to a page with the relevant content, not the corporate home page.
• Keeps linked phrases short to aid scanning (2-4 words).
• Links on meaningful words and phrases. Avoids phrases like, "click here."
• Includs a brief description of what the user should expect on the linked page. In code:
• Uses relative links when linking between pages in a site. Uses absolute links to pages on unrelated sites.
• Uses link titles in the code for IE users (preferably less than 60 characters, no more than 80).

Search Capabilities

• A search feature appears on every page (exceptions include pop-up forms and the like).
• Search box is wide to allow for visible search parameters.
• Advanced Search, if included, is named just that (to scare off novices).
• Search system performs a spelling check and offers synonym expansion.
• Site avoids scoped searching. If included it indicates scope at top of both query and results pages, and additionally offers an automatic extended site search immediately with the same parameters.
• Results do not include a visible scoring system.
• Eliminates duplicate occurances of the same results (e.g., foo.com/bar vs. foo.com/bar/ vs. foo.com/bar/index.html). Page Design
• Content accounts for 50% to 80% of a page's design (what's left over after logos, navigation, non-content imagery, ads, white space, footers, etc.).
• Page elements are consistent, and important information is above the fold.
• Pages load in 10 seconds or less on users bandwidth.
• Pages degrade adequately on older browsers.
• Text is over plain background, and there is high contrast between the two.
• Link styles are minimal (generally one each of link, visited, hover, and active states). Additional link styles are used only if necessary.
• Specified the layout of any liquid areas (usually content) in terms of percentages.

Fonts and Graphics

• Graphics are properly optimized.
• Text in graphics is generally avoided.
• Preferred fonts are used: Verdana, Arial, Geneva, sans-serif.
• Fonts, when enlarged, don't destroy layout.
• Images are reused rather than rotated.
• Page still works with graphics turned off.
• Graphics included are necessary to support the message.
• Fonts are large enough and scalable.
• Browser chrome is removed from screen shots.
• Animation and 3D graphics are generally avoided.

Content Design

• Uses bullets, lists, very short paragraphs, etc. to make content scannable.
• Articles are structured with scannable nested headings.
• Content is formatted in chunks targeted to user interest, not just broken into multiple pages.
• No moving text; most is left-justified; sans-serif for small text; no upper-case sentences/paragraphs; italics and bold are used sparingly.
• Dates follow the international format (year-month-day) or are written out (August 30, 2001).

Writing

• Writing is brief, concise, and well edited.
• Information has persistent value.
• Avoids vanity pages.
• Starts each page with the conclusion, and only gradually added the detail supporting that conclusion.
• One idea per paragraph.
• Uses simple sentence structures and words.
• Gives users just the facts. Uses humor with caution.
• Uses objective language. Folder Structure
• Folder names are all lower-case and follow the alpha-numeric rules found under "Naming Conventions" below.
• Segmented the site sections according to:
  Root directory (the "images" folder usually goes at the top level within the root folder)
  Sub-directories (usually one for each area of the site, plus an images folder at the top level within the root directory)
  Images are restricted to one folder ("images") at the top level within the root directory (for global images) and then if a great number of images are going to be used only section-specifically, those are stored in local "images" folders

Naming Conventions

• Uses clients preferred naming method. If possible, uses longer descriptive names (like "content_design.htm" vs. "contdesi.htm").
• Uses alphanumeric characters (a-z, 0-9) and - (dash) or _ (underscore)
• Doesn't use spaces in file names.
• Avoids characters which require a shift key to create, or any punctuation other than a period.
• Uses only lower-case letters.
• Ends filenames in .htm (not .html).

Multimedia

• Any files taking longer than 10 seconds to download include a size warning (> 50kb on a 56kbps modem, > 200kb on fast connections). Also includes the running time of video clips or animations, and indicate any non-standard formats.
• Includes a short summary (and a still clip) of the linked object.
• If appropriate to the content, includes links to helper applications, like Adobe Acrobat Reader if the file is a .pdf.

Page Titles

• Follows title strategy ... Page Content Descriptor : Site Name, Site section (E.g.: Content Implementation Guidelines : CDG Solutions, Usability Process )
• Tries to use only two to six words, and makes their meaning clear when taken out of context.
• The first word(s) are important information-carrying one(s).
• Avoids making several page titles start with the same word. Headlines
• Describes the article in terms that relate to the user.
• Uses plain language.
• Avoids enticing teasers that don't describe.

CSS

• Uses CSS to format content appearance (as supported by browsers), rather than older HTML methods.
• Uses a browser detect and serve the visitor a CSS file that is appropriate for their browser/platform combination.
• Uses linked style sheets.

Documentation and Help Pages

• When using screen shots, browser chrome was cropped out.
• Hired a professional to write help sections (a technical writer).
• Documentation pages are searchable.
• Documentation section has an abundance of examples.
• Instructions are task-oriented and step-by-step.
• A short conceptual model of the system is provided, including a diagram that explains how the different parts work together.
• Terms or difficult concepts are linked to a glossary.

Content Management
Site has procedures in place to remove outdated information immediately (such as calendar events which have passed).