Software Testing

Test Planning, Test Process by G C Reddy (919247837478)(gcreddy@gcreddy.com)

Testing Forum QTP Brochure QTP Online Training QTP Training in Hyderabad QTP Software Testing 3/16/10

Software Testing Guide

Software Testing Guide

I) Introduction a) Software, Types of Software b) Software Project, Application and Product c) Software Business Process II) SDLC (SOFTWARE DEVELOPMENT LIFE CYCLE) a) Requirements Gathering b) Analysis & Planning c) Software Design d) Coding/Implementation e) Testing f) Release & Maintenance III) SDLC Models a) Sequential Models 1) Waterfall Model 2) V Model b) Incremental / Iterative Models 1) Prototype Model 2) Spiral Model 3) Agile Model

IV) Test Levels nit Testing/Component Testing/Module Testing

ntegration Testing

ystem Testing V) SOFTWARE ENVIRONMENT a) I-Tier or Standalone Applications b) II-Tier or Client/Server Applications c) III-Tier or Web Applications d) N-Tier or Distributed Applications VI) Test Types a) Functional Testing b) Non-Functional Testing c) Structural Testing d) Re & Regration Testing VII) Test Design Techniques a) Black box Techniques 1) Equivalence Partitioning/ Equivalence Classes (EP/EC) 2) Boundary Value Analysis (BVA) 3) Decision Table Testing 4) State Transition Testing 5) Use Case Testing b) White box Techniques 1) Statement Testing 2) Decision Testing 3) Condition/Multi Condition Testing 4) Mutation Testing VIII) Testing Process (STLC) a) Test Strategy b) Test Planning c) Configuration Management d) Risk Analysis e) Test Design (Test Scenarios, Test Cases and Test Data) f) Test Execution g) Defect Reporting & Tracking h) Status Reporting i) Test Closure

cceptance Testing

IX) Informal Testing a) Exploratory Testing b) Error Guessing X) Quality Standards a) ISO Standards b) IEEE Standards c) CMM/CMM (I) Process Guidelines

XI) Software Business Domains

a) BFSI b) ERP c) Healthcare d) Telecom e) Ecommerce f) Others

Software Quality: Software satisfies quality only when it meets to Customer Requirement / Customer Satisfaction / Customer Expectations. Meets Customer Requirement refers to proper output & Customer Expectations refers to extra characteristics, good interface, speed, privacy, security, easy to operate, good functionality. Non-technical reasons: Cost of product & Time to market

Software Quality Assurance: SQA are the Concepts to be followed by company to develop the software. An SQA team is responsible for Monitoring & Measuring the strength of developing processes.

Software Project: A set of problems assigned by the client, who can be solved by the software people through the process of software Engineer called Software project. In short, the problem, the people, the process called project. Software related problem is solved by software engineers through software engineer process is software project.

Software Development Life Cycle / Life Cycle Development: Stages involved in software project development

1) 2) 3) 4) 5) 6)

Information gathering; Customer requirement Analysis; Customer requirement v/s Solutions Design; Dividing the project into modules & coupling them Coding; Physical construction of project Testing Maintenance

Information gathering stage: In this stage, Business Analyst studies the requirement of the client /customer and they prepare Business Requirement Specification (BRS) documents.

Analysis: In this stage, Sr. Analyst prepares Software Requirement Specification (S/w RS) document with respect to corresponding BRS document. This document consists of two subdocuments System Requirement Specification (SRS) & Functional Requirement Specification (FRS). SRS contain details about software & hardware requirement. FRS contains details about the functionality to be used in project.

Designing: In designing phase, Designers creates two documents High Level Document (HLD) & Low Level Document (LLD). HLD consists of main modules of the project from root to leaf and multiple LLDs. LLD consists of sub-modules of main module along with Data flow diagrams, ER-Diagrams, etc., are prepared by technical support people or designers called Internal designers. Black box tester should have knowledge of customer requirement Black box testing tests BRS & SRS Testing external interfacing is Black box testing Testing internal interfacing is White box testing White box testing is done w.r.t design documents

Testing:

Testing

Development
V MODEL TESTING

Port testing Test Software changes Test efficiency

Functional system testing User acceptance testing Test documentation

Design phase testing Programme phase testing

Assesment development plan Prepare Test plan Requirement phase testing

MAINTENANCE

Install Build

Design & Coding

INFORMATION

* Test plan is developed based on Development plan Formula for test efficiency: DRE = A / A + B DRE = Defect Removal Efficiency A -> Bugs found at the testing side B -> Bugs found at the client side DRE= 0.8 0.9 good 0.7 0.8 requires improvement < 0.7 poor

Refinement Form of V-Model

From the above refinement form of V-Model, small & medium scale organizations are maintaining separate testing team for Functional & System testing stage.

1)

Reviews during Analysis

In general, Software development process starts with Information Gathering & Analysis. In this stage Business Analyst category people are preparing BRS & S/w RS documents and after completion documents preparation, they conduct reviews on the documents for completeness & correctness. This review focuses on below factors: 1) 2) 3) 4) 5) Are Are Are Are Are they they they they they complete met with right requirements of client / customer achievable w.r.t technology reasonable w.r.t time & cost testable

2) Reviews during Design After completion of Analysis phase & their reviews, our Project-level designers will start logical design of application in terms of External & Internal design (HLDs & LLDs). In this stage, they conduct reviews for completeness & correctness of designed documents. This review focuses on below factors: 1) Are they understandable 2) Are they met with right requirements of client / customer 3) Are they complete

