The Project : a real-world context characterized by the following model project.
Application : It is a real-time system that must provide timely responses to user requests for services. It is an online system connected to remote terminals.
Staff : The programming staff consists of twenty to thirty programmers.There staff is used for system’s design.
Schedule : The project will take 24 months from the start of design to formal acceptance by the customer. Acceptance will be followed by a 6-month cutover period. Computer resources for development and testing will be almost adequate.
Specification : means requirements.
Acceptance Test : The system will be accepted only after a formal acceptance test. The application is not new, so part of the formal test already exists. At first the customer will intend to design the acceptance test, but later it will become the software design team’s responsibility.
Personnel : Management’s attitude is positive and knowledgeable about the realities of such projects.
Standards : Programming and test standards exist and are usually followed. They understand the role of interfaces and the need for interface standards.
Objectives : The system is the first of many similar systems that will be implemented in the future. No two will be identical, but they will have 75% of the code in common. Once installed, the system is expected to operate profitably for more than 10 years.
Source : One-third of the code is new, one-third extracted from a previous, reliable, but poorly documented system, and one-third is being rehosted
History : One programmer will quit before his components are tested. Another programmer will be fired before testing begins. A facility and/or hardware delivery problem will delay testing for several weeks and force second- and third-shift work. Several important milestones will slip but the delivery date will
be met.
Overview
The process starts with a program embedded in an environment, such as a computer, an operating system, or a calling program. This understanding leads us to create three models:
a model of the environment,
a model of the program,
a model of the expected bugs.
From these models we create a set of tests, which are then executed. The result of each test is either expected or unexpected. If unexpected, it may lead us to revise the test, our model or concept of how the program behaves, our concept of what bugs are possible, or the program itself. Only rarely would we attempt to modify the environment.
The Environment
A program’s environment is the hardware and software required to make it run.
For online systems the environment may include communications lines, other systems, terminals, and operators. The environment also includes all programs that interact with—and are used to create— the program under test, such as operating system, loader, linkage editor, compiler, utility routines.
If testing reveals an unexpected result, we may have to change our beliefs (our model of the environment) to find out what went wrong. But sometimes the environment could be wrong: the bug
could be in the hardware or firmware after all
Monday, February 23, 2009
Some Dichotomies in Testing
Testing versus Debugging : The phrase “ Test and Debug “ is treated as a single word.
The purpose of testing is to show that a program has bugs.
The purpose of debugging is find the error or misconception that led to the program’s failure and to design and implement the program changes that correct the error.
Note : Debugging usually follows testing, but they differ as to goals, methods and psychology.
Function versus Structure : Tests can be designed from a functional or structural point of view. In functional testing the program or system is treated as a blackbox.
Black box Testing : Here we don’t know the inter functionality we knows only about the input and the outcome. In structural testing does look at the implementation details, as programming style, control method, source language, database design and coding details.
White box Testing : Here inter functionality is considered Designer versus the Tester : Designing depends on a system’s structural details. The more you know
about the design, the likelier you are to eliminate useless tests.
Tester, test-team member or test designer contrast to the programmer and program designer. Testing includes unit testing to unit integration, component testing to component integration, system testing to system integration.
Modularity versus Efficiency : Both tests and systems can be modular. A module is a discrete, well defined small component of a system. The smaller the component, the easier is to understand but every component has interfaces with other components and all component interfaces are sources of confusion.
Smaller the component less the bugs.Large components reduce external interfaces but have complicated internal logic that may be difficult or impossible to understand.Testing can and should likewise be originated in to modular components, small, independent test cases have the virtue of easy repeatability.
Small versus Large : Programming in the large means constructing programs that consist of many components written by many different persons.Programming in the small is what we do for ourselves in the privacy of our own offices or as homework exercises in an undergraduate programming course.Qualitative changes occur with size and so must testing methods and quality criteria.
The Builder Versus the Buyer :
Just as programmers and testers can merge and become one, so can builder and buyer.
1. The builder, who designs for and is accountable to
2. The buyer, who pays for the system in the hope of profits from providing services to
The purpose of testing is to show that a program has bugs.
The purpose of debugging is find the error or misconception that led to the program’s failure and to design and implement the program changes that correct the error.
Note : Debugging usually follows testing, but they differ as to goals, methods and psychology.
Function versus Structure : Tests can be designed from a functional or structural point of view. In functional testing the program or system is treated as a blackbox.
Black box Testing : Here we don’t know the inter functionality we knows only about the input and the outcome. In structural testing does look at the implementation details, as programming style, control method, source language, database design and coding details.
White box Testing : Here inter functionality is considered Designer versus the Tester : Designing depends on a system’s structural details. The more you know
about the design, the likelier you are to eliminate useless tests.
Tester, test-team member or test designer contrast to the programmer and program designer. Testing includes unit testing to unit integration, component testing to component integration, system testing to system integration.
Modularity versus Efficiency : Both tests and systems can be modular. A module is a discrete, well defined small component of a system. The smaller the component, the easier is to understand but every component has interfaces with other components and all component interfaces are sources of confusion.
Smaller the component less the bugs.Large components reduce external interfaces but have complicated internal logic that may be difficult or impossible to understand.Testing can and should likewise be originated in to modular components, small, independent test cases have the virtue of easy repeatability.
Small versus Large : Programming in the large means constructing programs that consist of many components written by many different persons.Programming in the small is what we do for ourselves in the privacy of our own offices or as homework exercises in an undergraduate programming course.Qualitative changes occur with size and so must testing methods and quality criteria.
The Builder Versus the Buyer :
Just as programmers and testers can merge and become one, so can builder and buyer.
1. The builder, who designs for and is accountable to
2. The buyer, who pays for the system in the hope of profits from providing services to
software testing design
Test design : Design means documenting or modeling. In test design phase the given system is tested that bugs are present or not. If test design is not formally designed no one is sure whether there was a bug or not. So, test design is a important one to get the system without any bugs.
Testing isn’t everything
We must first review, inspect, read, do walkthroughs and then test.
The major methods in decreasing order of effectiveness as follows :
Inspection methods : It includes walkthroughs, desk checking, formal inspection and code reading.
These methods appear to be as effective as testing, but the bugs caught do not completely overload.
Design style : It includes testability, openness and clarity to prevent bugs.
Static Analysis Methods : It includes of strong typing and type checking. It eliminates an entire category of bugs.
Languages : The source language can help reduce certain kinds of bugs. Programmers find new kinds of bugs in new languages, so the bug rate seems to be independent of the languages used.
Design methodology and Development Environment : Design methodology can prevent many kinds of bugs. Development process used and the environment in which what methodology is embedded
Testing isn’t everything
We must first review, inspect, read, do walkthroughs and then test.
The major methods in decreasing order of effectiveness as follows :
Inspection methods : It includes walkthroughs, desk checking, formal inspection and code reading.
These methods appear to be as effective as testing, but the bugs caught do not completely overload.
Design style : It includes testability, openness and clarity to prevent bugs.
Static Analysis Methods : It includes of strong typing and type checking. It eliminates an entire category of bugs.
Languages : The source language can help reduce certain kinds of bugs. Programmers find new kinds of bugs in new languages, so the bug rate seems to be independent of the languages used.
Design methodology and Development Environment : Design methodology can prevent many kinds of bugs. Development process used and the environment in which what methodology is embedded
Phases in a Tester’s Life
Phase 0 : There’s no difference between testing and debugging. Here there is no effective testing, no quality assurance and no quality.\
Phase 1 : The purpose of testing is to show that the software works. Testing increases, software works decreases. There is a difference between testing and debugging. If testing fails the software doesn’t work.
Phase 2 : The purpose of testing is to show that the software doesn’t works. The test reveals a bug, the programmer corrects it, the test designer designs and executes another test intended to demonstrate another bug. It is never ending sequence.
Phase 3 : The purpose of testing is not to prove anything, but to reduce the perceived risk of not working to an acceptable value. Here testing implements the quality control. To the extent that testing catches bugs and to the extent that those bugs are fixed, testing does improve the product. If a test is
passed, then the product’s quality does not change, but our perception of that quality does.
Note : testing pass or fail reduces our perception of risk about a software product.
Phase 4 : Here what testing can do and not to do. The testability is that goal for two reasons :
1.Reduce the labor of testing.
2.Testable code has fewer bugs that code that’s hard to test.
Phase 1 : The purpose of testing is to show that the software works. Testing increases, software works decreases. There is a difference between testing and debugging. If testing fails the software doesn’t work.
Phase 2 : The purpose of testing is to show that the software doesn’t works. The test reveals a bug, the programmer corrects it, the test designer designs and executes another test intended to demonstrate another bug. It is never ending sequence.
Phase 3 : The purpose of testing is not to prove anything, but to reduce the perceived risk of not working to an acceptable value. Here testing implements the quality control. To the extent that testing catches bugs and to the extent that those bugs are fixed, testing does improve the product. If a test is
passed, then the product’s quality does not change, but our perception of that quality does.
Note : testing pass or fail reduces our perception of risk about a software product.
Phase 4 : Here what testing can do and not to do. The testability is that goal for two reasons :
1.Reduce the labor of testing.
2.Testable code has fewer bugs that code that’s hard to test.
Goals for Testing
Testing and test design as a parts of quality assurance, should also focus on bug prevention. To the extent that testing and test design do not prevent bugs, they should be able to discover symptoms caused by bugs. Bug prevention is testing first goal. Bug prevention is better than the detection and correction. There is no retesting and no time wastage. The act of testing, the act of designing tests is one of the bug preventions. Before coding test can be performed. “Test, then code”. Testing discover and eliminates bugs before coding.
Bug prevention – Primary goal
Bug discovery – Secondary goal
Bug prevention – Primary goal
Bug discovery – Secondary goal
Productivity and Quality in Software
Once in production, each and every stage is subjected to quality control and testing from component source inspection to final testing before shipping.If flaws are discovered at any stage, that part will be discarded or cycled back for rework and correction.The assembly line’s productivity is measured by the sum of the cost of the materials, the rework,discarded components and the cost of quality assurance and testing.
Productivity and Quality in Software
Once in production, each and every stage is subjected to quality control and testing from component
source inspection to final testing before shipping.If flaws are discovered at any stage, that part will be discarded or cycled back for rework and correction.The assembly line’s productivity is measured by the sum of the cost of the materials, the rework,discarded components and the cost of quality assurance and testing.
source inspection to final testing before shipping.If flaws are discovered at any stage, that part will be discarded or cycled back for rework and correction.The assembly line’s productivity is measured by the sum of the cost of the materials, the rework,discarded components and the cost of quality assurance and testing.
Subscribe to:
Posts (Atom)
