Month: July 2017

#TesterSkills

Newbie Tester? Enquirer within upon Everything #NewbieTester

FoxyTester

Are you new to testing? So new you are struggling with the terminology and don’t know where to start. So far all you know is that there’s more to it than just ‘playing’ with the software. In fact you may be so new you’ve not started testing yet. For you it’s a dream job that means you’d get to try out cool new stuff. Foxy-Tester is here for you.

What does a Tester do exactly? 

Ahem!

Well it depends.

There are two schools of software development. Just like in politics we have a Left and a Right. 

On the Right we have Old School where everything is planned and designed ahead of time, and a date chosen to release the software. Then it seems like a competition where the developers deliver too soon and you find so many bugs you wonder if they even tried. But at least they left you with time to test. Alternatively Developers can take so long you have almost no time to test. Again bugs are found in test, but it all seems a bit manic. This approach is called Waterfall. This suggests a process that trickles down where important decisions are made early on in the process. But the tester’s role is simply one of verifying that the software delivered meets the specified requirements. 

On the Left we have the shiny new approach called Agile. A list of work is made and divided up into small features. Principles can be adopted or ignored, but are often not fully understood by all. Development is chopped up and delivered in ‘Sprints’. Developers and Testers get a chance to say that each Feature will take this long in comparison with some arbitrary Fibonacci scale. Over a series of sprints the lessons learned make the estimating easier to get right. Testers and Developers become the masters of their own fate.

In the Waterfall situation, the Tester is either given the Specifications or Requirements as a large document outlining the rules and features that the software being developed is expected to include. If you are lucky, you have time to plan and write tests before you get the software. Unlucky? You have to wing it until you find your first Showstopper bug. Something that makes everything you just tested obsolete and you can do no more testing without the fix. This buys you the time you need to be better prepared for the next wave (or Test Cycle). As a cool tip, where you found the bug is a good place to dig deeper. 

Agile leaves you no place to hide, but at least you had a shot at guessing how long the testing would take up front. At least you have a nice little feature to test then move on to the next. Ok. The picture is not quite that pretty. You still get bugs, cycles and ‘wash, rinse, repeat’. Eventually though the small pieces of work stack up and progress is tracked. You have a chance to say how it all went and what could be done better next time. Where the Foxy-Tester is recognised as a valuable member of the team, the whole process is collaborative. Things gradually evolve.

In the next #NewbieTester post: I’ll explain What is testing exactly? and as a Newbie Tester / Foxy-Tester-in-the-making What you’ll need to focus on daily.

#MindMapping, #TesterSkills, #WritingTests

Test Analysis vs Counselling

FoxyTester

The process of understanding requirements, and subsequently confirming understanding by writing the tests, is one that mirrors the counselling process.

The counsellor, much like the Tester, builds a relationship with the ‘client’ (who may be a single user or group of users, stakeholders or business analysts) and together they assess the problem. The aim then is to set goals or targets for change and to define what MUST happen as a result of one specific ACTION or EVENT. For the Tester these goals form the requirements. Usually the testing starts with the written requirements, but these may be in the process of being clarified, expanded upon or finalised, or as often happens when you get them they are already signed off.

In the process of analysis, each requirement is broken down into a series of simple statements that explicitly define what the resulting software MUST do in response to a specific event or action by the user. The job of the Tester is to ensure that the software adheres to these rules [but also continues to adhere to existing rules without conflict]. The Tester also helps discover situations where the software MUST adhere to the converse rule or variations of the rule, by considering the exceptions to the rule. Each component of a requirement is essentially a statement with a ‘MUST‘ at the centre of it. Each test for that MUST is a statement that begins ‘ENSURE that…’ where the rules are applied appropriately for precise situations, or a variety of cases, and always applied in a defined order.

Intervention by the Foxy Tester and the Counsellor is wielded in the form of insightful questions that help reveal the possible scenarios or ‘Ah-ha’ moments. Here the Tester must think laterally and ask ‘WHAT IF?’ this or what if that. Questions that challenge every aspect of the requirement. With the help of the users the Tester can outline the types of scenarios to consider. A Tester must wear every kind of hat, in consideration of every viewpoint he can think of. He/she must consider the current situations that may exist and ask: How will this or that situation, along with any existing data, be impacted by the proposed requirements? The Tester with the user’s help then explores how each scenario MUST be responded to by the EVENT or user ACTION. A counsellor may take a more challenging approach dependent upon the level of resistance to change and severity of the problem.

img_0123
Source: Hackney & Cormier (1987) Counselling strategies and interventions

For the Tester, every ‘MUST’ within a requirement can yield one or perhaps many ‘ENSURE’ statements that outline the tests. For each test the Tester considers the pre-existing state or states. The state defines what must exist or have already happened prior to the specified test action or event. This is the ‘GIVEN’. Although it’s not always ‘a given’. Here again there may be many variations to consider. The GIVEN can include any complicated scenario that can pre-exist: that CAN, MUST or possibly SHOULD NOT permit the user ACTION or EVENT when under scrutiny of the test. Although the number of combinations may seem endless, they can be grouped into CLASSES that are similar enough to be considered EQUIVALENT.

Finally, reviewing the tests, and running them against the developed software mirrors the counsellor ‘s Evaluation, whilst the resulting outcomes is Referral and Termination. Whether the termination results in waiting for a bug fix before repeating tests, or confirmation that the Tester has ENSURED that the required MUSTS are correctly applied. For the counsellor and the Tester the outcome may also be one of, ‘wash, rinse, repeat ‘ until done.