Testing

Ideal user

Background- Has the experience of user operations and in the use of IT facilities, independent thinker Skills- good communicator, need to expect system to fail Independence- not involved in the IT project and also in the user specifications, need to be a self-starter. Attitude- need to be an optimistic thinker, neutral, need to be analytical. Availability - Fully dedicated in doing the Tests

typical user

Background- Involved in the IT project and also in the user specifications Skills- Non technical and technical persons Attitude -Pragmatic Availability -Testing is not the main job

Grey Box Testing

Having knowledge of internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Tester is not required to have a full access to the software's source code. May also include reverse engineering to determine, for instance, boundary values or error messages

Issues of UAT Management

Insufficient number of testers Inexperienced user representative Incompetent Testers

Reasons why it is not possible to find Ideal User acceptance tester?

Lack of Software Project Management Knowledge Not always possible to have independent User Acceptance testers Generally, testing is not their main job Too busy with operational activities

Static Techniques list

Software inspection Software reviews Code reading Algorithm analysis and tracing

UAT Methodologies

Structured testing: 1)Conducted based on the test plan and test procedures. 2)It consists various tests against agreed requirements. Unstructured testing: 1) A test that is conducted by not referring to the test plan 2) It is a free form test which tests the software with the idea of breaking it.

UAT Team Members

Team Leader Test Analyst User Representative Testers Test Observers

UAT Deliverables

Test plan: Outlines the testing strategy (Acceptance Testing, Entry and Fail Criteria, Test Execution Team, Test Script Developer) Test cases: Guide the team to effectively test the application Test Log: Records all the test cases executed and the actual results User Sign Off: Indicates that the customer are satisfied with the product.

Testing - Granularity Levels

Unit testing: checking the behavior of single modules Integration testing: checking the behavior of module cooperation. Regression testing: to check the behavior of new versions/releases System testing: the software behavior is compared with the requirements specifications Acceptance testing: the software behavior is compared with end user requirements

UAT Activities

User Acceptance Test Planning Designing UAT Test Cases Review/Approve Acceptance Test Plan Executing Test Cases Documenting the defects found during UAT Resolving the Defects Fixing Sign Off

Smoke Testing

- A common approach for creating "daily builds" for product software - Software components that have been translated into code are integrated into a "build." - A series of tests is designed to expose errors that will keep the build from properly performing its function - The build is integrated with other builds and the entire product (in its current form) is smoke tested daily

Validation Testing

- Determine if the software meets all of the requirements defined in the software requirements specification (SRS)

Bottom-Up Integration

- Integration begins with the lowest-level modules, which are combined into clusters, or builds, that perform a specific software subfunction - Drivers (control programs developed as stubs) are written to coordinate test case input and output - The cluster is tested - Drivers are removed and clusters are combined moving upward in the program structure - problems : whole program does not exist until the last module is integrated AND Timing and resource contention problems are not found until late in the process

Regression testing

- Objective : Retest changed components (or parts) - done by developers, test engineers and users - problems : maintaining test suite & cost of re-testing

System Integration Testing

- Objective: To test the co-existence of products and applications that are required to perform together in the production-like operational environment - done by system testers

Unit testing

- Tests done on particular functions or code modules. - objective:To test the function of a program or unit of code such as a program or module - Done by Programmers

Top-Down Integration

- The main control module is used as a driver, and stubs are substituted for all modules directly subordinate to the main module - Tests are run as each individual module is integrated - problems : calculations are performed in the modules at the bottom of the hierarchy

The Use of UAT

- it is performed after the software has successfully completed systems testing - A formal UAT is not compulsory

Integration testing

-To technically verify proper interfacing between modules, and within sub-systems - done by developers

Alpha and Beta Testing

-provides the customer an outline of the things that you would like them to focus on and specific test scenarios for them to execute.

Principles of Testing

1. Testing shows the presence of defects, but if no defects are found that is not proof of correctness. 2. Exhaustive Testing is impossible 3. Early Testing is important 4. Defect Clustering 5. Pesticide Paradox 6. Testing is Context Dependent 7. Absence-of-Errors fallacy

Acceptance Testing Definition

A final testing phase that is conducted during the life cycle of software development, in order to determine whether the developed system meets the agreed requirements and to evaluate the readiness for operational use

Static Techniques

Heavily manual, error-prone, time consuming

Obsolete and Redundant

Obsolete: A test case that is not longer valid Redundant: A test case that does not differ significantly from others

Test Process

Planning and Control, Analysis and Design, Implementation and Execution, Evaluating Exit Criteria and Reporting, Evaluating Exit Criteria and Reporting and Test Closure Activities

White Box Testing

Tester has access to the internal data structures and algorithms including the code that implement these. Methods include: API testing, Code coverage, Fault injection methods, Mutation testing methods and Static testing

Dynamic Techniques list

Testing and Profiling

Software Testing definition

Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user

Black Box Testing

Treats the software as a "black box"—without any knowledge of internal implementation. Methods include: fuzz testing and model-based testing

Box Approach

black, white and grey box

Types of User Acceptance Tester

ideal and typical

Black Box Testing info

input determined by: - requirements result: Actual output compared with required output

White Box Testing info

input determined by: design elements result: Confirmation of expected behavior

Grey Box Testing info

input determined by: requirements & key design elements result: As for black and white box testing

Software Testing objective

to find errors. Can detect the presence of defects, but not their absence