Testers of the world will (re)unite on October 21-22nd 2016 in Manchester (UK) for the most awesome, friendliest and jam packed software testing conference ever!
Our TestBash Manchester conference day is a single track conference all about software testing. There will be plenty to soak up and learn. The lineup of talks and speakers are below.
Date: Friday October 21st 2016 + Optional Open Space on Saturday 22nd October
Time: 8am – 10pm kick starting the day with a Lean Coffee, ending with social activities, discussions and more! (Conference talks end at 6pm)
Location: The Lowry
Book early to avoid sad faces.Register now
We need sponsors to help make this TestBash awesome. Full details here.
The People And The Talks
Don’t Think So Close To Me: Managing Critical and Social Distance in Testing – James Bach
Why do we need testing? Partly because thinkers make mistakes. How do we find those mistakes? Partly by using a different kind of thinking than that which created the mistake. This is the notion of critical distance– how much difference there is between perspectives or ways of thinking. Critical distance can be achieved in various ways, one of which is by creating social distance between different roles on the project. But social distance can kill productivity. Eliminating social distance is a big part of Agile. So how can we nurture the diversity and independence of viewpoints and approaches necessary for critical distance without putting up walls that make it hard for us to collaborate? This is the question I will try to answer in this talk.
Psychology of Asking Questions – Iain Bright
Psychology – the scientific study of the human mind and its functions, especially those affecting behavior in a given context.
Question – a sentence worded or expressed so as to elicit information.
For me, a key skill in testing is asking questions. As testers, we should be asking questions about the requirements/design/system at every opportunity we can: Who will be using it? Where? What happens if…? How does it work? How should it work? Why…?
These are all good questions, but the focus of them is to get information about the product being tested. Maybe we should be asking other questions? Not about the product, but about ourselves and of our peers and colleagues. And not to just elicit information either, but also elicit a desired response or behavioural change.
As testers, we sometimes find ourselves trying to deal with difficult situations and/or people. The natural response is try and find a solution to the problem or overcome the objections. Instead, maybe we should be asking more questions to challenge the problem faced until an agreement is reached?
What questions should we be asking of ourselves, peers and colleagues, and how?
That’s the aim of the presentation by guiding the audience through the following:
- To ask yourself what you are trying to achieve and why it’s important.
- To consider the working environment and the people in it and how you may need to re-phrase the same question to suit.
- To learn about different psychological techniques (e.g. ‘Why Not’, ‘Door in the Face’, ‘Foot in the Door’, ‘Placebo information’) and how they can be used to overcome objections.
During the presentation I will include some examples from my own experience as case studies and use time at the end to encourage the audience to share their experiences.
On Positivity – Turning That Frown Upside Down – Kim Knup
When I started testing I think I was good because I loved pointing out problems and faults, not only in the systems I was testing but also in my everyday life.
I loved moaning and complaining, about all sorts of things.
The toilet seat being left up, my flatmates not washing up, people walking too slowly in the street, and people in general.
I lived a life all about problems, finding and ranting about the negatives in every situation.
Nevertheless in my opinion, I did ok in my career with this approach even though I did fulfill the stereotype of the moaning tester, one with a martyr complex that hated people (not great when you are meant to be a team player).
This may have been a side effect of the waterfall projects I was involved in, or just my personality at the time.
But everything changed when I joined (supposedly) agile teams and realised I needed to communicate in more ways than just with a negative connotation. I therefore decided to try and turn my frown upside down.
This is my story of, how I did that using cognitive behavioural therapy techniques and exercises, what happened as a consequence, and how a bit of positive outlook can change your testing career.
Testers! Be More Salmon! – Duncan Nisbet
An organisation’s decision to shift towards a more agile & lean software development often leaves Testers wondering where they fit; promises of all the testing being automated, the whole team owning quality & light documentation appear to take away everything that Testers hold close to their heart.
What I have personally seen is that the iterative development cycle of Agile has not yet managed to remove the need for Testers, but it has caused the roles & responsibilities of those doing the testing to change.
The shortened delivery cycle means that Testers cannot be afforded the time they once used to have for planning, executing & reporting their testing.
So how do Testers fit in this fast paced delivery cycle?
My answer is that they need to be more salmon (without the death).
Testers need to be involved further upstream in the development cycle – they need to focus on questioning whether we’re building the right thing as much as whether we’re building right.
They also need to understand what other testing is going on in the product they are helping to develop – Programmers are writing unit tests, what are they looking for? UX are running A/B & multivariant tests, why?
The 4-hour Tester Experiment (No Testers Were Harmed In The Process) – Helena Jeret-Mäe and Joep Schuurkes
The challenge of teaching new testers useful skills is something that many testers face – either you’re a manager, a test competence lead, or an experienced tester who coaches other testers. What would you need to learn and practice to become a tester in the first place? How would you pick the things to learn and skills to practice to help a new team member learn the ropes of testing and start adding value? If Tim Ferriss can come up with the 4-hour chef, why can’t we come up with the 4-hour tester?
Armed with the hypothesis that it’s possible to identify the core skills and knowledge for testers and that it’s possible to become familiar with those in 4 hours, Joep and Helena set out to explore and discover what that core consists of. This talk addresses the process of discovery itself, how they found the hypothesis to be or not to be true, and what they learned along the way. They will also present the results of the experiment as a set of heuristics in a framework that can help novice testers to learn testing.
A Road to Awesomeness – Huib Schoots
New to testing? Looking improve your testing skills? Recently discovered the testing community and wondering what we’ve been talking about all this time? Well, this talk is for you then!
Huib is awesome. Well, he thinks he is. Others do to though, based on the popularity of his popular blogpost “Heuristics for recognizing professional testers”. In this talk, Huib will share his view on what an awesome tester is, based on that blogpost.
How did Huib become an awesome tester? What does he know that we may not. What skills has he learnt over his career, that we are perhaps yet to. What characteristics has he identified in himself and other awesome testers? Huib is going to share his personal learning journey with us. Offering us his map into the world of learning software testing, a detailed comprehensive map. Huib will walk us through his map expanding on why his map contains this area, key concepts to grasp in this area, how he cut his path through this area, sharing with us who and what helped him.
As a coach and trainer, Huib has coached and trained many software testers in his career. Over this time he has collated a huge list of useful resources, including books, blogs, videos and some great communities. Huib will equip you with them all, giving you all he has to offer, preparing you as best he can for your journey, be it at the start, or a new chapter. It just leaves one question, what does your map look like?
Listening: An Essential Skill For Software Testers – Stephen Mounsey
“When you talk you are repeating what you already know. But if you listen, you may learn something new” Dalai Lama
Are you really listening? Listening is an important skill for any human being but for a tester an essential skill. If part of testing is about information gathering and interpretation then Listening is a key component.
A detailed look at the art of listening with parallels being drawn between listening theories and how we test. Listening when done effectively has the potential to change your relationships as well as your testing.
- The characteristics of those who really listen
- Listening theory – how we listen
- Benefits of listening
- Practical examples of how we aren’t listening testing
Getting The Message Across – Beren Van Daele
Last week, I read the following tip: Never talk to management about testing. If you really have to talk to management, talk about money and risk. DO NOT mention Testing.
I’ve had my experience of talking about testing to management about testing. It didn’t go well.
The quote got me thinking though. If we can’t talk to management about testing, can we talk to –anyone- about testing? The same reasons apply to just about anyone. Management doesn’t care about testing. Developers don’t care about testing. Your mom doesn’t care about testing.
They DO care about the results of your testing.
Then again, most of the results, put in the form of a report are gathering dust in people’s shelves.
Much to our detriment, we’re pushed in a situation where we’re encouraged not to talk about what we do, but need to get our message across for sake of the project. We all have our little tricks and hoodwinks to get buy-in from our stakeholders and I want to show you three of them.
During my talk, I want to provide several hooks to explain ‘what we do’ to our stakeholders without actually mentioning testing. I want to show how we can create low maintenance interactive, visible reports to shock and/or mold the project one way or another.
We provide information. Through reporting this information, we influence and guide the flow of that project. By having human interactions around this information and talking about it with many different people, we lay bare:
- What it means;
- How we got it;
- Why it’s important to the project.
For a year and a half, I’ve worked on a test strategy and adjusted it many times. We’ve grown from a rigid test case centered approach to a minimal documented approach.
The only documentation we kept at the end were bugs and reports.
Is Test Causing Your Live Problems? – Gwen Diagram
Do you encounter fear pressing that deploy button? Are you worried that once you deploy to live you’ll be monitoring the servers, waiting for calls and tucking yourself into your sleeping bag at work for a late night? Sometimes deploying to live causes things to go bang and you’ll wonder, what the hell has happened? Have you asked yourself, how closely does your test environment actually match live and do you know the differences? Gwen will be going through some common problems with test environments and how to keep them in a state so that you have more confidence to deploy code. She will touch on topics such as performance, monitoring, configuration and rollbacks with a few hairy experiences related to what happens when these aren’t considered. A release should be a reason to go to the pub and have a beer to celebrate a successful deployment instead of staying back and firefighting.
The Deadly Sins Of Acceptance Scenarios – Mark Winteringham
BDD, ATDD, Acceptance criteria and scenarios are becoming an ever popular means of defining requirements, enabling collaboration, facilitating testing, development and checking activities. Yet when it comes to adopting these practises we misunderstand and misuse them to our team and to our product’s detriment and worse, as more teams make the move to use acceptance criteria and scenarios the common mistakes we make become accepted as the correct way to work.
The deadly sins of acceptance criteria and scenarios will challenge commonly held views made around creating and using acceptance criteria and scenarios, question their validity and explain why they are causing more harm than good, as well as how we might atone by changing our and our teams behaviour.
So if you sit alone writing scenarios as a means to create test scripts, or attempt to cover every boundary of a form field in one scenario, think that all acceptance scenarios should be automated to inform us we are delivering what the business wants then maybe you should find out if you are committing a deadly sin!
Book early to avoid sad faces.Register now
Many thanks for the following micro-sponsors. We appreciate every single one! You should too!