CAPITULO II: CARACTERÍSTICAS DEL SISTEMA
2.12 Descripción de los Casos de uso expandida
· Grey box Testing is the new term, which evolved due to the different architectural usage of the system. This is just a combination of both Black box & White box testing. Tester should have the knowledge of both the internals and externals of the function.
· Tester should have good knowledge of White Box Testing and complete knowledge of Black Box Testing.
· Grey box testing is especially important with Web and Internet applications, because the Internet is built around loosely integrated components that connect via relatively well-defined interfaces
6. Difference Tables
Testing is an activity done to achieve the quality.
6.2.Testing Vs Debugging
Testing Debugging
Testing is done to find bugs Debugging is an art of fixing bugs.
6.3.Quality Assurance Vs Quality Control
Quality Analysis Quality Control
Study on Process followed in Project
development Study on Project for its Function and
Specification QA is a planned and systematic set of
activities necessary to provide adequate confidence that requirements are properly established and products or services conform to specified requirements.
QC is a process by which product quality is compared with applicable standards, and the action taken when nonconformance is detected.
It is an activity that establishes and evaluates the processes to produce the products by preventing the introduction of issues or defects.
It is an activity, which verifies if the product meets pre-defined standards.
QA improves the processes that are applied to multiple products that will ever be produced by a process.
· help establish processes.
· Sets up measurements programs to evaluate processes.
· Identifies weaknesses in processes and improves them.
Qc improves the development of a specific product or service by identifying the defects, reporting them and correcting the defects
It is performed during development on key artifacts, like walkthroughs, reviews and inspections, mentor feedback, training, checklists and standards.
It is performed after a work product is produced against established criteria ensuring that the product integrates correctly into the
environment.
QA is the determination of correctness of the final software product by a development project with respect to the user needs and requirements and the responsibility of the entire team
Qc is a demonstration of consistency,
completeness, and correctness of the software at each stage and between each stage of the development life cycle and the responsibility of the tester.
6.4.Verification & Validation
Verification Validation
Process of determining whether output of one phase of development conforms to its
containment of errors Validation is concerned about the final product to be error free
6.5.Black Box Testing & White Box Testing
Black Box / Functional White Box / Structural
Test case selection that is based on an analysis of the specification of the component without reference to its internal workings
Test case selection that is based on an analysis of the internal structure of the component.
It focuses on global issues of workflows,
configuration, performance, and so forth It is based on how the system is built It attempts to find errors in the external
behavior of the code in the following categories:
- incorrect or missing functionality - interface errors;
- errors in data structures used by interfaces
- behavior or performance errors - initialization and termination errors.
It applied to individual components and interfaces, being particularly effective at discovering localized errors in control and data flows
It involves insightful test planning, careful
design, and meticulous result checking It involves the creation of custom test data. And we can reuse such test data for other kinds of tests
Skilled manual tester know how to follow a trail of bugs, A good manual tester also applies on the spot judgment to observed results that an automated tool can’t
No matter who does the structural testing, they will need to understand some fundamental test design techniques to do a good job.
6.6.IST & UAT
Particulars IST UAT
Base line document Functional Specification Business Requirement
Data Simulated Live Data
Environment Controlled Simulated Live
Orientation Component Business
Tester composition Testing Firm Testing Firm / users
Purpose Verification Validation
6.7.SIT & IST
SIT IST
SIT can be done when system is on the
process of integration IST need integrated System of various Unit levels of independent functionality and checks its workability after integration and compares it before integration.
6.8. Alpha Testing & Beta Testing
Component Alpha testing Beta testing
Test data Simulated Live
Test Environment Controlled Uncontrolled
To Achieve Functionality User needs
Tested by Only testers Testers and End-Users
Supporting Document Used
Functional Specification Customer Requirement Specification
6.9.Test Bed and Test Environment
Test Bed Test Environment
Test bed holds only testing documents which supports testing which includes Test data, Data guidelines etc.
Test environment includes all supportive elements namely hardware, software, tools, Browsers, Servers, etc.
6.10.Re-testing and Regression Testing
Re-testing Regression Testing
To check for a particular bug and its dependencies after it is said to be fixed.
To check for the added or new
functionality's effect on the existing system
7. Levels of Testing
7.1.Unit Testing“The testing of individual software components.”
… BS795-1
· Individual testing of separate units - methods and classes.
· Write many short tests (in code) that span the extents of the requirements for the module you wish to test.
· Write tests before you write the code. You are done coding once your code can pass all the tests.
7.1.1.Benefits of Unit Testing
· Assurance of working components before integration
· Tests are repeatable - Every time you change something you can rerun your suite of tests to verify that the unit still works.
· Tests can be designed to ensure that the code fulfills the requirements.
· All debugging is separated from the code.
7.1.2.Pre-requisites
Before component testing may begin the component test strategy (2.1.1) and project component test plan (2.1.2) shall be specified.
Component test strategy
The component test strategy shall specify the techniques to be employed in the design of test cases and the rationale for their choice. Selection of techniques shall be according to clause 3. If techniques not described explicitly in this clause are used they shall comply with the 'Other Testing Techniques' clause (3.13).
The component test strategy shall specify criteria for test completion and the rationale for their choice. These test completion criteria should be test coverage levels whose measurement shall be achieved by using the test measurement techniques defined in clause 4. If measures not described explicitly in this clause are used they shall comply with the 'Other Test Measurement Techniques' clause (4.13).
The component test strategy shall document the degree of independence required of personnel designing test cases from the design process, such as:
a) the test cases are designed by the person(s) who writes the component under test;
b) the test cases are designed by another person(s);
c) the test cases are designed by a person(s) from a different section;
d) the test cases are designed by a person(s) from a different organisation;
e) the test cases are not chosen by a person.
The component test strategy shall document whether the component testing is carried out using isolation, bottom-up or top-down approaches, or some mixture of these.
The component test strategy shall document the environment in which component tests will be executed. This shall include a description of the hardware and software environment in which all component tests will be run.
The component test strategy shall document the test process that shall be used for component testing.
The test process documentation shall define the testing activities to be performed and the inputs and outputs of each activity.
Standard for Software Component Testing
6 Working Draft 3.4 (27-Apr-01) © British Computer Society, SIGIST, 2001
For any given test case, the test process documentation shall require that the following activities occur in the following sequence:
a) Component Test Planning;
b) Component Test Specification;
c) Component Test Execution;
d) Component Test Recording;
e) Checking for Component Test Completion.
This Figure illustrates the generic test process described in clause 2.1.1.8. Component Test Planning shall begin the test process and Checking for Component Test Completion shall end it;
these activities are carried out for the whole component. Component Test Specification, Component Test Execution, and Component Test Recording may however, on any one iteration, be carried out for a subset of the test cases associated with a component. Later activities for one test case may occur before earlier activities for another. Whenever an error is corrected by making a change or changes to test materials or the component under test, the affected activities shall be repeated.
7.2.Integration Testing
“Testing performed to expose faults in the interfaces and in the interaction between integrated components”
… BS7925-1 Testing of combined parts of an application to determine they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network etc. This type of testing is especially relevant to client/server and distributed systems.
Objective:
The typical objectives of software integration testing are to:
· Cause failures involving the interactions of the integrated software components when running on a single platform.
· Report these failures to the software development team so that the underlying defects can be identified and fixed.
· Help the software development team to stabilize the software so that it can be successfully distributed prior to system testing.
· Minimize the number of low-level defects that will prevent effective system and launch testing.
Entry criteria:
·
The integration team is adequately staffed and trained in software integration testing.·
The integration environment is ready.· The first two software components have:
o
Passed unit testing.o Been ported to the integration environment.
o Been integrated.
· Documented Evidence that component has successfully completed unit test.
· Adequate program or component documentation is available
· Verification that the correct version of the unit has been turned over for integration.
Exit criteria:
· A test suite of test cases exists for each interface between software components.
· All software integration test suites successfully execute (i.e., the tests completely execute and the actual test results match the expected test results).
· Successful execution of the integration test plan
· No open severity 1 or 2 defects
· Component stability
Guidelines:
· The iterative and incremental development cycle implies that software integration testing is regularly performed in an iterative and incremental manner.
· Software integration testing must be automated if adequate regression testing is to occur.
· Software integration testing can elicit failures produced by defects that are difficult to detect during system or launch testing once the system has been completely integrated.
7.2.1.Incremental Integration Testing
“Integration testing where system components are integrated into the system one at a time until the entire system is integrated”
… BS795-1 Continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers. Integration testing where system components are integrated into the system one at a time until the entire system is integrated.
7.2.1.1.Top Down Integration
“An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components has been tested.”
… BS795-1
· Modules integrated by moving down the program design hierarchy.
· Can use depth first or breadth first top down integration.
Steps:
· Main control module used as the test driver, with stubs for all subordinate modules.
· Replace stubs either depth first or breadth first
· Replace stubs one at a time.
· Test after each module integrated
· Use regression testing (conducting all or some of the previous tests) to ensure new errors are not introduced.
· Verifies major control and decision points early in design process.
Level 2 Level 2
Level 2 Level 2
Level 1 Testing Level 1
sequence
Level 2 stubs
Level 3 stubs
. . .
7.2.1.2.Bottom up Integration
“An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.”
…BS7925-1
· Begin construction and testing with atomic modules (lowest level modules).
· Use driver program to test.
Steps:
· Low level modules combined in clusters (builds) that perform specific software sub-functions.
· Driver program developed to test. Cluster is tested.
· Driver programs removed and clusters combined, moving upwards in program structure.
Bottom-up Top-down
Major
Features · Allows early testing aimed t proving feasibility and practicality of particular modules.
· Modules can be integrated in various clusters as desired.
· Major emphasis is on module functionality and performance.
· The control program is tested first
· Modules are integrated one at a time
· Major emphasis is on interface testing
Advantages · No test stubs are needed
· It is easier to adjust manpower needs
· Errors in critical modules are found early
· No test drivers are needed
· The control program plus a few modules forms a basic early prototype
· Interface errors are discovered early
· Modular features aid debugging Disadvantages · Test drivers are needed
· Many modules must be integrated before a working program is available
· Interface errors are discovered late
· Test stubs are needed
· The extended early phases dictate a slow manpower buildup
· Errors in critical modules at low levels are found late
Comments At any given point, more code has been written and tested that with top down testing. Some people feel that bottom-up is a more intuitive test philosophy.
An early working program raises morale and helps convince management progress is being made. It is hard to maintain a pure top-down strategy in practice.
7.2.1.3.Stub and Drivers 5.2.1.3.1 Stubs:
Stubs are program units that are stand-ins² for the other (more complex) program units that are directly referenced by the unit being tested.
Stubs are usually expected to provide the following:
An interface that is identical to the interface that will be provided by the actual program unit, and the minimum acceptable behavior expected of the actual program unit. (This can be as simple as a return statement)
5.2.1.3.2 Drivers:
Drivers are programs or tools that allow a tester to exercise/examine in a controlling manner the unit of software being tested.
A driver is usually expected to provide the following:
A means of defining, declaring, or otherwise creating, any variables, constants, or other items needed in the testing of the unit, and a means of monitoring the states of these items, any input and output mechanisms needed in the testing of the unit
Sandwich Testing: Combines bottom-up and top-down testing using testing layer.
7.2.2.Non-Incremental Testing 7.2.2.1.Big Bang Integration
“Integration testing where no incremental testing takes place prior to all the system's components being combined to form the system.”
… BS7925-1 7.2.2.2.Validation Testing
Validation testing aims to demonstrate that the software functions in a manner that can be reasonably expected by the customer.
Tests conformance of the software to the Software Requirements Specification. This should contain a section “Validation criteria” which is used to develop the validation tests.
Validation test criteria
· A set of black box tests to demonstrate conformance with requirements.
· To check that: all functional requirements satisfied, all performance requirements achieved, documentation is correct and 'human-engineered', and other
requirements are met (e.g., compatibility, error recovery, maintainability).
· When validation tests fail it may be too late to correct the error prior to scheduled delivery. Need to negotiate a method of resolving deficiencies with the customer.
7.2.2.3.Configuration review
An audit to ensure that all elements of the software configuration are properly developed, catalogued, and has necessary detail to support maintenance.
7.3.System Testing
“System testing is the process of testing an integrated system to verify that it meets specified requirements".
… BS7925-1 It is further sub-divided into
· Functional system testing
· Non-Functional system testing System test Entrance Criteria:
· Successful execution of the Integration test cases
· No open severity 1 or 2 defects
· 75-80% of total system functionality and 90% of major functionality delivered
· System stability for 48-72 hours to start test
System Test Exit Criteria:
· Successful execution of the system test cases ,and documentation that shows coverage of requirements and high-risk system components
· System meets pre-defined quality goals
· 100% of total system functionality delivered
7.3.1.Functional Testing
7.3.1.1.Requirement based Testing
“Designing tests based on objectives derived from requirements for the software component (e.g., tests that exercise specific functions or probe the non-functional constraints such as performance or security)”
… BS7925-1 Requirements testing must verify that the system can perform its function correctly and that the correctness can be sustained over a continuous period of time. Unless the system can function correctly over an extended period of time management will not be able to rely upon the system. The system can be tested for correctness throughout the lifecycle, but it is difficult to test the reliability until the program becomes operational.
Objectives:
Successfully implementing user requirements is only one aspect of requirements testing.
The responsible user is normally only one of many groups having an interest in the application system. The objectives that need to be addressed in requirements testing are:
· User requirements are implemented
· Correctness is maintained over extended processing periods.
· Application processing complies with the organization’s policies and procedures.
When to use Requirements Testing:
Every application should be requirements tested. The process should begin in the
requirements phase, and continue through every phase of the life cycle into operations
and maintenance. It is not a question as to whether requirements must be tested but,
rather, the extent and methods used in requirements testing.
7.3.2.Business-Process based Non-Functional Testing
Testing of those requirements that do not relate to functionality. I.e. performance, usability, etc. “
…BS7925-1
Non-Functional testing types:7.3.2.1.Recovery testing
“Testing aimed at verifying the system's ability to recover from varying degrees of failure.”
,,, BS7925-1 Recovery is the ability to restart operations after the integrity of the application has been lost. The process normally involves reverting to a point where the integrity of the system is known, and then reprocessing transactions up until the point of failure. The importance of recovery will vary from application to application.
Objectives:
Recovery testing is used to ensure that operations can be continued after a disaster, recovery testing not only verifies the recovery process, but also the effectiveness of the component parts of that process. Specific objectives of recovery testing include:
· Adequate backup data is preserved
· Backup data is stored in a secure location
· Recovery procedure are documented
· Recovery personnel have been assigned and trained
· Recovery tools have been developed and are available
When to use Recovery Testing:
Recovery testing should be performed whenever the user of the application states that the continuity of operation of the application is essential to the proper functioning of the user area.
The user should estimate the potential loss associated with inability to recover operations over
The user should estimate the potential loss associated with inability to recover operations over