Welcome to Foxy-Tester.com the focalpoint for sharpening your test skills
This week I enjoyed my first TestBash in Brighton. There is so much to write about, including some amazing people I met there, not least Dorothy Graham #dorothygraham Test Automation specialist and author, but for now I just wanted to share the #testsphere cards info.
Here are a few links:
More to follow soon.
For starters….a simple example follows. Read the lyrics of the song, then return here to compare notes.
Remembering the song ‘Twelve Days of Christmas’ for more info please follow this Wikipedia song.
We’ll use this version…
On the twelfth day of Christmas,
my true love sent to me
Twelve drummers drumming,
Eleven pipers piping,
Ten lords a-leaping,
Nine ladies dancing,
Eight maids a-milking,
Seven swans a-swimming,
Six geese a-laying,
Five golden rings,
Four calling birds,
Three French hens,
Two turtle doves,
And a partridge in a pear tree!
The client tells us: ‘That’s what I want!’
Testers. This is your requirement. At first it might seem rather extravagant. The developer needs to deliver this pronto and to a fixed agreed budget. How can you help achieve this with maxing efficiency? What questions do you need answering?
So get to work on this right now. Christmas is just 3 months away and we have a deadline!
Q. Is this a serious request? A. Yes it’s a romantic gesture along with a real proposal.
Q. Yes, but it is an expensive one, how tight is the budget?
A. Let’s keep it real tight and to the letter.
Q. As the song is a round, are you sending the 1st item (partridge in a pear tree) on 25th, 1st and 2nd item on 26th, 1st, 2nd and 3rd item on 27th and so on?
A. Yes, but obviously assume she returns my gifts each day and that I resend those all the next day along with the next one on the list.
Q. Even the rings?
A. Ah yes, she’d probably keep the real ring, so we need a spare.
Q. Ah so on Day 1 you just send
And a partridge in a pear tree! And she returns it? On Day 2 you send Two turtle doves,
And the partridge in a pear tree! (The one you sent the day before?) etc… but what if she does not return them.
A. Trust me she will.
Q. Eight maids a-milking? What are they milking?
A. It’s just the way we say milk-maids but it makes sense that they have a stool to sit and pretend to milk otherwise we’d need 8 cows as well and that could get expensive.
Q. 5 Gold rings? You just need one real one? A. Ah yes, one can be real gold and the another 5 for show but still ‘gold’ and ‘rings’. – Olympic Rings perhaps.
Q. How big? A. Size J and the 5 would be about 10cm diameter each.
Q. If the drummer is drumming and pipers piping, it will be somewhat noisy unless they play something. What music should they play?
A. Little drummer boy of course.
Q. Lords leaping and Ladies dancing? They won’t come cheap – do they need to be titled?
A. No no. Of course not, that’s just their costume, this is all for show and effect, like a pantomime. Anyway Christmas is expensive enough these days and my fiancé-to-be is very frugal. So the proposal needs to be sincere but the rest is for fun only.
Q. So the birds? Are they real?
A. Well, the swans could be ballet dancers from swan lake.
Q. But do you need a lake? Do they actually need to be swimming?
A. No just making the actions of swimming and looking like swans.
Q. And the ‘Six geese a-laying,
Four calling birds,
Three French hens,
Two turtle doves,
And a partridge in a pear tree! ‘ are they to be fake too?
A. No they should all be real, I’m not a total cheapskate you know! But the pear tree should not be too big.
Q. How big?
A. No more than 1 metre, but it needs at least one real edible pear on it, just for show. How much will all this cost me exactly?
Etc, etc, etc …
Do you have some other question? If so please add them below.
So thankfully we established the requirements which turned out to be a lot cheaper than it seemed – with one ‘set’ of each item, despite the song repeating over 12 days.
You may have something different, but hopefully it’s getting closer.
Acceptance – Checklist / shopping list
In appropriate costume:
Dancers:
• Ten lords a-leaping (book for days 10,11 and 12)
• Nine ladies dancing (Days 9, 10, 11, 12)
Actors:
• Eight maids with milking stools (Days 8, 9, 10, 11, 12)
Ballet dancers:
• Seven ballet ‘swans’ ‘swimming’ as if in swan lake (Days 7, 8, 9, 10, 11, 12)
Musicians :playing Little Drummer boy.
• Twelve drummers drumming (book for Day 12 only)
• Eleven pipers piping (book for days 11 and 12)
Firstly, being a Tester is about developing a mindset that seeks to clarify everything and assume nothing that is not clearly stated. The main question types are ‘What?’ questions as these drill down to the next level to uncover and clarify gaps. ‘What?’ questions dig below the common language to describes actions or events that are to be added to the software to produce the desired expected outcomes.
‘When?’ questions also have their place, as do ‘Who?’ questions. Timing can be essential and often events are time-driven. Limitations and restrictions in permission determine who, as do key roles.
‘Why?’ questions are less obvious and yet delivering the software is very much hinged upon the ‘Why?’. The motivation behind the software change, is what drives the delivery.
Secondly, before any work begins on development of software the gaps and potential misunderstandings in a specification need to be brought to the forefront. Each sentence needs to be scrutinised to examine its clarity. What we think is clear to us may have a different meaning to someone else.
Each situation has a history too. So previous events and actions that are part of the current software (or expectations) also need to be considered. What a Tester does is take the language of ‘should’ and defines the ‘must’. The developer will decide how the action or event will result in the expected outcome. To the Tester this is usually an unknown quantity with an initial state, inputs and outputs. This describes the so called ‘black box’ as we don’t know what is inside or how it works. Although ‘White’ box is not really self-explanatory. Glass-box would be better.
Testing the fuzzy design plan that only exists as a description of what the software (or shopping list) should do or contain is the cheapest way to write software. To build it right first time some examples can help, but from the Tester can devise tests for the developer to include when checking their build and in their testing. Outline the road map for the testing to come and have the clarifications written into the specifications before the development starts.
As you can see, the Foxy-Tester mindset can be applied to any situation that needs clarification or has potential gaps or fuzziness even a bizarre Christmas shopping list.
Now take another look at Wikipedia Price and compare costs. We could easily have been way off base and delivered the wrong things.
I’ve sadly neglected this blog site for several weeks now. Everything started well, but then I got to thinking, thinking and more thinking. Then learning and understanding. To relaunch this blog, here’s the Foxy-Tester.com mission Statement:
Our mission is to be and nurture leading edge revolutionary and banner-waving ambitious advocates of BDD, specification by example and ‘shift-left’ testing. Our Passion (with a capital ‘P’) is to learn, re-learn and guide other wildly ambitious testers who have the same ambition and passion for the role. To make full-stack Automated Testing an imperative for all testers to get on the first rung of the ladder right now. To join with leading figures in Testing to make Testing a fully recognised indispensable technical role. To guide testers who want to keep ahead of trends to set the trends and make Testing and Software QA all it can be. To make it happen for themselves rather than wait for it to have happened everywhere else first.
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.
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.
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.
Here are some snaps from a recent trip to Valencia. How is the picture of these old cycles of relevance? I guess when you have seen as many testing cycles as I have, it’s exciting to see something new!
Welcome to the start of your journey towards becoming an extremely sly Foxy-Tester.
