Software Testing - Manual Testing

v)Test Process
vi)Test Plan
vii)Test Design Test Script
viii)Test Execution

V)Testing Process

PET Process: (Process experts, tools and technology) This testing process developed by HCL and approved quality analyst form of India. It is a refinement of V- Modal to define testing process along with development stages.

VI)Test Planning: After completion of test initiation, TL of the testing team concentrate on test planning to define "What to test", "How to test" ,"When to test", "Who to test"?. Test plan author follows below work bench (process) to prepare test plan document.

1.Team formation: In general test planning process starts with testing team formation. In this step test plan author depends on below factors
a) Availability of testers
b) Test duration
c) Availability of test environment resources
Case Study: Test duration
C/S, Web, ERP ---- 3 to 5 months of functional & system testing
Team size 3:1
2.Identify tactical risks: After completion of team formation test plan author study possible risks raised during testing of that project
Ex Risk 1: Lack of knowledge on domain
Risk 2: Lack of budget (time)
Risk 3: Lack of resources
Risk 4: Delay in delivery
Risk 5: Lack of development process rigor (seriousness of dev team)
Risk 6: Lack of test data (some times test engg conducting Ad Hoc testing)
Risk 7: Lack of communication
3) Prepare Test Plan: After completion of team formation and risk analysis test plan author prepare test plan document in IEEE format.
FORMAT:
1) Test Plan ID: Unique number
2) Introduction: About project and test team
3) Test Items: Modules/Features/services/functions
4) Features to be tested: Responsible modules to prepare test cases
5) Features to be not tested: which ones and why not?
6) Approach: Required list of testing techniques (depends on TRM)
7) Feature Pass or Fail Criteria: When a feature is pass when a feature is fail
8) Suspension Criteria : Possible abnormal situations raised during above features testing
9) Testing Tasks (Pre requisite): Necessary tasks to do before starts of every feature testing
10) Test Deliverables: Required test documents to prepare during testing
11) Test Environment: Required HW and SW including testing tools
12) Staff and Training Needs: Names of selected test engineers
13) Responsibilities: Work allocation
14) Schdule: Dates & Time
15) Risks and Mitigations :
16) Approvals : Signatures of test plan author, QA or PM

Review Test Plan: After completion of test plan preparation, test plan author review the document for completeness and correctness. In this review, responsible person conducts coverage analysis. Topics in test plan review based on
a) BRS & SRS based coverage
b) Risks based coverage
c) TRM based coverage
VII) Test Design: After completion of test plan finalization, selected test engineers involved in required training sessions to understand business logic. This type of training provided by business analyst or functional lead or business consultant. After completion of required training sessions test engineers are preparing test cases for responsible modules
There are 3 methods to prepare core level test cases (UI, Functionality, Input domain, error handling, and manual support testing). They are
1)Business Logic based test case design (80%)
2)Input domain based test case design (15%)
3)User Interface based test case design (5%)
1. Business Logic: In general functionality and error handling based test cases prepared by test engineers depends on usecase in SRS. A usecase describes that how a user use specific functionality in our application. A test case describes that a test condition to apply on that application to validate. To prepare this type of test cases depends on usecases, we can follow below approach.

Step 1: Collect responsible usecases
Step 2: Select Usecase and their dependencies
2.1 Identify entry condition (base state)
2.2 Identify input required (test data)
2.3 Identify exit condition (end state)
2.4 Identify out put and out come (expected)
2.5 Study normal flow (call states)
2.6 Identify alternative flows and exceptions
Step 3: Prepare test cases depends on above study
Step 4: Review the test case as per completeness and correctness
Usecase 1
From a usecase and data modal, a login process allows userid and password. Userid is taking alphanumeric and lowercase from 4 to 16 characters long. Password allow alphabets in lower case from 4 to 8 characters long.
Test case 1: Successful entry of userid

BVA (Size)------------------------------------ECP (Type )
Min 4-- Pass----------------------------------Valid----Invalid
Max 16-- Pass--------------------------------0-9-----A-Z
Max -1-- Pass--------------------------------a-z-----Special Char and Blank Spaces
Min+1-- Pass
Max+1-- Fail
Min-1-- Fail



Test Case 2: Successful entry of password

BVA (Size)------------------------------------ECP (Type )
Min 4-- Pass----------------------------------Valid------Invalid
Max 8 --Pass---------------------------------------------A-Z
Max -1 -- Pass-------------------------------a-z---------Special Char and Blank Spaces
Min+1 -- Pass---------------------------------------------0-9
Max+1 --Fail
Min-1-- Fail

Test Case 3: Successful log in

User id------------------Password--------------------------- Criteria
Valid--------------------Valid---------------------------------Pass
Valid--------------------Invalid-------------------------------Fail
Invalid------------------Invalid-------------------------------Fail
Valid--------------------Blank--------------------------------Fail
Blank------------------- Valid---------------------------------Fail

