Manual Testing Concepts Instructor: Surender

Agenda  Content: 1. Testing Overview I. What is testing II. Who does testing III. When to Start Testing and When to Stop Testing IV. Difference between Verification & Validation V. Difference between Testing, Quality Assurance and Quality Control VI. Difference between Audit and Inspection VII. Difference between Testing and Debugging VIII. Testing Myths

AGENDA CONTINUED…  Content: 1. Testing Overview I. What is testing II. Who does testing III. When to Start Testing and When to Stop Testing IV. Difference between Verification & Validation V. Difference between Testing, Quality Assurance and Quality Control VI. Difference between Audit and Inspection VII. Difference between Testing and Debugging VIII. Testing Myths

AGENDA CONTINUED… 1. Testing Types I. Manual Testing II. Automation Testing

AGENDA CONTINUED… 1. Testing Methods I. Black Box Testing II. White Box Testing III. Grey Box Testing

AGENDA CONTINUED… 1. Levels of Testing I. Functional Testing II. Non-Functional Testing

AGENDA CONTINUED…  Content: 1. Testing Documentation I. Testing strategy II. Test Plan III. Test Scenario & Test Case IV. Traceability Matrix 2. Software Development Life Cycle (SDLC) 3. Software Testing Life Cycle (STLC) 4. Defect Life Cycle 5. Test Metrics / Reports

Testing Overview  What is Testing…?  Testing is the process of evaluating a system or its component(s) with the intent to find that whether it satisfies the specified requirements or not  Testing is executing a system in order to identify any gaps, errors or missing requirements in conflicting to the actual requirements

Testing Overview  Who does Testing…?  Software Tester  Software Developer  Project Lead/Manager  End User

Testing Overview  When to start Testing  Analysis  Design  Coding  Testing  Deployment

Testing Overview  When to stop Testing  Completion of test case execution.  Completion of Functional and code coverage to a certain point.  Bug rate falls below a certain level and no high priority bugs are identified.  Management decision.

Difference between Verification & Validation

Difference between Quality Assurance, Quality Control and Testing

Difference between Audit and Inspection  Audit  A systematic process to determine how the actual testing process is conducted within an organization or a team.  It is an independent examination of processes which are involved during the testing of software  Inspection  A formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group other than the author to detect faults, violations of development standards, and other problems.  Formal Inspection meetings may have following process: Planning, Overview Preparation, Inspection Meeting, Rework, and Follow-up.

Difference between Testing and Debugging  Testing  It involves the identification of bug/error/defect in the software without correcting it..  Normally professionals with a Quality Assurance background are involved in the identification of bugs.  Testing is performed in the testing phase  Debugging  It involves identifying, isolating and fixing the problems/bug..  Developers who code the software conduct debugging upon encountering an error in the code.  Debugging is the part of White box or Unit Testing.  Debugging can be performed in the development phase while conducting Unit Testing or in phases while fixing the reported bugs.

Testing Myths…..!!  Testing is too expensive.  Testing is time consuming.  Testing cannot be started if the product is not fully developed  Complete Testing is Possible..  If the software is tested then it must be bug free.  Missed defects are due to Testers.  Testers should be responsible for the quality of a product.  Test Automation should be used wherever it is possible to use it and to reduce time.  Any one can test a Software application  A tester’s task is only to find bugs

Testing Types  Manual Testing  Testing of the Software manually i.e. without using any automated tool or any script.  Different stages for manual testing like unit testing, Integration testing, System testing and User Acceptance testing.  Testers use test plan, test cases or test scenarios to test the Software to ensure the completeness of testing.  Automation Testing  Tester writes scripts and uses another software to test the software.  This process involves automation Test Automation of a manual process.  Automation Testing is used to re-run the test scenarios that were performed manually, quickly and repeatedly..  Increases the test coverage; improve accuracy, saves time and money in comparison to manual testing.

Testing Methods  Black Box Testing  A tester will interact with the system’s user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.  Focuses on functional requirement of the software  White Box Testing  White box testing is the detailed investigation of internal logic and structure of the code.  Also called glass testing or open box testing.  The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving inappropriately  Grey Box Testing  Its a technique to test the application with limited knowledge of the internal workings of an application. In software testing  "The more you know the better” carries a lot of weight when testing an application.

Comparison between the Three Testing Types