4) Are they follow able 5) Does they handle errors

3)

During Unit Testing

After completeness of Design & their reviews, software programmers will starts coding the logical design to physical construction of software. During these coding stage programmers is conducting Unit Testing through a set of White box testing techniques, Unit Testing also known as Module / Component / Program / Micro testing

White box Testing: There are three possible White box testing techniques 1) Execution Testing Basic path coverage Execution of all possible blocks in a program Loops coverage Termination of loop statements Programmer technique coverage less no of memory cycles & CPU cycles 2) Operation Testing Running the application on Customer expected platforms

3)

Mutation Testing

Mutation means that a change program. White box testers are performing the change in the program to estimate test coverage on that program. Mutation testing can decide whether the test coverage is correct or wrong 4) Integration Testing

After completion of dependent modules of development & testing, Programmers combine them to form a System. In this Integration, they are conducting Integration testing on the compiled modules w.r.t HLD. There are three approaches to conduct Integration testing a) Top-Down Approach

Top-Down Approach In this approach, testing is conducted on Main module without conducting testing to some of sub-modules. From the above diagram, a Stub is a temporary program instead of under constructive sub-module, it is known as called program.

b)

Bottom-Up Approach

Bottom-Up Approach

In this approach, testing is conducted on sub-modules without conducting testing on main modules. From the above diagram, a Driver is a temporary program instead of main module, it is known as calling program. c) Sandwich or Hybrid Approach

Sandwich / Hybrid Approach In this approach, testing is conducted taking both Top-Down & Bottom Approaches. * Build: A finally integrated all modules set *.exe form file is called build. 4) Functional & System testing (* imp)

After completion of final integration of modules as a system, Testing Engineers are planning to conduct Functional & System testing through Black box testing techniques, these techniques classified into four categories. 1) 2) 3) 4) Usability Testing Functional Testing Performance Testing Security Testing From Above 1 & 2 are Core level and 3 & 4 are Advance level During During During During Usability testing, Testing team validates User-Friendliness of screens. Functional testing, TT validates the correctness of customer requirements Performance testing, TT estimates speed of processing Security testing, Testing team validates privacy to User operations

1)

Usability Testing

In general, TT starts with test execution with Usability testing. During test, Testing team validates User-Friendliness of screens of build. During Usability testing, TT applies two types of sub-test: a) User Interface Test

Easy of use (Understandable screens) Look & Feel (Attractiveness & Pleasantness) Speed in Interface (Less no of event to complete a test, easy short navigation) b) Manual Support Test

Context sensitiveness of user manuals Manual support test are conducted at the end of all testing & before release 2) Functional Testing

The major part of Black box testing is Functional testing, during this test, Testing team1 concentrates on meet customer requirements. This Functional Testing is classified into below sub-test.

a)

Functional / Requirement Testing

During this test, Test Engineers validates correctness of every functionality in terms of below coverages. Behavioral coverage (changes in object properties) Input domain coverage (size & type of every input & output object) Error handling coverage (preventing negative navigations) Calculations coverage (correctness of output) Back-end coverage (impact of Front-end operation on back-end tables contents) Service levels coverage (order of functionalities) b) Input Domain Testing

It is a part of Functionality testing; Test Engineers are maintaining special structures to define size & type of input object c) Recovery Testing

It is also known as Reliability testing. During this test, Testing team validates whether the application is changing from abnormal state to normal state or not. d) Compatibility Testing

It is also known as Portability testing. During this test, Testing team validates whether application build run on customer expected platforms or not. During this test, Testing Engineers are finding Backward compatibility at maximum. Forward compatibility -> application is ready to run but Operating system is not supporting.

Backward compatibility -> Operating system is supporting but the application has some internal coding problems to run on Operating system e) Configuration Testing

It is also known as Hardware compatibility testing. During this test, Testing team validates whether application build supports different technology Hardware devices or not. f) Inter-Systems Testing

During this test, Testing team validates whether application build co-existence with other existing softwares or not and also test whether any Dead lock situation occurs or not.

g)

Installation Testing

During this test, Testing team validates whether application build along with supported softwares into customers site like configured systems. During this test, Testing team observes below factors. Setup program execution to start installation Easy Interface Amount of disk occupied after installation h) Parallel / Comparative Testing

During this test, Testing team compares application build with competitive products in market. i) Sanitation / Garbage Testing

During this test, Testing team tries to find extra features in application build w.r.t customer requirements. * Defects During this test, Testing team reports defects to developers in terms of below categories

1. 2. 3.
*

Mismatches between expected & actual Missing functionality Extra functionality w.r.t customer requirement

Manual v/s Automation

A Tester conducts any test on application build without using any testing tool is called Manual testing, if any testing tool is used then it is called Automation testing

In common testing process, Testing Engineers are using test Automation w.r.t test impact & criticality. Impact -> test repetition & Criticality -> complex to apply test manually. Due to these two reasons testing people are using test Automation. j) Re-testing

The re-execution of a test with multiple test data to validate a function, e.g. To validate multiplication, Test Engineers use different combinations of input in terms of min, max, -ve, +ve, zero, int, float, etc.

k)

Regression Testing

