Testers are often told that they should shift testing upstream and test early, so that bugs are found before code is written. My MoT article “Shifting software testing left with operational definitions” shows how operational definitions can help testers do that.
An operational definition is a procedure that translates “a concept into a precise measurement.” Testers can use operational definitions to test how code is specified and test the specifications they have been given. This way, testers shift testing upstream and find bugs before code is written.
What You’ll Learn:
Reasons for shifting your testing upstream
A method to shift your testing upstream
A way to question specifications for work
What an operational definition is
How operational definitions can be used to help testers
After reading, share your thoughts:
How do you check whether requirements are clear enough to test?
Have you ever used operational definitions to help you test earlier? What happened?
What questions could operational definitions help you ask in planning meetings?
Can you see yourself using operational definitions in your testing after reading this, and where would you start?
I have certainly found operational definitions useful for moving testing upstream. By setting requirements in terms that are clear and measurable, I was able to run tests early and catch issues before they went into code.
In one project, we were given a rather vague user story: something to the effect of “The app should be easy to use.” Employing operational definitions, I was able to further carve that out into something more concrete: “The app should allow users to log in within 3 seconds” and “The app should display user data within 5 seconds after login.” These requirements could be tested much easier even before development started, and thus we caught UI performance issues fairly early.
I always ask, “Can we define measurable criteria for success?” whenever trying to determine if requirements are clear enough for testing. If the answer is no, then alarm bells should start ringing. Operational definitions help me ask, “What does user-friendly mean, exactly?” or “How do we define secure in this context?” Those questions are typically discussed during planning.
Having gone through the operational definitions, I can surely see myself putting them to greater use. I would initially review the specifications I receive from the customer to check if they are detailed, making their criteria subject to testing. Making sure that this happens earlier can save misunderstandings and costly rework in the later stages of the development cycle.