So, I recently missed a bug that slipped into production - we had made a change to the validation on a web page and it caused an adverse knock-on affect to the validation behaviour. When I reviewed my test plan and regression pack I realised that I didnāt actually have any test cases in places that could have caught this particular bug, which got me thinking:
How about in addition to my high level regression test cases I also come up with āmini regressionā cases for each area, for example: validation - I would have an exhaustive list of things to check for this area, including:
ā¢ Special characters
ā¢ Long string
ā¢ Empty
ā¢ Spaces
ā¢ Numeric/alphanumeric
ā¢ Numeric variables (commas, decimal places, leading zeros, negative numbers, )
ā¢ Trigger validation by leaving fields blank ā when completing fields ensure that validation messages disappear
Before I go down this path, does this seem like a good idea or is there a better way I could do this?
I am currently trying to think of as many key areas for testing websites as possible. At the moment Iāve got:
Iām sure there will be lots more! The idea would be to maintain this regression pack and only pull in the relevant ones I require for each project, eg: if we have changed the CSS then I would run that regression.
Iāll translate what youāre doing into terms I understand. It sounds like youāre building risk catalogues so that you can more effectively tackle change risk. This is a sensible thing to do, and is a part of outside-in risk analysis.
Donāt lose sight of the purpose of your particular website. Test against risks that are informed by your site and its needs. Maybe it simply has to be performant, or must be secure, or has to be well formatted, or maybe you require maximum uptime. Beginning with the details and establishing risks is inside-out risk analysis.
Beware of premature formalization. Writing everything down can be a costly burden. Being general allows you to make your coverage more fuzzy, so you donāt have well-defined holes in it. A ātest caseā such as āsecurityā covers a lot more than āwhen you click the log on button and the username field has a valid username thatās in the database with a password in the password field that has an encrypted version in the database against that username then the user is given a tokenā¦ā. Checklists are a great way to fill in the gaps - things that are sufficient risks to warrant repeating actions. Youāre not aiming for perfect, youāre aiming for good enough - and this partly means prioritizing risks and properly using resources. A list of risks is a great way to start - I use the HTSM a lot to help me with this during testing.
Test insane is a place where testers can share mindmaps which they think are useful. I have found it a great place to get ideas which I can wrap around my tests to see where I can improve them. Donāt forget to look for other, potentially more useful mind mapsā¦ I just linked the first one I found which might be useful.
(I am not involved with TI, I just find it a great exploratory testing tool)