UseCase 2
In a insurance application, user can apply for different types of insurances. When a user select type B insurance, system asks age to enter. Age value should be greter than 18 years and should be less than 60
Test case 1: Successful selection of type B Insurance
Test Case 2 : Successful focus to age when you select type B
Test Case 3: Successful entry of age value

BVA (Size)---------------------------------------------------ECP (Type)
Min 19 -- Pass------------------------------------------------Valid-----Invalid
Max 59 --Pass----------------------------------------------- 0-9------- A-Z
Max -1 -- Pass----------------------------------------------------------Special Char and Blank Spaces
Min+1 -- Pass------------------------------------------------ ----------a-z
Max+1-- Fail
Min-1 -- Fail

Usecase 3: In shopping application customer can try for purchase order creation. Application takes item no & qty. Item no allows alphanumeric from 4-6 charaters long and quantity allows upto 10 items to purchase. After filling item no & qty , our system returns price of one item & total amount

Test Case 1: Successful item no
BVA (Size) --------------------------------------------------ECP (Type )
Min 4 --Pass--------------------------------------------------Valid--------Invalid
Max 6 --Pass--------------------------------------------------0-9---------A-Z
Max -1-- Pass-------------------------------------------------a-z-------- Special Char and Blank Spaces
Min+1 -- Pass-------------------------------------------------A-Z
Max+1 -- Fail
Min-1 -- Fail

Test Case 2: Successful selection of Qty
BVA (Size)--------------------------------------------------ECP (Type )
Min 1 -- Pass--------------------------------------------------Valid--------Invalid
Max 10 -- Pass------------------------------------------------0-9----------A-Z
Max -1 -- Pass-------------------------------------------------------------Special Char and Blank Spaces
Min+1 -- Pass
Max+1 -- Fail
Min-1 -- Fail

Test case 3: Successful calculation
Total=price * qty

Usecase 4
In banking application user can dial bank using his person computer. In this process user can use 6 digit pwd & below fields.
Area code--3 digit no & allows blank
Prefix-- 3 digit no, not starts with 0 or 1
Suffix-- 6 digit & alphanumeric values
Commonds-- Deposit ,balance enquiry, mini statement ,bill pay
Test Case 1: Successful entry of password
BVA (Size) ECP (Type )
Min 6 --Pass Valid--------Invalid
Max 6 --Pass 0-9--------A-Z
Max -1 -- Fail-------------------------------------------------------------Special Char and Blank Spaces
Min+1 -- Fail ---------------------------------------------------a-z
Max+1 -- Fail
Min-1 -- Fail

Test Case 2: Successful area code
BVA (Size) ECP (Type )
Min 3 -- Pass Valid--------Invalid
Max 3 -- Pass 0-9----------A-Z
Max -1-- Fail Blank-------Special Char
Min+1 --Fail----------------------------------------------------------------a-z
Max+1 -- Fail
Min-1 --Fail

Test Case 3 : Successful prefix:
BVA (Size) ECP (Type )
Min 200 -- Pass Valid--------Invalid
Max 999 -- Pass 0-9----------A-Z
Max -1-- Pass-------------------------------------------------Special Char and Blank Spaces
Min+1 -- Pass-------------------------------------------------a-z
Max+1 -- Fail
Min-1 --Fail

Test Case 4: Successful suffix
BVA (Size) ECP (Type)
Min 6 -- Pass Valid----------Invalid
Max 6 -- Pass 0-9
Max -1 -- fail A-Z------------Special Char and Blank Spaces
Min+1 -- Fail-------------------------------------------------- a-z
Max+1 -- Fail
Min-1 --Fail

Testcase 5: Successful commands such as deposit, balance enquiry etc.,
Test Case 6: Successful dialing with valid values
Test Case 7: Unsuccessful dialing without filling all field values except area code
Test Case 8: Successful dialing with out filling area code

Test Case Format: During test design, test enggs are preparing test case documents in IEEE format.
1) Test Case ID: Unique name or number
2) Test Case Name: Name of the test condition
3) Feature to be tested: Module or feature or service or component
4) Test Suite ID: Batch name, in which this case is a member
5) Priority: Importance of test case
P0--- Basic Functionality
P1--- General functionality ( ex I/P domain, compatibility, error handling, intersystem testing etc.,)
6) Test Environment: Require H/W and S/W including testing tools
7) Test Effort (person / hr): Time to execute this case, ex 20 min
8) Test Duration: Date & Time
9) Test Setup: Necessary tasks to do before starts this case execution
10) Test Procedure *: Step by step procedure from base state to end state
Step No----Action----I/P Required----ExpectedResult---- Defect ID----Comments----Test Design
11) Test Case Pass or Fail Criteria : When this case is pass, when this is case is fail?
Note: In general test engg’s are preparing test case documents with step-by-step procedure only (i.e 10th field only)
Ex Prepare test case document for successful mail reply.
----Step No----Action------------IP Required--------------Expected
---------1.--------Log on to site----Valid UID and PWD---------Inbox page appear
---------2.--------Click inbox link--------------------------------Mail box appear
---------3.--------Select Received mail subject-----------------Mail message appear
---------4---------Click reply---------------------------------------Compose window appears with to Received mailed
---------5.----------Enter new message and click save-----------Ack from web server

