Project 1 - V&V SW Analysis - I
5 steps to create (and execute) a test plan for your new product or feature
1. Analyze the product or feature you’re testing
you need to have a deep understanding of the product or feature before you can start creating a test plan for it. For example, let’s say you’ve just gone through a website redesign and want to test it before launch.
2. Design the test strategies (and approach) you’re going to use
Next, it’s time to decide the scope of your test plan. What’s included in the scope of your testing will depend on a number of factors beyond just the product or feature. You need to dig in and think about:
- Customer requirement: What are your users going to use most?
- Budget and timeline: How much time and resources do you have to complete testing?
- Product specs: What are the most important parts of this feature that need to be tested?
- Team abilities: Do you have the technical expertise you need to complete each test?
- Unit testing: Test the smallest piece of software or a specific feature.
- API testing: Test the API created for the application in multiple scenarios.
- Integration testing: Test multiple software modules or features as a group.
- System testing: Test the entire integrated system against its requirements.
- Install testing: Test the install/uninstall process your customers will go through.
- Compatibility testing: Test your software on different hardware, operating systems, and environments.
- Load and stress testing: Test your software performance as the workload increases
3. Define the test objectives and pass/fail criteria
- Response time: Total time to send a request and get a response.
- Wait time: How long it takes to receive the first byte after a request is sent.
- Average load time: Average amount of time it takes to deliver every request.
- Peak response time: The longest amount of time it takes to fulfill a request.
- Requests per second: How many requests can be handled.
- Transactions passed/failed: The total number of successful or unsuccessful requests.
- Memory utilization: How much memory is needed to process the request.
4. Plan the test environment
The results of your test plan will depend as much on the feature you’re testing as the environment you’re testing it in. As part of the scope, you need to determine what hardware, software, operating system, and device combinations you’re going to test.
5. Execute your test plan and track progress in your project management tool
Once your test plan is in place, there’s a specific process you need to follow. Think of this as the Software Testing Life Cycle (STLC).
Software Development Life Cycle, the STLC follows each phase of testing and usually looks something like this:
- Requirements/Design review
- Test planning
- Test designing
- Test environment setup
- Test execution
- Test reporting
A Test Case consists of the following fields:
- Test Case ID: This is a unique ID for a test case. Conventions are followed here. For example – TC_UI_1 indicates “User Interface Test Case #1”.
- Test Priority: Test priority can be low, medium, or high depending on the business requirements. This comes in handy while executing the tests.
- Module Name: The name of the module or sub-module being tested is specified here.
- Test Designed by: The name of the tester who designed the test.
- Test Designed date: The date when the test was designed.
- Test Executed by: The name of the tester who executed the test. This field is filled after the test execution.
- Test Execution date: The date when the test was executed.
- Test Title/Name: Test case title/name
- Test Summary/Description: Test objective
- Pre-condition: Any requirement that must be fulfilled before this test case is executed. It’s good to list all the pre-conditions to execute this test case successfully.
- Dependencies: Identify and determine dependencies on other test cases or requirements
- Test Steps: List all the test steps with details and in the order of test execution.
- Test Data: Input for the test case is defined here. You can provide different sets of data with the exact values to be used as input.
- Expected Result: Mention the expected result, including messages or errors that should appear on the screen.
- Post-Condition: State of the system after running this test case
- Actual Result: Actual result obtained after the test case execution is filled here.
- Status (Pass/Fail): If the actual result is not as expected, mark this field as Fail; otherwise, mark it as Pass.
- Notes/Questions/Comments: Special conditions to support the above test fields or any questions related to the test case can be mentioned here.
Test plan to test features of a new mobile phone:-
if( product owner long press the power button)
{
open the company logo at centre;
}
else if(customer press the power button)
{
open the apps in grid;
}
else if( product owner power on the phone)
{
shows call the phone icon on first position at bottom;
}
else if(product owner power on the phone)
{
shows Dictionary icon on second position at bottom;
}
else if( product owner click on call the phone icon)
{
contacts appears in alphabetical order;
}
else if(product owner click on Dictionary icon)
{
search bar appears at centre;
}
else if(product owner long press power on button)
{
displays Good-Bye and gets switched off;
}
else if(product owners phone font)
{
always in calibri with size of 12;
}
else if(customer requirement touch responsive)
{
reflects on touch;
}
else ( customer requirement no hard buttons)
{
touch screen sensitive;
}