continued from Part 1
Right that’s better, refuelled and ready to go for the pre lunch session of talks!
Katrina, all the way from NZ! Wow that’s a long way, is here to talk to us about pair testing, something I very much believe in and have seen work to very good effect, but something that not many testers do.
Cool, experiential report and she starts with “once upon a time…”, I like these types of talks, they are based on reality and truth and I find them easier to relate to.
Katrina faced a problem where testers were in their own bubbles of isolation, with little collaboration. Not knowing where to start addressing this, she started investigating pairing. Most resources about pairing are developer related.
She ran an introduction workshop to pairing which started with the communication task similar to the product owner/developer game, using dominoes. Pairing was pitched as an experiment, and planned out who pairs with who, and when. Often this more planned approach is needed to start with to encourage people to do it without the overhead of working out who to pair with, on what and when.
The sessions consisted of : introduction, native testing, visitor testing, debrief – emphasis on communication, questions, hands on. Sounds really great! They had a retro at the end of the first month and the general feeling was good. Katrina paid attention to the influencers when deciding on the pairings, giving them partners who would likely give them a good experience, to then help influence others. Smart!
Consequences were a greater visibility of skills, and knowledge, plus bring fresh thinking, a new pair of eyes to the party. Other feedback was that time was an issue, session were too long and too frequent. Sessions were changed to fort nightly (rather than weekly), but the length of session remained the same,… Perhaps the session was not consisting of native and visitor testing therefore not taking long enough.
After the second month, they had another retro and 100% wanted to continue doing pairing! Great result!!!! People were making fewer assumptions and learning how to ask more questions. This is a consequence of being able to practice in a safe environment and regularly. They also gained a wider appreciation of other parts of the system, leading to better planning and collaboration for test tools development.
The pairing approach filtered through to devs and other parts of the business, through observing the testers doing it. I’ve found that encouraging through doing and is a very powerful change management tool.
The questions asked at the end focussed on reluctance to allow work off-project, and the the point was made that it is proven to be efficient and effective to pair.
Talk 4 – Model fatigue and how to break it – John Stevenson
John Stevenson just woke us all up with some techno with the slides showing many models, testing mnemonics…
He talks about just blindingly using test models can be counter productive, they become stale. Why are we not changing the test models depending on your context? Call out to James Lyndsay, “the importance of diversity”. Testers should be the disruptive element on a project, asking the questions no one else is, challenge.
“Failure is success if we learn from it” – if things don’t change and continue as normal, then we haven’t learnt from our failures. Mnemonic SCAMPER, he talks about the ‘enlarge’ part where he used the touring model FCC CUTS VIDS. They enlarged the tour, to be more useful within their context.
Use existing models in different contexts, eg HTSM for automation, reword it, adapt it. By doing this, they started finding more bugs, some of which were already live!
Short and sweet talk, but done intentionally to invite more questions and discussion, nice!
How to change the ‘boilerplate’, use tools to encourage creativeness to adapt them. One of the problems is the heuristics (which should be adapted to context) are abused and used as boilerplate without thinking about whether they really fit and work.
Another question was how to start using models… Answer JDI… Just do it. It reminds me of the phrase, it’s better to seek forgiveness than seek permission.
Testers are creative people but it’s not always recognised both within our community and outside.
When is it time to start challenging the model you’re using? What are the smells? – just be divergent, think outside the box, challenge what you’re doing, inspect and adapt!
Talk 5 – Accepting ignorance – the force of a good tester – Patrick Prill
Next talk is by Patrick Prill…
Michael boltons webinar on regression testing introduced 4 types which opened his eyes to a wider world of testing.
He challenges understanding of well known terms, integration testing, test case, quality, testing, agile … Do we know what these terms mean? Are they agreed within your team, wider team? This is something I have encountered so many time, an something we are wrestling with at the moment. Even if you have a glossary or dictionary there is no guarantee everyone will use it!
Ignorance, definition: lack of knowledge or information… He expands the definition to specify definitions of each bit specifically for testing “To be aware that you have insufficient facts, skills or understanding about a topic and remain curious to constantly improve and further discover what your don’t know”. Feels like he’s heading to the orders of ignorance, something that is very useful to understand.
The stuff you know can be defined by the DIKW pyramid. (Top down) wisdom, knowledge, information, data.
Ignorance in testing – it’s everywhere, and we aim to be aware of what we don’t know, this should be manifested by Risk assessments, test planning, evolving test charters, deep testing, test reporting. The latter is an account of what we tested (what we know) and what we didn’t test (the things we don’t know). The stuff we didn’t test is arguably the most important part of that report as it may help drive further work, further testing.
Learning and skills improvement are another area where ignorance plays a big part. How much do you really know?
He goes on to explain how while you may be aware of what you don’t know, be aware of other who either know more or know different stuff. To be aware of the borders of your knowledge, and what you want or need to learn or improve is a very powerful position to be in.
I really relate to this talk. 5 years ago I was ignorant to the testing community, I spent 15 years as a tester in my bubble, and thought I learnt everything that I needed to know… Agile Testing Days opened my eyes and blew my mind. Now I’m more aware of what I don’t know, how I can help others, and which others can help me…
<rumble> … Must be lunch time!
I escaped the hubbub and got some fresh air for lunch before taking part in the latest “testing in the pub” with Dan ashby and Steven janaway hosting, and Paul & zac from the app business.
Talk 6 – Test/QA a gate keeper’s experience – Michael Wansley
Michael Wansley is up now. He starts by explaining a bit of his history as someone who loves music and had a somewhat large hit, thriftshop. He equates some of those experiences, and speaking to fans, to his life as a software tester. He comes from an age where the “testers are the gatekeepers”… This is a somewhat controversial statement but he goes on to explain that we are all passionate about doing what’s right for the customer. Testers verify that the product does what it’s suppose to do! There is a danger that testers forget that we are power users, and not everyone is a power user.
He starts talking about communication, another very common theme, and being able to talk people of every context, every age.
Michael is a very good speaker and you can hear a pin drop as he pauses to allow us to reflect… Then hits us with an 80s nostalgia trip by relating Tron to the computer – user interface. “Vista was a really interesting project, an I can say that now because no none cares!!!” – business decisions overruled common sense by the sound of it… Testing it and fixing it was like “trying to polish a turd”. The testers made sure they documented everything.
Ask the question “what is it for”… This helps to put stuff into perspective, and helps us focus on what’s important.
Definitely contender for most entertaining talk of the day so far!
Talk 7 – Having all your testers code: It doesn’t have to be a big deal – Anna Baik & Andrew Morton
Next talk “having all your testers code. It doesn’t have to be a big deal” by Anna Baik and Andrew Morton. Sounds like it will be an experience report….
Starting with the common issue of not having time to learn, they explain how they tackled this by ring fencing time to do learning and experiments. However they rotated one tester out of the sprint to do this at a time, so they were alway working on their own.
As a side note, I don’t know why more presenters don’t use notes or cue cards. Is it perceived as a sign of weakness? I’ve never had that problem because I know my memory is poor so I need them!
Sorry, finding it quite hard to follow this one, perhaps it’s the post lunch slump…
“Inspect and adapt” … Right back in the programme! They found sprints weren’t really working for them so they adopted a more kanban approach.
Their automation was initially running dependant tests, so these were changed to become independent, and in control of their own test data. I’m assuming this also included environment configuration and any resetting that was needed. All pretty basic stuff for automated tests…
“Pairing is a great way of learning, sharing and just getting shit done in a productive manner”… This elicited a round of applause.
Everything Andrew and Anna talked about all seemed pretty straightforward cross functional team stuff to me. In my experience, the value of having a high performing cross functional team cannot be underestimated. Rely on those who are most suited to doing a job. If you need test automation frameworks coded up, use the developers; they will almost certainly be able to make it faster, and better than a tester, even if that tester can code.
Talk 8 – Do testers need a thick skin, or should we admit we’re simply human – Nicola Sedgwick
“Do testers need a thick skin, or should we admit we’re simply human” by Nicola Sedgwick… She starts off with a common conversation “there’s a bug in production”, “was this tested”, “what did I miss” you then start questioning your ability and process. Emotions kick in, defences go up and it doesn’t end well from that point. Although we are all rational, once emotions are there we become irrational.
There are many perceptions of testers, or types of testers, and the type at community events like Testbash probably represents a small subset of those types. There are courses on how testing can cope with other roles, but strangely not the other way round!
Communication is again a strong topic of this talk, do we need to be paying much much more attention on to how we communicate with all those around us.
Stress is a major issue and work is not the only source of stress, in fact it just piles on top of existing stress. Testers seem to get the rough end of the stick. Is this due to our passion for the product so we feel a greater ownership?
Amongst many coping mechanisms for stress and tips to be happy, Nicola suggest that you try to work on a product or in a domain you love.
What kind of tester is she… She is not just an information provider, she’s human with a wealth of experience!!
Great emotional talk!
The live blog is continued in Part 3