2 Input Domain Based Test Case: Usecases are describing functionality in terms of inputs, flow and output. But usecases are not responsible to define size and type of input objects. Due to this reasons test engineers are reading LLD's also. (data model or ER diagrams). To steady data model test engineer follows below approach.
Step 1: Collect data models of responsible modules
Step 2: Study the data model to under every input attribute in terms of size , type and constraints
Step 3: Identify critical attributes, which are participating in data retrievals and data manipulation.

Ex:AC no----Account Name----Balance----Address
    ----------Critical----------------
                             ---------Non Critical----------
Step 4 : Identify non critical attributes, which are just input/ output type.
Step 5: Prepare data matrices for very input attribute in terms of BVA & ECP
Input Attribute-------------------------ECP-----------------------BVA
                                    Valid---------Invalid          Max-----------Min

Ex 1: From usecase a bank application allows a fixed deposit form. From the data model that form consists of below fields
Customer Name: Alphabets in lower case middle _
Amount : 1500 to 100000
Tenor : upto 12 months
Interest: Numeric with decimal

From this usecase, if the tenor is greater than 10 months our system allows interest also as greater than 10%. Prepare test case document from above scenario.

Test Case 1: Successful entry of customer name


Test Case 2: Successful entry of amount


Test Case 3: Successful entry of tenor


Test Case 4: Successful entry of input


Test Case 5: Successful fixed deposit with all valid values


Test Case 6: Un successful operation due to tenor is greater than 10 months and interest is less than 10%.


Test Case 7: Unsuccessful operation due to without filling all field values



3. User Interface based test case design: To conduct user interface testing, test engineers are preparing UI test cases depends on our organization, user interface rules, global UI conventions (Microsoft 6 rules) and interest of customer site people.
Example: 1) Spelling check
2) Graphic check
3) Meaningful error messages
4) Meangful help documents (Manual support testing)
5) Accuracy of data displayed
a.Amount----DOB
b.Amount----DOB
c.DOB--------dd/mm/yy
6) Accuracy of data in the database as a result of user input i)Form
ii)table
iii)Report
7) Accuracy of data in the data base as a result of external factors
Ex: Imported files
Test case selection review: After completion of all possible test cases writing, test lead and test engg are concentrating on test case selection review for completeness and correctness. In this review test lead apply coverage analysis on that cases
a) BR based
b) Usecase based
c) Data model based
d) UI based
e) TRM based
At the end of this review, TL creates Requirement Trace ability Matrix. This is the mapping between BRS and prepared test cases. This is also known as Requirement Validation Matrix. (RVM).

VII) Test Execution
After completion of all possible test cases writing for responsible modules and their review, testing team concentrate on test execution to detect defect in build.
1.Test Execution Levels
2) Test Execution vs Test Cases
Level -0 All P0
Level -1 All P0, P1 & P2 test cases as batches
Level -2 Selected P0, P1 & P2 test cases wrt modification
Level -3 Selected P0,P1 & P2 test cases wrt build
3) Build Version Control: Testing team receive build from development team through below process

From the above model, testing team receives build from development through “File Transfer Protocol”. To distinguish between old and modified builds, development use unique no version system. This system is understandable to test engineers. For this version controlling development, team people are using Visual SourceSafe.
4) Level -0: After receiving initial build from development team, testing team covers basic functionality of that build to estimate stability. During this testing, testing team applies below factors to check whether the build is stable for complete testing or not?
 Understandable
 Operatable
 Observable
 Consistency
 Simplicity
 Controllable
 Maintainable
 Automatable
These are Testability Factors to do Sanity testing.
From the above factors, Sanity testing is also known as Testability testing, BVT, Octagonal testing and other shake-ups are called smoke testing.
5) Test Harness (Ready for testing)
Test harness= Test Environment + Test Bed

6) Test Automation: After receiving stable build from development, testing team concentrate on test automation to create automated test script if possible.
From the above model test engg's are following selective automation for repeatable and critical test cases only
7) Level -1 (Comprehensive testing): After receiving stable build from development team and completion possible automation, testing team concentrate on test execution to detect defects. They execute tests as batches. Test batch is also known as test suite or test set. Every test batch consists of a set of dependent test cases. During this test case execution as manual or automated, test engineer's create "Test Log". It consists of 3 types of entries.
 Passed, all expected equal to actual
 Failed ,any one expected vary with actual
 Blocked, due to failing of parent test

Level -2 (Regression testing): During comprehensive test execution, test engg’s are reporting defects to development team. After bug resolving, testing team receives modified build. Before concentrating on remaining comprehensive testing, testing team
Re-execute their previous tests on that modified build to ensure bug fix work and possibility of side effects. This type of re- execution of tests is called regression testing.
Note: If development team release modified builds due to project requirement changes, test engineer executes all P0, P1 and carefully selected P2 test cases.