The re-execution of test on modified build to ensure bug fixing work & occurrence of any side effects, Test Engineers conducts this test using Automation l) Error, Defect & Bug

A mistake in code is Error, due to errors in coding, Test Engineers are getting mismatches in application build are defects, if the defects are accepted by developers to be solves then it is Bug.

Testing Documents

Above Figure, shows the various levels of documents prepared at project testing. Test Policy is documented by Quality Control. Test Strategy & Test Methodology are documented by Quality Analyst or Project Manager. Test Plan, Test Cases, Test Procedure, Test Script & Defect Report are documented by Quality Assurance Engineers or Test Engineers. Test Policy & Test Strategy are Company Level Documents. Test Methodology, Test Plan, Test Cases, Test Procedure, Test Script, Defect Report & Final Test Summary Report are Project Level Documents.

1)

TEST POLICY:

This document developed by Quality Control people (Management). In this document Quality Control defines Testing Objective. Test Policy Document

Address of the Company

Test Definition Testing Process Testing Standards

: : :

Verification & Validation Proper planning before starts testing One defect per 250 lines of code or 10 FP (Functional points) QAM, TTM, PCM

Testing Measurements :

******* (C.E.O) QAM: Quality Assurance Measurements, how much quality is expected TTM: Testing Team Measurements, how much testing is over & is yet to complete PCM: Process Capability Measurements, depends on old project to the upcoming projects.

2)

TEST STRATEGY:

This is a Company level document & developed by Quality Analyst or Project Manager Category people, it defines Testing Approach. Components: a) b) c) d) e) f) Scope & Objective: Definition & purpose of testing in organization Business Issue: Budget control for testing Test Approach: Mapping between development stages & Testing Issue. Test Deliverables: Required testing documents to be prepared Roles & Responsibilities: Names of the job in testing team & their responsibilities Communication & Status reporting: Required negotiation between testing team & developing team during test execution g) Automation & Testing Tools: Purpose of automation & possibilities to go to test automation h) Testing Measurements & Metrics: QAM, TTM, PCM i) Risks & Mitigation: Possible problems will come in testing & solutions to overcome j) Change & Configuration Management: To handle change request during testing k) Training Plan: Required training sessions to testing team before start testing process

Testing Issues:

1. 2. 3. 4. 5. 6. 7. 8.

Authorization: Whether user is valid or not to connect to application Access Control: Whether a valid user have permission to use specific service Audit Trail: Maintains metadata about user operation in our application Continuity of Processing: Inter-process communication Correctness: Meet customer requirement in terms of functionality Coupling: Co-existence with other existence software to share resources Ease of Use: User Friendliness of the screens Installation, Un-installations, Dumping, Uploading,

Ease of Operator: Downloading, etc.,

9. 10. 11. 12. 13. 14. 15.

File Integrity: Creation of backup Reliability: Recover from abnormal state Performance: Speed of processing Portable: Run on different platforms Service levels: Order of functionalities

Maintainable: Whether our application build is long term serviceable to our customer Methodology: Whether our tester are following standards or not during testing 3) TEST METHODOLOGY: It is project level document. Methodology provides required testing approach to be followed for current project. In this level Quality Analyst select possible approach for corresponding project testing.

Pet Process: Process involves experts, tools & techniques. It is a refinement form of V-Model. It defines mapping between development & Testing stages. From this model, Organizations

are maintaining separate team for Functional & System testing & remaining stages of testing done by development people. This model is developed in HCL & recognized by QA Forum of INDIA.

TESTING PROCESS

Information Gathering (Business Requirement Specifications)

Unit & Integration

Test Closure

4)

TEST PLANNING:

After finalization of possible test for current project, Test Lead category people concentration on test plan document preparation to define work allocation in terms of What, Who, When & How to test. To prepare test plan document, test plan order follows below approach;

1]

Team Formation:

In general, Test planning process starts with testing team formation. To define a testing team, test plan author depends on below factors; 1. 2. 3. Availability of testers Test duration Availability of test environment resource 2] Identify Tactical Risk:

After Testing team formation Plan author analysis possible & mitigation (ad hoc testing) # Risk 1: # Soln 1: Lack of knowledge of Test Engineer on that domain Extra training to Test Engineers

# Risk 2: # Risk 3: # Soln 3: # Risk 4: # Soln 4: data # Risk 5: # Soln 5: # Risk 6: # Soln 6: # Risk 7:

Lack of Resource Lack of budget {less no of time} Increase Team size Lack of Test data Conduct test on past experience basis i.e., ad hoc testing or contact client for

Lack of developer process rigor Report to Test Lead for further communication between test & development PM Delay of modified build delivery Extra hours of work is needed Lack of communication in between Test Engineer - > Test team and Test team - > Development team

3]

PREPARE TEST PLAN:

After completion of testing team formation & Risk analysis, Test plan author concentrate on Test Plan Document in IEEE format. 01) 02) 03) 04) 05) Test Plan ID: Unique No or Name e.g. STP-ATM Introduction: About Project description Test Items: Modules / Functions / Services / Features / etc. Features to be tested: Responsible Modules for Test design (preparing test cases for added modules) Features not to be tested: Which feature is not to be tested and Why? (Due to test cases available for the old modules, so for these modules no need to be tested / no test case

Above (3), (4) & (5) decides which module to be tested > What to test? 06) 07) 08) 09) 10) type 11) Approach: List of selected testing techniques to be applied on above specified modules in reference to the TRM(Test Responsible Matrix). Feature pass or fail criteria: When a feature is pass or fail description (Environment is good) (After testing conclusion) Suspension criteria: Possible abnormal situations rose during above features testing (Environment is not good) (During testing conclusion) Test Environment: Required software & Hardware to be tested on above features Test Deliverables: Required testing document to be prepared (during testing, the Testing Task: of documents are prepared by tester) Necessary tasks to do before start every feature testing

