Table of Contents
There is no formal definition of what experience based testing in Agile-oriented projects is but to put it in simple terms, it’s testing a product using your previous experience. As the name implies is a testing activity performed by the QA based on the experience gained through the years on each project iteration. Verification of the quality of the product using the experience from previous projects, approaches, business domains, organizations, etc.
Since it is done often due to the Agile project nature, the skill from the engineer can be leveraged to the benefit of the project and fast feedback can be extracted. Although some engineers may have the needed experience to perform this type of testing, combining it with a proper testing strategy and plan would result in an effective test outcome.
One of the most important experience based testing techniques is Exploratory Testing which solely focuses on testing the product with no documentation or test plan up ahead, just the engineer’s experience. Other useful techniques are:
- Error Guessing
- Checklist Based Testing
When to use Experience Based Testing?
Usually, when the project has no or less documentation, not enough clarification about customer requirements, no testing strategy defined yet, limited product knowledge, not enough time for planning, analyzing, and defining test priorities, the QA engineer is left out on his own experience to initially test the product. The more experience the engineer has the easier it would be for him to verify the quality, report bugs, and provide a final verdict on the current state of the system.
Combining Experience Based Testing with Automated testing
When determining the features and functionalities for a product, it’s assumable that some risks should be set for each of them and that’s usually done in the risk analysis. Whether it will be high, medium or low, different testing activities need to have a risk given.
Let’s take a look at the example below for a system that should be in the later stages of development and that it should behave exactly like the requirements defined:
|Risk||Experience Testing||Automation Testing|
In a situation when we have a Low risk in the system it is highly recommended(++) that we perform experience based testing and it is recommended(+) that we already have some automation tests in place. Medium or high risks results with avoiding(-) experience based testing and focusing on automation testing that will give us quick feedback on the overall quality of the product.
Test document(charter) and result report
In the creation of the test charter that will eventually help us to perform experience based testing on the product, some questions need to be answered like:
- What are the main users in this feature?
- What’s the main functioanlity of the feature?
- What and how many actions one user can perform?
- Do we need any special setup prior to this?
- What is the objective of the user related to teh feature?
- Are there any additional data the user will need as an input?
The document should not be too small or too big since the testing session lasts between 60- 120 minutes. It should focus on the problem ahead and the area of testing. A charter can be created using spreadsheets, documents, mind mappings, etc. The goal is to document the findings and discuss future product quality improvements. Any error found must be documented as well.
Any additional tool like video evidence or screenshots can help the test session as well as the outcome of the execution. Expected vs actual results should also be documented to further compare and improve the product. There are no specific metrics on the testing itself, it’s just using the experience that you have in combination with a test charter to guide your testing and eventually summarize all the findings and errors in one place. Suggestions for improvements based on the summarization should come up as a result as well.
Share This Post