Lab 7 - Software Validation & Verification Plan
You are already familiar with the requirements gathering and you also produced several use cases and a project plan. During this lab we will learn how our developed POS software system can be checked against its specifications (requirements). During this lab we will mostly cover the verification part.
Note: Difference between validation and verification:
* Validation: Are we building the right system?
* Verification: Are we building the system right?
Create a test plan for the verification of the POS application functional requirements (produced in the first lab). You can use a Google spreadsheet (optional) extending the project plan. You need to select at least 50 functional requirements for this task. The test plan should have the following:
- Functionality to be verified
- Assignee (for each requirement)
- Usage frequency of the functionality to be verified: low/average/high (for each requirement)
- Possible damage for business on failure: low/average/high (for each requirement)
- Priority: low/average/high (for each requirement)
- Estimated effort in person-hours (for each requirement)
Functionality to be verified is just a functional requirement. Assignee is one of your team members. Usage freguency is your estimate to the functionality usage rate. If it is used seldom, like a report in the end of the week, then it would have "low" usage frequency. If it is used frequently, like making an order, then it will have a "high" usage frequency.
The possible damage for the business on failure should show how critical this functionality is for the business process. If you cannot accept the payments then it obviously should be "high".
The priority is based on the usage frequency and possible damage for business estimates. If both are high then priority is high. If both are low then priority is also low. But if they are different you need to make decision yourself based on the requirement under consideration.
Estimated effort can be either numeric in person-hours or also defined by a class like low/medium/high. If you will use classes, then you need to define the numeric range in person-hours for each of the classes. The estimated effort includes test preparation (designing of the test cases), execution of the test case and reporting of the execution results. The estimated effort does not include debugging and problem correction.
We recommend to do the effort estimating after completion of task 2 (see below). Designing of the test cases will give you some experience about the amount of work involved and after task 2 it would be easier to return to task 1 and make effort estimates.
The real test plan would clearly state who, when, what and how is going to test. We cover most of these elements in different tasks. During this task we will cover "who" and "what". In the task 2 we cover "how". We will not cover "when".
Create at least 5 test cases for your functionality verification. These test cases should cover at least 5 non-trivial functional requirements. Your test cases should have at least the following elements:
- Test case ID
- Related requirement(s)
- Input that is used for the test to verify the functionality. Pay special attention to the borderline cases and exceptions.
- Steps performed during the verification process
- Expected results
You can change/improve your requirements to make them more suitable for this task.
Describe how you are planning to measure non-functional requirements for usability and performance. You need to pick 2 non-functional requirements related to usability and 2 related to performance (that is, 4 non-functional requirements in total). You need to offer concrete steps, methods and techniques to test each of the selected non-functional requirements. Make clear how you are going to ensure/guarantee their measurability in reality (ensure they are measurable).
All three tasks (test plan, test cases, usability and performance test process description) should be delivered via the GitHub wiki.
These quite general wiki articles should be considered as a starting point for your further research. There exists many guidlines and tools for the system verification, and you need to become familiar with that field. After this small homework we expect you to be familiar with the main tools and terms used for the V&V and software tesing in general.
During the evaluation you should be able to describe at least major terms like:
- Load Testing
- Usability Testing
- Testing levels (check this)
- Test plan
- Verification and Validation procedures
- Software testing in general - http://en.wikipedia.org/wiki/Software_testing
- Test plan - http://en.wikipedia.org/wiki/Test_plan
- Test case - http://en.wikipedia.org/wiki/Test_case
- Usability testing - http://en.wikipedia.org/wiki/Usability_testing
- Performance testing - http://en.wikipedia.org/wiki/Load_testing