Above (6) to (11) specifies -> How to test? 12) 13) Staff & Training: Names of selected Test Engineers & training requirements to them Responsibilities: Work allocation to every member in the team (dependable modules are given to single Test Engineer)

14)

Schedule:

Dates & Times of testing modules

Above (4) specifies -> When to test? 15) 16) 4) List & Mitigation: Possible testing level risks & solution to overcome them Approvals: Signatures of Test plan authors & Project Manager / Quality Analyst Review Test Plan:

After completion of plan document preparation, Test plan author conducts a review of completion & correctness. In this review, Plan author follows below coverage analysis BRS based coverage (What to test? Review) Risks based coverage (When & Who to test? Review) TRM based coverage (How to test? Review) 5) TEST DESIGNING:

After completion of Test Planning & required training to testing team, corresponding testing team members will start preparing the list of test cases for their responsible modules. There are three types of test cases design methods to cover core level testing (Usability & Functionality testing). a) b) c) Business Logic based test case design (S/w RS) Input Domain based test case design (E-R diagrams / Data Models) User Interface based test case design (MS-Windows rules) a) Business Logic based Test Case design (S/w RS)

In general, Test Engineers are preparing a set of Test Cases depends on Use Cases in (S/w RS). Every Use Case describes a functionality in terms of inputs, process & output, depends on this Use Cases Test Engineers are preparing Test Cases to validate the functionality

From the above model, Test Engineers are preparing Test Cases depends on corresponding Use Cases & every test case defines a test condition to be applied. To prepare test cases, Test Engineers studies Use Cases in below approach: Steps: 1) Collect Use Cases of our responsible module 2) Select a Use Case & their dependencies from the list 2.1) Identify entry condition (Base state) 2.2) Identify input required (Test data) 2.3) Identify exit condition (End state) 2.4) Identify output & outcome (Expected) 2.5) Identify normal flow (Navigation) 2.6) Identify alternative flows & exceptions 3) 4) 5) Write Test Cases depends on above information Review Test Cases for the completeness & correctness Goto step (2) until completion of all Use Cases completion

Use Case I: A login process allows user id & password to validate users. During these validations, login process allows user id in alpha-numeric from 4 to 16 characters long & password in alphabets in lowercase from 4 to 8 characters long. Case study: Test Case 1) Successful entry of user id

BVA (Size)

min min-1 min+1 max-1 max+1 max

-> 4 chars => -> 3 chars => -> 5 chars => -> 15 chars -> 17 chars -> 16 chars ECP

pass fail pass => => =>

pass fail pass

Valid a-z A-Z 0-9

Invalid special chars blank

Test Case Format: During Test design Test Engineers are writing list of Test Cases in IEEE format. 01) 02) 03) 04) 05) Test Case ID: Unique no or name Test Case Name: Name of test condition to be tested Feature to be tested: Module / Function / Feature Test suit ID: Batch ID, in which this case is member Priority: Importance of Test Case {Low, Med, High} P0 -> Basic functionality P1 -> General functionality (I/P domain, Error handling, Compatibility etc,) P2 -> Cosmetic testing (UIT) 06) 07) 08) 09) 10) Test Test Test Test Test Environment: Required Software & Hardware to execute afford (person / hr): Time to execute this Test Case e.g. 20 minutes duration: Date & Time Setup: Required testing task to do before starts case execution (pre-requisites) Procedure: Step by step procedure to execute Test Case

Test Procedure Format:

2) 3) 4)

1) Step No: Action: Input required: Expected:

-> Test Design

5) 6) 7)

Actual: Result: Comments:

-> Test Execution

11)

Test Case passes or fails criteria: When this case is pass or fail Test Engineers follows list of Test Cases along with step by step procedures only

Note:

Example 1: Prepare Test Procedure for below test cases Successful file save operation in Notepad . Step No 1 2 3 4 Action Open Notepad Fill with text Click Save Icon or click File menu Option & select save option Enter File name & Click Save Input Required Expected Empty Editor Save Icon enabled Save Dialog box appears with Default file name Focus to Notepad & File name Appears in title bar of Notepad

Unique File name

Note: For more examples refer to notes b) Input Domain based Test Case design (E-R diagrams / Data Models)

In general, Test Engineers are preparing maximum Test Cases depends on Use Cases or functional requirements in S/wRS. These functional specifications provide functional descriptions with input, output & process, but they are not responsible to provide information about size & type of input objects. To correct this type of information, Test Engineers study Data model of responsible modules E-R diagram. During Data model study, Test Engineer follows below approach: Steps: 1) 2) 3) 4) Collect Data model of responsible modules Study every input attribute in terms of size, type & constraint Identify critical attributes in the test, which is participated in manipulation & retrivals Identify non-critical attributes such as input & output type

A/C No: Critical

A/C Name: Balance: NonCritical

Address:

5)

