Test Plan vs Test Strategy vs Test Approach

                Test Plan vs Test Strategy vs Test Approach 

                                                                Test Plan

                                                                       |

                                                              Test Strategy

                                                                       |

                                                             Test Approach

    The above flow diagram illustrates that First Test Plan is created which includes test strategy &

test Strategy includes the test Approach

Theory Says – 

Test Plan - “A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort” 
The purpose of the Master Test Plan, as stated by the IEEE Std 829 is to provide an overall test planning and test management document for multiple levels of test (either within one project or across multiple projects). 
You can see the IEEE standard test plan is here. 

Test Strategy – Test Strategy or Test Approach is a set of guide lines that describes test design. Test strategy says - How testing is going to be performed? What will be the test architecture? 
Test Strategy can be at two levels – Company/Organization Level and Project Level. For e,g, If company is product based, then there can be a general test strategy for testing their software products. Same strategy can be implemented (with/without  some modifications) at project level whenever a new project comes. 
Might be these are OK for beginners, but actually this is not enough. 

Test approach -- "It's the way how do you do your testing." Test Approach is created by the individual tester/TestLead according to the module or application means his own views or approaches for that Module.

Example: Test plan gives the information of who is going to test at what time. For example: Module 1 is going to be tested by “X tester”. If tester Y replaces X for some reason, the test plan has to be updated.

On the contrary, test strategy is going to have details like – “Individual modules are to be tested by test team members & there should be more than 85% automation for each module“ In this case, it does not matter who is testing it- so it’s generic and the change in the team member does not have to be updated, keeping it static.

& test approach will be decided the by the test Lead/tester that which tool will be used for automation . Ex. for UI whether to use selenium or QTP... for API whether to use the restAssuerd or SOAPUI

From Testing School Basics : Test Plan

Test Plan

Test plan is in high demand. Ya it should be! Test plan reflects your entire project testing schedule and approach. This article is in response to those who have demanded sample test plan.

Making Test Plan has multiple benefits

• Test Plan helps us determine the effort needed to validate the quality of the application  under test
• Help people outside the test team such as developers, business managers, customers understand the details of testing.
• Test Plan guides our thinking. It is like a rule book, which needs to be followed.
• Important aspects like test estimation, test scope, test strategy are documented in Test Plan, so it can be reviewed by Management Team and re-used for other projects.

As per IEEE 829  test plan Consists of 

Test Plan Identifiers:

S.No.	Parameter	Description
1.	Test plan identifier	Unique identifying reference.
2.	Introduction	A brief introduction about the project and to the document.
3.	Test items	A test item is a software item that is the application under test.
4.	Features to be tested	A feature that needs to tested on the testware.
5.	Features not to be tested	Identify the features and the reasons for not including as part of testing.
6.	Approach	Details about the overall approach to testing.
7.	Item pass/fail criteria	Documented whether a software item has passed or failed its test.
8.	Test deliverables	The deliverables that are delivered as part of the testing process,such as test plans, test specifications and test summary reports.
9.	Testing tasks	All tasks for planning and executing the testing.
10.	Environmental needs	Defining the environmental requirements such as hardware, software, OS, network configurations, tools required.
11.	Responsibilities	Lists the roles and responsibilities of the team members.
12.	Staffing and training needs	Captures the actual staffing requirements and any specific skills and training requirements.
13.	Schedule	States the important project delivery dates and key milestones.
14.	Risks and Mitigation	High-level project risks and assumptions and a mitigating plan for each identified risk.
15.	Approvals	Captures all approvers of the document, their titles and the sign off date.

Decision table vs State transition

Decision table vs State transition

State Transition:

State or behavior of a system change upon interaction with other system/object, hence testing this transition between states of a system or objects is State Transition.

Ex :
Remember the state transition diagrams or sequence diagrams of UML.These two diagrams which are drafted along the HLD are to be referred to identify the objects, theirs states and transitions.
ATM money withdrawal :
User (Object) is validated for authorization and authentication. Change in state i.e. (inactive user is been activated).
check whether the user is activated or not upon valid and invalid A & A.
Advantages:
Very easy way to draft the test cases.
Transition issues which influence the business can be identified.

Disadvantages:
limited impact on business rules and test conditions.
Requires UML to be included in design phase i.e. in HLD.

Decision Tables:

Drafting a table which highlights the conditions between two objects where rows are denoted by one object and columns by another.

Ex:
Z = X + Y, X is cost price of a certain product, Y is the profit. Z is the selling price
Decision Table will be
Test Condition: sum of CP and Profit shall result as SP.
Row = X, Column = Y. both positive and negative permutations are to be considered.
Thus decision table is to be drafted.

Advantages:
In order to optimize the number of test cases required to ensure optimal test coverage these two design techniques are helpful.
Cover both positive and negative aspects of the test conditions.
Objects are tested, hence functionality i.e. behavior can be defect free.
Disadvantages:
Requires UML to be included in design phase i.e. in HLD.
Is not easy to implement initially.

Agile Test Design techniques

When you start your project, in the initial phase only you need to decide your Test Design technique
Based on my experience , I categorized them as

1) Dynamic Test Design techniques

•   Structured Based (White box)
•   Specification Based (Black box) 
•   Experience Based ( It depends how much experience you have & how well you can use that) 

2) Static Test Design techniques

• Informal Reviews
• Walkthroughs
• Static Analysis
• Technical Reviews
• Inspection

Equivalence Class Partitioning vs Boundary value analysis

Equivalence Partitioning/Equivalence Class Partitioning
========================================
Test cases for input box accepting numbers between 1 and 1000 using Equivalence Partitioning:
1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid test case. If you select other values between 1 and 1000 then result is going to be same. So one test case for valid input data should be sufficient....... TC1 : 5

2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case..... TC2: -5

3) Input data with any value greater than 1000 to represent third invalid input class.  TC3:  1001

Boundary value analysis:
==================
Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis:
1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our case.

2) Test data with values just beyond the extreme edges of input domains i.e. values 0 and 1001.


Example
========
As an example, consider a printer that has an input option of the number of copies to be made, from 1 to 99. To apply boundary value analysis, we will take the minimum and maximum (boundary) values from the valid partition (1 and 99 in this case) together with the first or last value respectively in each of the invalid partitions adjacent to the valid partition (0 and 100 in this case). In this example we would have three equivalence partitioning tests (one from each of the three partitions) and four boundary value tests. Consider the bank system described in the previous section in equivalence partitioning.



One more Example
=================
Equivalence Partitioning: (EQP)

It is a Black Box Testing Technique that divides the input domain into classes of data from which test cases can be derived.

For example:

If we want to test a field which accepts values from 1 to 9, we will write test cases with the following test data.
1. Test case with test data less than 1
2. Test case with test data greater than 9
3. Test case with test data between 1 and 9

Boundary Value Analysis: (BVA)
This is also a Black Box Testing Technique which concentrates on the Corner cases or the boundaries of the input domain rather than its center

For example If we want to test a field from 1 to 9 boundary values will be 0,1,2,and 8,9,10

The left hand value is called the lower boundary ie 1 here in this example and the Right side value 9 is called the Upper boundary and hence the selection of values is 
a. Upper boundaries +1,-1
b. Lower boundaries +1,-1