Requirement Implementation UAT

Testing Life Cycle
Specification IST


Unit Testing


Objective of Testing
 Primary role of testing is not demonstration of correct performance but the exposure of hidden defects  Testing is executing a program with an intend of finding Fault/Error and Failure.  Error: Human Action that produces an in correct result.  Fault: Manifestation of an error in software. (also called defect or Bug)

 Failure: Deviation of the software from its expected delivery or service.

Why Software Testing?
•To discover defects. •To avoid user-detecting problems. •To prove that the software has no faults. •To learn about the reliability of the software. •To ensure that product works as user expected. •To stay in business. •To avoid being sued by customers. •To detect defects early, which helps in reducing the cost of defect fixing.

What are we testing for?
Discovering defects from what is expected There are two types of defects – 1] Variance from Specifications. 2] Variance from what is desired. Why do we need an approach for testing? Yes, We definitely need an approach for testing. To over come the following problems, we need a formal approach for Testing. •Incomplete functional coverage •No risk management •Too little emphasis on user tasks •Inefficient over the long term

What is Quality?
Here are some of the traditional definitions: –Fitness for use (Dr. Joseph M. Juran) –The totality of features and characteristics of a product that bear on its ability to satisfy a given need (ASQ)

–Conformance with requirements (Philip Cosby) –The total composite product and service characteristics of marketing, engineering, manufacturing and maintenance through which the product and service in use will meet expectations of the customer (Armand V. Feigenbaum)

Quality Assurance
It is a planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. A Set of activities designed to evaluate the process by which products are developed or manufactured.

Quality Control
Set activities designed to evaluate the quality of developed or manufactured products. It is the process which product compares quality with applicable standard.

It is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.

It is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.

It is the process of evaluating a system or component based on its form, structure, content or documentation without computer program execution.

Static Testing

Requirement & Function

It is a statement of what the data and Software should perform. Function It is a desirable behavior of a requirement.

Test Baselines
Business Requirement Document Functional Specification Document Design Specification Documents Gap Analysis Document

2 Areas of Testing • • Black box Testing White box Testing

Black box Testing
Black box testing is also called as Functionality Testing. In this testing Tester will be asked to test the correctness of the functionality with the help of Inputs and Outputs. Tester doesn’t require the knowledge of software code. Approach: •Equivalence Class •Boundary Value Analysis •Error Guessing

Equivalence Class:
• For each piece of the specification, generate one or more equivalence Class. • Label the classes as “Valid” or “Invalid”. • Generate one test case for each Invalid Equivalence class.

• Generate a test cases that Covers as many as for Equivalence class.

Boundary Value Analysis:
• Generate test cases for the boundary values.
• Minimum Value, Minimum Value + 1, Minimum Value -1 • Maximum Value, Maximum Value + 1, Maximum Value – 1

Error Guessing:
Generate Test cases against to the specification.

White box Testing
White box testing is also called as Structural testing. Tester does require the knowledge of software code. Structure = 1 Entry + 1 Exit with certain Constraints, Conditions and Loops . Why do we go for white box testing when black box testing is used to find defects? • Logic Errors and incorrect assumptions are most likely to be made while coding for “special cases”. Need to ensure these execution paths are tested. • May find assumptions about execution paths incorrect, and so make design errors. • Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.

Approach Basic Path testing: Cyclomatic Complexity. Mc Cabe Complexity. Structure Testing: Conditions Testing.

Data Flow Testing.
Loop testing.

4 • • • •

Phases of Testing – The V Model Unit Test Integration Test System Test Acceptance Test


What is Unit Testing
Unit testing involves testing the smallest software Unit of block of code. A Software Unit can be collection of code segment that make up a modular or a function .It can be a Screen of a GUI application.

Integration Testing:
The primary objective of integration testing is to discover errors in the interfaces between Modules / Sub-Systems. Approach: Top-Down Approach.

Bottom-Up Approach. System Testing: The primary objective of system testing is to discover errors when the system is tested as a whole. System testing is also called as End-To-End Testing. Tester is expected to test from Login-To-Logout by covering various business functionalities. Approach: IDO Model Identifying the End-To-End / Business Life Cycles. Design the test and data. Optimize the End-End / Business Life Cycles.

What is UAT?
 User Acceptance testing involves having the end users test how the software performs in their every day business processes.  The explanation of UAT is actually in its name.  Taking each part separately explains what it is about. USER ACCEPTANCE TESTING

What is USER?
Users means the real business users, who will have to operate the system; normally the staff of an organization. They are the only people who understand exactly what the business is, and how it operates. Therefore they are the only people qualified to check a system to see if it will deliver any benefit to the business or organization.

 The acceptance of a system means you are confident it will give benefit to the organization.

 It does not mean that it only meets the original specification as requested.  The point is that a system may not be acceptable, even if it meets specification.  You may still have to pay the supplier, but you will not incur any costs to implement it.

What is TESTING?
 Whenever people are asked what testing is, many of them say it is to prove the system works.  This is the key problem with the way UAT is employed in many organizations, as it is impossible to prove any system is correct.  All you can prove is, if a system is wrong. Therefore a good test is one that is designed to try and make a system fail, so as to expose its faults before it goes live.

Test Condition
 A Test Condition is derived from a requirement or specification.  It includes all possible combinations and validations that can be attributed to that requirement/specification.