Prepare BVA & ECP for every input object ECP BVA(Size / Range) Minimum xxxx Maximum xxxx

Input Attribute Xxxx

Valid Invalid xxxx xxxx DATA MATRIX

Note: In general, Test Engineers are preparing step by step procedure based Test Cases for functionality testing. Test Engineers prepare valid / invalid table based Test Cases for input domain of object testing {Data Matrix } Note: notes For examples refer to

c) User Interface based test case design (MS-Windows rules) To conduct Usability Testing, Test Engineers are preparing list of Test Cases depends on our organization User Interface standards or conventions, Global User Interface rules & interest of customer site people. Example: Test Cases 1) 2) 3) 4) Spelling check Graphics check (Screen level Align, Font style, Color, Size & Microsoft six rules) Meaning of error messages Accuracy of data displayed

5) Accuracy of data in the database are result of user inputs, if developer restrict the data in database level by rounding / truncating then the developer must also restrict the data in front-end as well 6) Accuracy of data in the database as the result of external factors. Ex. File attachments 7) Meaningful help messages (Manual support testing)

Review Test Cases: After completion of all possible Test Cases preparation for responsible modules, Testing team concentrates on review of Test Cases for completeness & correctness. In this review, Testing team applies coverage analysis. Test Case Review 1) 2) 3) 4) 5) BR based coverage Use Cases based coverage Data model based coverage User Interface based coverage TRM based coverage

At the end of this review, Test Lead prepare Requirement Traceability Matrix or Requirement Validation Matrix (RTM / RVM) Business Requirement Source (Use Cases, Data model) Test Cases

xxxx

xxxx

xxxx

xxxx xxxx

xxxx

xxxx xxxx

xxxx

xxxx xxxx xxxx

xxxx

xxxx

xxxx xxxx

xxxx

xxxx xxxx xxxx

From RTM / RVM model, it defines mapping between customer requirement & prepared Test Cases to validate the requirement. 6) TEST EXECUTION:

After completion of Test Cases selections & their review, Testing team concentrate on Build release from development side & Test execution on that build. a) Test Execution Levels or Phases: See figure in next page for clear understandability of this levels b) Test Execution Levels v/s Test Cases: Level 0 -> P0 Test Cases Level 1 -> All P0, P1 & P2 Test Cases as batches Level 2 -> Selected P0, P1, & P2 w.r.t modification Level 3 -> Selected P0, P1, & P2 w.r.t critical areas in the master build

A) Test Execution Levels or Phases:

Defect Report

Level 1 Comprehensive Level 3 Final Regression

Level 2 Regression

Defect Fixing

c) Build Version Control: In general, Testing Engineers are receiving build from development in below model

Testers

Build

Testing Environment

FTP (file transport Protocol)

Server

During Test execution Test Engineer are receiving modified build from software. To distinguish old & new builds, development team maintains unique version in system, which is understandable to Tester / Testing team. For this version controlling developers are using version control tools (Visual Source Safe) d) Level 0 (Sanity / Test Acceptance / Build verification test):

After receiving initial build, Testing Engineers concentrate on basic functionality of that build to estimate stability for complete testing. In this Sanity testing, Testing Engineers tries to execute all P0 Test Cases to cover basis functionality. If functionality is not working /

functionality missing, Testing team rejects that build. If Tester decided stability then they concentrate on Test execution of all Test Cases to detect defects.

During this Sanity testing, Testing Engineer observes below factors on that build 1) 2) 3) 4) 5) 6) 7) 8) Understandable Operatable Observable Consistency Controllable Simplicity Maintainable Automation From the above 8 testable issues, Sanity test is also known as Testability testing / OCT angle testing. e) Test Automation:

If test automation is possible than Testing team concentrate on Test script creation using corresponding testing tools. Every Test script consists of navigation statement along with required check points. Stable Build

Test Automation (Select Automation)

(All P0 & Carefully selected P1 Test Cases) f) Level 1 (Comprehensive testing)

After completion of Sanity testing & possible test automation, Testing team concentrates on test batches formation with depended Test Cases. Test batches are also known as Test suits / sets. During these Test batches execution, Test Engineers prepare test log document, this document consist of three types of entries. 1) 2) 3) Passed (Expected = Actual) Failed (Any one Expected != Actual, Any one Expected variants from Actual) Blocked (Corresponding parent functionality failed)

g)

Level 2 (Regression testing)

During Comprehensive test execution, Test Engineers are reporting mismatches as defects to developers. After receiving modified build from developers, Test Engineers concentrate on Regression testing to ensure bug-fixing work & occurrences of side effects.

Case I: If development team resolve bugs severity which is high, Test Engineers re-execute all P0, P1 & carefully selected P2 Test Cases on modified build Case II: Bugs severity is medium, then all P0, carefully selected P1 & some of P2 Test Cases Case III:

Bugs severity is low, then some P0, P1 & P2 Case IV: If development team released modified build due to sudden changes in project requirement then Test Engineers re-execute all P0, P1 & carefully selected P2 Test Cases w.r.t that requirement modification. h) Level 3 (Final Regression / Pre-Acceptance testing)

7)

TEST REPORTING:

