Registration is now closed.
Sign up to our mailing list and we will send you updates on things we are working on (including the announcement of any new events).
TestBash, the leading software testing conference within the UK, has now passed! We hope you are not suffering from the TestBash blues!
This page will turn into an archive of the event. We are in the process of updating this page with links/photos/information.
- Adam Bardell – My first TestBash in 2015 (and blog post)
- Chris George – TestBash 2015 – Sun, Sea and Test
- Matt Hutchison (Testing Curator) – Tweet Bits from #TestBash 2015
- James Macdonald – TestBash Workshop Day 2015
- Simon Prior – TestBash 2015 – More than Just a Conference
- Neil Studd – The TestBash 2015 Story
- Amy Phillips – Thoughts From TestBash 2015
- John Stevenson – Tesbash 2015 – Workshop Day
- Simon Knight – The End of An Era
- Colin Watson – TestBash 2015, Key Theme Changing Your Language!
- Rosie Sherry – On Being Thankful
- QA Symphony – A Bash on the Beach at TestBash
- UTest – Top Tweets from TestBash
- Daniel Knott – TestBash 2015 and my Workshop about Mobile Testing
- Del Dewar – TestBash 2015 – Are ye Dancin’?
- Bhagya Mudiyanslage – Testbash 2015 impact
- Stephen Janaway – TestBash – The Friendly Conference
- Jokin Aspiazu – Consider Your Time As A Training Resource
And our Flickr stream.
Please view descriptions of talks below. Slides and video links coming soon!
The Rapid Software Testing Guide to What You Meant To Say – Michael Bolton
“I break the software.” “Cannot reproduce.” “We need a week to regress the new build.” “We have to do automation.” “It works!” From time to time, testers say things that they don’t mean, sometimes as a slip, and sometimes as a habit. Usually there’s no malice or intention to mislead, but our clients may be deceived nonetheless. Worse, we can deceive ourselves.
Words are powerful tools for understanding and clarifying ideas, but like all tools, they must be used skilfully to achieve their purposes and to avoid trouble. In the Rapid Software Testing Guide to What You Meant To Say, Michael Bolton will report on some common expressions and patterns of speech that he considers risky, and he’ll offer ideas for using words more carefully and precisely.
Why I Lost My Job As a Test Manager and What I Learnt As a Result – Stephen Janaway
My career followed the typical path of someone in technology. Tester, Test Lead, Test Manager, Senior Test Manager. It started in 1999, back when we lived in a world of scripted tests and large, separate, test teams who designed and ran the tests. A world of silo’s and walls, a world where communication-by-bug-report was common.
Agile came, and fortunately disrupted things. Teams became cross-functional, and yet management did not change. Management became harder; there were more stakeholders to manage, and more areas to cover. Task switching came as standard. Eventually the penny dropped with senior management and the management team was re-organised. A change had to come and that meant no more Test Managers….
This presentation aims to present a view of test management that I think fits with the software development methodologies, and team structures that we typically see in IT today. It will use my personal experiences to explain why I think discipline based management is no longer relevant or required, and how Test Managers need to adapt to the new world of cross-functional, agile teams and continuous delivery. Change is coming, how will we all adapt?
What’s In a Name? Experimenting With Testing Job Titles – Martin Hynie
Organizational bias towards software testing has continued to haunt us throughout my career. With each successful mission to spread knowledge about our community and craft, I would encounter another challenge. A new manager, an opposing director or a newly contracted consultant who would overlook the potential benefits of including members of testing in key phases of critical projects. I was hiring experts in our target market, brilliant coders and researchers, and excellent critical thinkers but we continued to be overlooked only to be brought in too late to contribute key information that could have saved our projects time and money.
So as a team, we asked the question: “What if we did not call ourselves testers? Would anything change?” In other words… we had an interesting hypothesis about our system and like all good testers, we decided to test it in order to learn more about it.
In this presentation, I will present the story of our 18 month experiment with rotating job titles. I will highlight:
- The startling impact this had on how the members of the testing team were included (and sought out) within development projects.
- The dramatic changes in communication paths that happened within weeks of each job title change.
- The emergence of extremely strong relationships in departments like marketing and product management.
- The reaction when job titles would get changed back to software tester.
- And most surprisingly, the observed companywide changes made to accommodate and empower the “new key roles” being filled by members of the testing team.
Automation in Testing – Richard Bradshaw
In this talk I will introduce the ideas of Automation in Testing. I will explain my reasoning for this new term over existing. Exploring the industries view of automation and how this has guided the way automation is being used in testing. We will explore the new opportunities for automation that become so clear when you change your terminology. Focusing on how most common automation framework approaches can be utilised to provide tools that assist testing. I will share my experiences of where I have created automation specifically to assist my testing, not checking, testing. I may even attempt a live demo.
The Art of Asking Questions – Karen Johnson
The Art of Asking Questions As software testers, we need to learn a product thoroughly, we need to know how a product has been built so that we can test and investigate the robustness and readiness of a product. So we ask lots of questions. We ask designers, developers, product owners and many other people questions throughout our day and yet, rarely do we stop to recognize the skill of asking questions.
Bug Detection – Iain McCowatt
Download Slides (PowerPoint) / Video coming soon!
How do you recognise a bug? For me, the experience varies. Sometimes it’s a flash of inspiration, a Eureka moment, “That’s not right!” and obviously so. At other times it is a simple act of deduction: I am looking for a specific behaviour, the software doesn’t provide it, therefore I’ve found a bug.
The latter gets much of the attention: this lies at the heart of automated checks and traditional test scripts: do x, expect y, if not y then bug. Yet many of the bugs, and many of the most important bugs,that I’ve found in my life as a tester have fallen into the former category: they were bugs that simply leapt out at me, some of them screaming. This is powerful, and we ignore it at our peril: your skill and knowledge play a critical role in your ability to even SEE the bugs that lie before you.
Join me in this discussion of how intuition and tacit knowledge influence how human beings recognise bugs. Starting with just a little theory and examples, we’ll move quickly on to explore the implications for how you lead the process of discovery, how to balance tester integration and independence, and how to harness the diversity amongst members of your testing team.
Quality doesn’t belong with the tester! – Maaret Pyhäjärvi
If it doesn’t work in production, was it badly tested? Or, is it that testing – like use in production – shows problems that were already there, but without trying them early on, the problems remain in production?
This presentation deals with the biggest learning over the years as tester that I’ve needed to pick up: while it’s great that I’m useful and needed, I need to actively work towards being less needed by teaching more testing skills to all team members and always remember that the quality belongs with the developer. It was already broken, I did not break it, and learning to break it less is a valuable thing developers pick up with testing skills.
We look at an example of a team that, learning to rely on the tester, ended up with worse quality than without a tester. We’ll also look at the practical steps of assigning responsibilities and pairing up and test automation effort that helped bring things back in balance.
Re-running the ‘Are you a mac or a PC? battle … for iOS and Android – Sally Goble & Jon Hare-Winton
In 2006 Mitchell and Webb starred in a long running TV campaign to persuade viewers about the differences between Macs and PCs. In 2015 Goble and Hare-Winton will re-run the battle in the field of mobile testing – this time it’s iOS versus Android.
Slave to Apple’s two week approval and release process – maybe you should switch to Android? Spend nights crying about device fragmentation – ditch Android and embrace the sparsity of Apple devices. Manual and automation testing approaches and techniques on the two platforms will be compared, contrasted and – well – just argued about. Which side will you take?
Jon Hare-Winton has a Nexus 5 and a Nexus 7. Sally Goble has an iPhone 5S and an old iPad 2. They both work in the mobile development team at the Guardian and have more than 12 years of testing experience between them.
Getting Rid of Release Candidate Testing – Matthew Heusser
No slides / Video coming soon!
Agile Delivery to production requires a lot of things, but one of the most challenge may be to reduce the human process of testing release candidates, sometimes called “regression testing” — or even eliminating it entirely! Is that possible, valuable, and helpful for your organization? The answer to all three might just be ‘yes.’ In this presentation Matt Heusser explains his experiences with frequent release, architectures and context where it can make sense, common requirements, infrastructure pieces, patterns, when it might not make sense … and some concrete suggestions to try tomorrow.
Myths and Legends of Software Testing – Vernon Richards
“Nobody would ever do that!”
“Testers should learn how to write code”
“Why didn’t you find that bug?”
Sound familiar? If you’ve been a tester for longer than a couple of nanoseconds, you’ve probably heard or said something similar to the above comments – I certainly have! Whether it’s a control freak PM, a hero developer or a quality cop tester, these odd notions of testing are everywhere.
But so what? Well the job of a tester is to challenge assumptions and in this session, I’ll explore whether any of these myths & legends of software testing are true, false or somewhere in between.