,
6 tweets,
1 min read
Read on Twitter
"We didn't think of that combination of inputs"
"We didn't foresee users clicking the 'submit" button twice"
"We didn't account for balances too big to fit in an int"
"We didn't envisage two processes accessing the same data in that order"
"We didn't foresee users clicking the 'submit" button twice"
"We didn't account for balances too big to fit in an int"
"We didn't envisage two processes accessing the same data in that order"
My reply: "What thought did you put into exploring the possibilities?" Did they do a truth table or a decision table? Did they sketch a state transition model or a response matrix? Did they use Venn diagrams to explore the entire input space? Did they visuallse concurrency?
Did they explore combinations and permutations of inputs/conditions?
Did they inspect the load-bearing code and ask "What could go wrong with this?"
Did they consider the UI/API and ask "What inputs does this allow?"
The answer is almost always "no" to *all* of those questions. Typically, teams do no test analysis at all. And that includes many teams with dedicated testers. It's a lost skillset.