During comprehensive testing, Test Engineer are reporting mismatches as defects to developers through IEEE format. 1) 2) 3) 4) 5) 6) 7) 8) 9) Defect ID: Unique No or Name Description: Summary of the defect Feature: Module / Function / Service , in these module TE found the defect Test Case Name: Corresponding failing test condition Reproducible (Yes / No): Yes -> Every time defect appears during test execution No -> Rarely defect appears If Yes, attach test procedure: If No, attach snapshot & strong reasons: Status: New / Reopen Severity: Seriousness of defect w.r.t functionality (high / medium / low)

10) 11) 12) 13) 14) 15)

Priority: Importance of the defect w.r.t customers (high / medium / low) Reported bug: Name of Test Engineer Reported on: Date of submission Assign to: Name of the responsible person in development team -> PM Build Version ID: In which build, Test Engineer fount the defect Suggested fix (Optional): Tester tries to produce suggestion to solve this defect

16) Fixed by: PM or Team Lead 17) Resolved by: Developer name 18) Resolved on: Date of solving 19) Resolution type: check out in next page 20) Approved by: Signature of Project Manager (PM) Defect Age: The time gap between reported on & resolved on Defect submission process:

By Developers

Defect Status Cycle: New Open / rejected / deferred close reopen

Deferred => Accepted but not interested to resolve in this version Defect Resolution: After receiving defect report from Testers, developers review the defect & they send resolution type to Tester as a reply 01) Duplicate, rejected due to the defect is same as previously reported defect 02) Enhancement, rejected due to the defect is related future requirement of customer 03) H/w limitation, rejected due to the defect raised w.r.t limitation of H/w devices

04) 05) 06) 07) 08) 09) 10) 11) 12)

S/w limitations, rejected due to the defect raised w.r.t limitation of S/w Techno Not applicable, rejected due to the defect has no proper meaning Functions as designed, rejected due to coding is correct w.r.t to designed docs Need more information, not (accepted / rejected) but developers requires extra information to understand the defect Not reproducible, not (accepted / rejected) but developers require correct procedure to reproduce the defect No plan to fix it, not (accepted / rejected) but developers want extra time to fix Fixed, developers accepted to resolve Fixed indirectly, accepted but not interested to resolve in this version (default) User misunderstanding, need extra negotiation between testing & development team. Types of defects: 01) User Interface bugs (low severity): 1) Spelling mistakes (high priority) 2) Improper alignment (low priority) 02) Boundary related bugs (medium severity) 1) Doesnt allows valid type (high priority) 2) Allows invalid type also (low priority) 03) Error handling bugs (medium severity) 1) Doesnt providing error message window (high priority) 2) Improper meaning of error message (low priority) 04) Calculations bugs (high severity) 1) Final output is wrong (low priority) 2) Dependent results are wrong (high priority) 05) Race condition bugs (high severity) 1) Dead lock (high priority) 2) Improper order of services (low priority) 06) Load conditions bugs (high severity) 1) Doesnt allow multiple users to access / operate (high priority) 2) Doesnt allow customers accepted load (low priority) 07) Hardware bugs (high severity) 1) Doesnt handle device (high priority) 2) Wrong output from device (low priority) 08) ID control bugs (medium severity) 1) Logo missing, wrong logo, Version No mistake, Copyright window missing, Developers Name missing, Tester Name missing 09) Version control bugs (medium severity) 1) Differences between two consecutive build versions 10) Source bugs (medium severity) 1) Mistake in help documents Manual support

8)

TEST CLOSURE:

After completion of all possible test cycle execution, Test Lead conducts a review to estimate the completeness & correctness of testing. In this review, Test Lead follows below factors with Test Engineers 1) Coverage Analysis a) b) c) d) e) BR based coverage Use Cases based coverage Data model based coverage User Interface based coverage TRM based coverage 2) Bug density a) b) c) d) Module A has 20% percentile bugs found Module B has 20% percentile bugs found Module C has 40% percentile bugs found Module D has 20% percentile bugs found 3) Analysis of deferred bugs Whether deferred bugs are deferrable or not At the end of this review, Testing team concentrate on high bug density modules or all modules if time is available. 9) User Acceptance Testing (UAT)

Organization management concentrate on UAT to collect feedback, there are two approaches to conduct testing. 1. Alpha () test 2. Beta () test 10) Sign Off After completion of User Acceptance testing & their modifications, Test Lead concentrates on final test summary report creation. It is a part of Software Release Node (S/w RN). This final test summary report consist of below documents 1) 2) 3) 4) 5) Test Strategy / Methodology (TRM) System Test Plan Requirement Traceability Matrix (RTM) Automated Test Scripts Bugs Summary Reports The below, has to be in horizontal direction Bug Description

Feature Found By Status (closed / deferred) Comments CASE STUDY ON A PROJECT TESTING PROCESS The X is a client/server product. It is running in single computer with windows 2000 as OS this product provides a facility to search matched records in existing database. w.r.t has given search keys. Local host

This product maintains a default administrator to create new users and every valid user search data in database. Activity flow diagram: -

Admin (Or) user

Admin Invalid user Valid

Search keys

Existing DB