Test Case
 A Test Case gives values / qualifiers to the attributes that the test condition can have. Test cases, typically, are dependant on data / standards.  A Test Case is the end state of a test condition, i.e., it cannot be decomposed or broken down further.  Test case is a description of what to be tested, what data to be given and what actions to be done to check the actual result against the expected result.

What are the items of test case?
Test case items are: • Test Case Number • Pre-Condition • Description • Expected Result • Actual Result • Status (Pass/Fail) • Remarks. What are the characteristics of good test case? A • • • • good test case should have the following: TC should start with “what you are testing”. TC should be independent. TC should not contain “If” statements. TC should be uniform. E.g.. <Action Buttons>, “Links”…

Test Script
A Test Script contains the Navigation Steps, Instructions, Data and Expected Results required to execute the test case(s).

Type of Testing
GUI Testing Functional Testing Backend Testing Regression Testing Performance Testing Interface Testing

Why Do User Acceptance Testing?

 The short answer is to protect the organization from harm. Any changes in a business, and especially installing new computer systems, expose it to many risks  Therefore the main reason for UAT is to find out what a system will do to your organization before you implement it.  Then make the decision based on the evidence presented by the testing.

Difference between IST & UAT

Particulars Baseline Document Data Environment Perspective Location Tester Composition Purpose

IST Functional Specification Simulated Controlled Functionality Off Site Tester Company Validation & Verification

UAT Business Requirement Live Data Simulated Live User Style On Site Test Company & Real Users

User Need

Load Testing

 Testing a system by increasing the load i.e., by creating many virtual users. The response time will be calculated.  The creation of a simulated "load" on a real computer system by using virtual users who submit work as real users would do at real client workstations and thus "testing" the system's ability to support such a workload. The virtual users are in software running on a "driver machine" or "injector".

Stress Testing
Testing a system by varying the resources, i.e., by reducing memory, or by increasing the duration and calculating the response time and see at point exactly the system breaks down.

Regression Testing
“Regression Testing is the process of testing the changes to computer programs to make sure that the older programs still work with the new changes.” “When making improvements on software, retesting previously tested functions to make sure adding new features has not introduced new problems.”

Seven Steps Test Methodology
Key Task –1 : Risk Analysis
Risk’s associated with projects are analyzed and mitigation’s are documented. Types of risk that are associated are – –Schedule Risk: Factors that may affect the schedule of testing are discussed. –Technology Risk: Risks on the hardware and software of the application are discussed here –Resource Risk: Test team availability on slippage of the project schedule is discussed. –Support Risk: Clarifications required on the specification and availability of personnel for the same is discussed.

Key Task –2:Test Planning
     Kick of meeting Developing Test Strategy Assigning Responsibilities Application Understanding Internal Presentation

Test Strategy
Indicates HOW testing is to be carried out Indicates WHERE to emphasize so that best possible use of resource and time can be made. Makes testing process manageable by providing structured approach. Addresses most of the risk and different types of test.

   

Key Task –3 : Test Design
•Test Condition •Test Case

•Test Script •Data Guidelines •Activity Schedule •Trace ability Matrix

Key Task – 4 : Test Execution
–Set up system test environment.
–Establish test data bed. –Identify test cases. –Identify test cycles –Performing necessary activities to execute testing accordance with the test plan and test design. –Analyze test run results –Logging test activities –Documenting defects including supporting evidence.


Key Task – 5: Defect Tracking & Management

Defect Recording •Defect recording to describe and quantify deviations from requirements. Defect Reporting– •Reporting the status of Defects including Severity and location. • Defect Tracking – •Monitoring Defects from the time of recording until satisfactory resolution has been determined

Defect Recording
Defects are recorded for following purposes •To correct defect. •To report status of the application •To gather statistics used to develop defect expectations in future application. •To improve the software development process.

Defect Status
Defect Status •Raised When defect is found, it will be in raised status. •Authorized When Client authorizes as a defect then the status Will change as authorized. •Fixed When developer fixes the defect, then the status Will change as fixed •Deferred If Client takes the call and defer it for next release, Then it is Deferred Status. •Re-raised If defect reappears in re test, then it is re-raised Status.

Defect Severity

The impact of this defect is severe and the system cannot go to Production Environment or for User Acceptance Testing without resolving the defect.

• Major
The Impact of this defect is severe, however an interim solution is available. The defect neither should nor hinder the test process.

All defects that are not in the ‘X’ or ‘C’ Category.

Key Task – 6 : Quantitative Measurement
 Metrics specific to testing include data collected during testing, defect tracking

Test Metrics
The following measurements generated during testing – –Total no of tests –Number of tests executed to date –Total number of defects corrected in each activity –Total number of defects detected in each activity –Average duration between defect detection and defect correction –Total number of defects remaining at delivery

Defect Metrics
Defects per thousand lines of Code Defects Resolution [Closed, Deferred, Raised, Open] Root Cause Analysis. Defect Distribution by Severity. Defect distribution by Defect Type.

Key Task – 7: Test Closure
•Executive Summary •Test Overview •Trace ability Matrix •Test Execution Summary •Features not tested •Defect Summary •Defect Matrix •Defect Analysis

Trace ability Matrix to be maintained
Throughout the testing life cycle of the project trace ability matrix has been maintained to ensure the verification and validation of the testing is complete.

Example of Trace ability Matrix

Your role
Understanding the Application Preparation of Clarification Document Internal Presentation Identify Scope of work Estimate the number of Functional points, screens, fields etc. Derive Test Condition Derive Test Case Preparation of Test Data Derive Test Script Prepare Defect Log Maintain Defect Log Report Defects