Levels of Testing  Functional Testing  Unit Testing.  Integration Testing I.Bottom-Up Integration II.Top-Down Integration  System Testing  System Integration Testing  Regression Testing  Acceptance Testing I.Alpha Testing II.Beta Testing  Non-Functional Testing  Performance Testing I.Load Testing II.Stress Testing  Usability Testing  Security Testing  Portability Testing

Testing Documents  Testing Strategy  Test Plan  Test Scenario  Test Case  Traceability Matrix

Testing Documents - Testing Strategy  Test strategy is statement of overall approach of testing to meet the business and test objectives  It is a plan level document and has to be prepared in the requirement stage of the project.  It identifies the methods, techniques and tools to be used for testing  Components of the Test Strategy document: I.Scope, Objectives and critical success factors II.Overall testing approach, Management and other business initiative III.Test Environment IV.Test Automation requirements V.Testing measurements and metrics VI.Defect reporting and tracking VII.Project Policies VIII.Risk Identification, Mitigation and Contingency plan IX.Test deliverability X.Specific Document templates used in testing XI.Change and configuration management XII.Training plan

Testing Documents - Test Plan  Test Plan is derived from the Product Description, Software Requirement Specification SRS, or Use Case Documents.  Focus of the document is to describe what to test, how to test, when to test and who will do what test.  The Test Plan document is usually prepared by the Test Lead or Test Manager  Components of the Test Plan document: I.Scope : Features to be Tested and features not to be tested II.Test Approach Test Case identification/creation/modifications Test Data Preparation Test Environment Entrance and Exit Criteria Test Complete and Validations Test Reporting III.Testing Objectives and Goals IV.Test Phases : Functional, Regression, Integration and Business Acceptance Testing V.Test Environment VI.Test Schedules VII.Resource Requirements VIII.Roles & Responsibilities IX.Project Impact Analysis : Risks, Assumptions and Constraints X.Test Management and Reporting XI.Defect Life Cycle XII.Test Execution Criteria : Suspension, Resumption and Approval Criteria XIII.Test Deliverables.

Testing Documents - Test Scenario  Test scenarios are the high level classification of test requirement grouped depending on the functionality of a module  Test Scenario represents a series of actions that are associated together.  A test scenario may have one or more test cases associated to it

Testing Documents - Test Case  Test cases are the set of valid and invalid executable procedure of a test scenario.  A test case with valid functionality is called positive test case  A test case with invalid functionality is called negative test case.  Test scenario ensures that all business flow has been covered and tested end to end while Test case ensure that a single step has been covered well  Typical Test Case format I.Test Case ID II.Prerequisite(Test Data) III.Test case Description IV.Expected Result V.Actual Result VI.Pass/Fail VII.Comments

Testing Documents - Traceability Matrix  Testing Requirements Traceability Matrix is a document that traces and maps user requirements, usually requirement IDs from a requirement specification document, with the test case IDs.  Purpose of this document is to make sure that all the requirements are covered in test cases so that nothing is missed  Types of Traceability Matrices I.Forward Traceability: Mapping of Requirements to Test Cases. II.Backward Traceability: Mapping of Test Cases to Requirements. III.Bi-Directional Traceability: Contains both Forward and Backward Traceability  Basic Traceability Matrix format:

Software Development Life Cycle (SDLC)  It is a framework defining tasks performed at each step in the software development process.  SDLC consists of following activities:  Requirements Phase.  Analysis Phase  Design Phase  Coding/Development Phase  Testing Phase  Deployment Phase  Maintenance Phase

Software Development Life Cycle (SDLC) - Models  Waterfall Model  V-Life Cycle Model  Iterative Model (Spiral Model)  Agile Methodology

Software Testing Life Cycle (STLC)

Defect Life Cycle

Test Metrics / Reports  Why are test metrics important? You cannot improve what you cannot measure.” “You cannot control what you cannot measure” Which areas have the most defects? How long does it take to repair defects? Which areas have the highest re-work rates? Over All testing progress  Metrics can be defined as “STANDARDS OF MEASUREMENT”.  Sample Metrics I.Overall Test Execution Percentage II.No. of Test Cases executed per Day III.No. of Defects reported IV.Defect Discovery Rate Defects Found / Man Days in Effort V.Actual Testing progress against plan : No. of Test cases done / No. planned Test cases VI.No. of Defects found during testing VII.Defect Density Report: No. of Defects / Size

Q & A