FUNCTIONAL POINTS: Login is taking user id and password User id and password allows alphabets in lower case from 4 to 8 characters long. New user ids created by administrators only New user creation windows allows unique user id and password with create and cancel buttons Search records opened for valid users only Search records window maintains below search keys Customer id: 6 digits number (collected from design document First name: one character in upper or lower Last name: one to eight characters in lower case characters Date of birth: dd\mm\yy in numeric Age: from and to in numeric Search records windows allows below combination of fields to search records. Last name Last with first name

 Last name with first name and d-o-b Last name with first name and age Customer id only Search records window consists of start search and stop search buttons. Allows last name as full or partial Allows customer id as full or partial with * or wild card Customer id

286*----2 8 6 * ------

Refresh search records window using Alt+ctrl Display matched records in a pop-up window with ok button after search completion. Returns message like too many matches to display when matched records >1000 Test methodology:- (by PM) Testing stage System testing Testing Factors Authorization Access Control Audit trail Continuity to Correctness Coupling Data integrity Ease of use Ease of operate Reliability Fortable Performance Service levels Maintainable Methodology Note: Test responsibility matrix for IIXI (11 by 1)

X product is maintaining metadata so it is not sharing resources of other application This application went to run on windows 2000 It is a stand alone application (at time one user can operate) So need net to test load and stress testing) System test plan by test lead:-

1. 2. 3.

Test plan ID: STP_X

Introduction: X is a product and it provides a facility to connect to existing data base and search matching records to retrieve. Test items user creation Login by user Search records 4. Features to be tested: user creation Login by user Search records 5. Features not to be tested:Approach: To apply PM selected 1 factors from TRM, below black box testing techniques are suitable to follow depends on test lead.

6.

User interface testing Manual support testing Functionality testing i/p domain testing Recovery testing Sanitation testing Installation testing Security testing Complaints testing

7.

Entry criteria: -

Are the necessary documents available? Is the X product is ready for release from developers? Is the supporting database available to search required records? Is the test environment ready?

8.

Suspension criteria:

Data base disconnect may require suspension of testing Suspension of testing is mandatory when searching records process went to infinite. Admin is failed to new user creation, a decision can be mad to continue testing on searching records module using admin or other existing valid users.

9.

Exit Criteria: -

Ensure that the X product provides the required services Ensure that all test documents has been completed up to date. All high severity bugs resolved.

10.

Test deliverables:-

Test cases Test procedures Automated Test scripts Test log Defect Report

Test Engg..

11.

Test environment:-

Client pc or local host OS: Win2000 DB server: ORACLE/ SQL SERVER/ MS-ACCESS Connectivity: DSN/ Thin Drivers 12. Testing Tasks:-

Availability of admin with password Database consists of records Valid users are able to database to search records 13. Staff and Training needs:Test Engg.. / QA Engg: Kurugonda Srinaiah

14.

Responsibilities: Responsibility K.Srinaiah K Srinaiah Test Lead with K Srinaiah 12 hours every day during Testing At the end of the Testing Effort

Document / Report

1. Tst cases with procedures Defect Report Test completion reports

15.
Task date

Schedule: Effort Start date End

Test design Implement test and Review Execute test Evaluate test

12 hours 4 hours 24 hours 8 hours

28-12-2005 29-12-2005 30-12-2005 02-01-2006

29-12-2005 29-12-2005 01-01-2006 02-01-2006

16. 1.

Risks and mitigations:Lack of documentation:

Contact business analyst Ad-hoc testing Contact customer site people if possible

2.
Over-time

Lack of time

3.
Over time

Delays and delivery:

4.

Lack of development process reggur:

Contact test lead to motivate developers Over time to complete task is right time

17.

APPROVALS: -

Test case 1: Signature of PM and signature of test lead. Test case 2: Successful entry of user id

BVA (size) Min = 4 chars pass Max = 8 chars pass Min-1 =3 chars fail Min +1 = 5 chars pass Max 1 = 7 chars pass Max +1 = 9 chars fail Test case 3: successful entry of password BVA (size) Min = 4 chars pass Max = 8 chars pass Min 1 = 3 chars fail Min +1 = 5 chars pass Max + = 7 chars pass Max = 9 chars fail

Test case 4: successful login operation User id Admin Admin Other valid Other valid Other invalid Blank Valid Password valid invalid valid invalid invalid value blank Criteria pass fail pass fail fail fail fail

Test case 5: Successful selection of new user creation option Test case 6: Un successful selection of this option due to current user is not admin. Test case 7 successful entry of user id in create user window

Note: (like as Test case2) Test case 8: Successful entry of userid in create user window

Note: (-----------test case 3) Test case9: Successful creation of new user by admin Test case10: unsuccessful new user creation due to given user id is not unique. Test case 11: successful closing of new user creation window using cancel (After enter user id and offer enter passes) Test case 12: Successful selection of search records option Test case 13: successful entry of customer id BVA (size) Min = max = 6 ECP (TYPE) valid invalid -------------------------0 9 a-z, A-Z, special characters Expect * , blank space Start with * Exp: 123 , *23, 1*23X

Test case 14: successful entry of first name Min = max = 1 pass o fail a- z A-Z o-9, special characters Ecp --------------------------valid invalid ----------------------------

Test case 15: successful entry of last name: Min = 1 and max = 8 pass a- z A-Z, o-9,

---------------valid invalid -----------------

Special characters Test case 16: successful entry of DOB BVA (range) Ecp (type) ----------------valid invalid ----------------special characters

Day: min 01 min 31 0- 9 a-z, A-Z Month: min 01 max 12 Year: min 00 max 99 Case 17: success entry of age from

min 01 max 22 0- 9 a-z, A-Z

Ecp(type) ----------------valid invalid -----------------

