Five-Fold Testing System — #3: Potential Problems
Mo’ Complexity, Mo’ Problems, and the Power of “Oh Really?”
Talking to a friend recently who was having difficulty keeping conversations going, I tried to simplify the situation somewhat by passing on something I had once heard, ‘whenever they say something,’ I offered, “all you need to do is pick up on 1 word from that sentence, and use that word to formulate your next sentence, that way you’ll never run out of things to say.” For example, if someones says to you, ‘I didn’t get much sleep yesterday,’ then you grab the operative word/concept (sleep) and either ask them a follow-up question about their sleep, or talk about your own sleep, or just simply say absolutely anything related to sleep!
Testing against complex requirements can be a little like this too…
While helping the newest member of our testing team scope out their first ticket this morning, we took a look at the very first requirement...
REQUIREMENT # 1: The “Show Deleted People” button should no longer open a pop-up, but instead display rows for all the deleted people on that specific site. This feature is still restricted to role-A & role-C users.
Just like the conversation-method, all we do here is keep an eye out for key words, concepts, actions. But first, and even more literally, we can literally take every single assertion that is made here (there’s quite a few!) and insert that skeptical Bruce Lee .GIF (or just put a question mark) at the end of each one. “So, this button is no longer going to open a pop-up, you say? Oh really?!?” Well then, dear requirement-writer, you have just unwittingly given me my first test-case, which is:
- Click ‘Deleted People’ button — Verify that the pop-up no longer opens
Obviously we can go through all of the requirements this way. Once a tester begins questioning the claims made, interesting (less literal) ways to test that claim will usually suggest themselves. For example, we may know that we’re going to test that the pop-up no longer opens, but how we’re going to do that could result in 3 or 4 different test-cases. So don’t feel bad, you’re not just recycling requirements into test-cases, but rather, using the requirements as mental ‘jump-off points’ for more lateral, interesting test-cases.
Expecting Problems / Seeking Problems & Scope
Good testers, just like good journalists, always have healthy skepticism about every claim that is being made (i.e. “Oh really?”). If the claim holds up to scrutiny, then great, it was solid. If the claim falls down at the first sign of resistance, then perhaps it should be looked at again. Expecting problems is smart (and ultimately, it also reflects well on us as thorough software testers, which is a pretty nice side effect).
Seeking problems is a slightly different proposition. How far do we prod and poke at something before we’re willing to say it’s okay/done? Playing around with SQL injections and query strings, or doing strange key-combinations on your keyboard may help you find a cool bug now and again, indeed, this sort of “exciting” testing is what often gets the most attention when it comes to testing (a reactionary move, perhaps, to counter the erroneous notion that testing is a dull, boring activity!). Nonetheless, we’re left with an important question how much is too much?
Here’s a simple offering: most testers work with software that we know relatively well, in teams with known deadlines, in companies with somewhat known priorities, with developers and product owners who’s weaknesses and strengths (that is to say style) we have become accustomed to. In other words, if we simply let context be our guide for what’s in testing-scope, we will find that many of the blueprints are all around us (and already set).
TAKE AWAYS
Keep a lookout for complexity. There’s a beautiful term in agile software development, and it’s called MVP (“minimum viable product”) — it is preached religiously by good developers and anyone working in an agile team, and it applies to testing too. An MVP is essentially the smallest do-able piece/chunk of functionality of any product you are building, so if you are making an e-commerce website, your MVP may be a single working home page, or a simple shopping cart — which you would then add more functionality (complexity) to over time. MVP forces you to think about doing things one step at a time, and for testers, this makes for more tangible work, and yes, more rewarding workdays and jobs/careers in general.
The point is, at DealerOn, the specific testing we do is sometimes left to the discretion of the testers. I don’t micro-manage, and while Developers will make helpful suggestions, or field questions, they won’t dictate the testing either. That’s a long way of saying, it’s up to us. And if that’s the case, it’s important that we decide to NOT complicate our testing. Perhaps more interestingly, don’t allow the complexity in badly designed software or requirements to come to you without pushing back. If and when you feel that requirements are getting too complex (i.e. 5 separate things being stuffed into one bullet point, it happens!) — then politely ask the writer if these things can be broken down. Doing so may just make you the superhero in the room.
On a related note — never forget this: a team member’s reticence to ask questions is what directly causes bad software and potentially bugs. Your job in this case is to not be them. Speak up early, ask your questions (concisely), use consistent terms (i.e. call things by the same name that others call it), but above all, do speak up.
Be skeptical about claims. Get creative and think up scenarios in which this new thing might not work. But contain your imaginings within test cases, as soon as you think of them, get them all down (don’t think you’ll remember, you won’t!) Doing so also ensures you won’t spend an inordinate amount of time writing silly (needless) tests; there’s something about seeing your list getting larger that often causes us to instinctively ask ourselves, “Is that enough?” This can be a really useful question to ask yourself if you’re a practical tester working with a team and to agreed upon deadlines.
KEEP GOING!
Well, we’ve just passed the halfway point of our review of the Five-Fold Testing System, from the perspective of DealerOn’s always-growing, always-learning Dev-QA team. Check back in shortly for the next article in the series, and please check out all of our other articles (written by developers, designers and everyone in between) if you want to get an idea of the innovative and exciting work that’s happening at DealerOn.