Special characters Test case 18: successful entry of age to Note: like as above Test case 19: successful display of matched records with full last name and all other fields are Blank Test case 20: successful display of matched records with full last name and first name Test case21: successful display of matched records with full last name first name and dob Test case22: successful display of matched records with full last name first name age Test case 23: on successful search operation due to invalid combination of filled fields. Test case 24: unsuccessful search operation due to invalid Dob Test case 25: unsuccessful search operation due to age from greater than age To Test case26: successful display of records with search key as partial last name and other fields as blank

Test case 27:successful display of records with search key a partial last name and first name Test case 28: successful display of records with search key as partial last name, first name and Dob Test case 29: successful display of records with search key as partial last name, first name Test case 30: successful display of records with search key as customer id Test case 31: successful display of records with search key as partial customer id with * as wild card Test case 32: Unsuccessful display of records due to no matching records in database w.r.to given search keys Test case 33: unsuccessful display of records due to too many records to display when no of matched records greater than 1000 Test case 34 : successful refresh search window with Alt +Ctrl Test case 35: Successful termination of search operation when click stop search button. Test case 36: successful closing of records window through click o.k after searching.

Test case 37: spelling check in every screen Test case 38: Graphics check in every screen Ex: (alignment, font, size, label, graphical, colour, etc) Usability Testing Test case39: Accuracy of data displayed Ex:Dob dd\mm\yy

Test case 40: Meaninful help messages and error messages

Posted by G.Chandra Mohan Reddy at 1:43 AM

12 comments:
Snaru said... Hi Mohan, Software testing guide is really very useful stuff. Can you please the provide the software testing guide with download option andf also append the screenshots in clearly. Thanks in advance for your needful help.

sujatha. April 19, 2010 4:12 AM

Rani said... hello mohan, This info is very much useful to everyone. Also for the Automated Testing Tools like QTP you have several info cum scripts.Keep it up. Thanks Amaravathi April 22, 2010 2:44 PM

somesh said... Dear Mohan Thanks for such a wonderful material. I think some images are missing. Can you provide a link to download this guide. April 23, 2010 11:09 AM

somesh said... Hi mohan Thanks for such a wonderful material I think some images are missing. Can you provide a downloading link for this guide. thanks April 23, 2010 11:18 AM

manju said... Excellent.....Testters like you are a real gem....i think your company might be very proud of you....Kudos for the great work...:-) April 28, 2010 6:32 AM

Anonymous said... Hello Mohan! I really very very much liked the testing material provided on this website. Specially "Software Testing Guide" link gives overall insite depth view about entire QA process. But here some images are broken so breaks reading continuity. So please fix it ASAP. If possible provide it as downloadble link. Keep this work up. Good Luck. July 25, 2010 8:24 PM

Anonymous said... This is very useful for newcomers.Thanks for such an wonderful blog. January 3, 2011 9:59 AM

Anonymous said... Hi Mohan, I was so amazed to see everything together in your blog, Thank you so much for your effort. keep posting January 28, 2011 11:16 AM

Anonymous said... 1.wht is diff between functional and regression testing? 2. regression testing is a functional testing?yes/no?why? February 12, 2011 1:38 AM

Anonymous said... Software testing guide is really very useful stuff. Can you please the provide the software testing guide with download option andf also append the screenshots in clearly. Thanks in advance for your needful help. February 28, 2011 10:35 PM

Anonymous said... Hi Mohan, Excellent information! Thank you so much for all the Testing based information. I am glad that i found this site. Thank you for sharing your knowledge. Thanks in advance for your help! April 3, 2011 9:19 AM

Saravanakannan said... Hi Mohan, This is very very useful for the testers.Really Great Job. Keep this work.. All the Best.. Thanks!! Saravanakannan April 24, 2011 7:43 PM

Post a Comment

Newer PostOlder PostHome

Subscribe to: Post Comments (Atom)

TESTING GROUP

Subscribe to G C Reddy QTP Group Email:

Subscribe

Visit this group

POPULAR POSTS Manual Testing Questions and Answers Part-I

Sample BRS Document Sample SRS Document Test case writing SQL queries examples Testing Interview questions Manual Testing Questions & Answers Part-II SQL for Testers Software Testing Guide Software Test Metrics

ABOUT ME

G.Chandra Mohan Reddy I am G C Reddy, Working as a Test Consultant in Hyderabad, INDIA. I am also providing Online training for QTP. View my complete profile
VISITOR COUNTER

website analytics

INFOLINKS RIGHT CLICK GCREDDY BLOG ARCHIVE 2010 (48) o May (4) o March (39) Software Testing Guide Unit Testing

 Selenium tool Test Management Manual Testing Questions & Answers Part-II Manual Testing Questions and Answers Part-I Configuration Management Software Test Methods Requirement Management Tools Requirements Management Rational Robot An Introduction to Quality Center An Introduction to LoadRunner Performance Testing Usability Testing CMM Levels Vs ISO Standards Agile methodology Test Design Techniques Software Test Metrics Sample SRS Document Sample BRS Document Software Test Documents ISTQB Certification Model questions Testing Interview questions Test plan Performance Test Plan Use Case template SQL queries examples Test case writing SQL for Testers web dictionary Static Testing Web testing guidelines Database tutorial Certification Model questions Software Quality Standards ISTQB Certification Guidelines Database Testing Quality Assurance o February (4) o January (1)

Picture Window template. Powered by Blogger.