TestBash Brighton Conference Day

2 TestBash Banners 2015-04

Testers of the world will (re)unite on March 10-11th 2016 in Brighton (UK) for the most awesome, friendliest and jam packed software testing conference ever!

Our TestBash Brighton conference day is a single track conference all about software testing.  There will be plenty to soak up and learn.  The line up of talks and speakers are below.

Date: Friday March 11th 2016

Time: 8am – 10pm – kick starting with a Lean Coffee, ending with social activities, discussions and more! (Conference talks end at 6pm)

LocationBrighton Dome.

Schedule: Download the schedule for the day (PDF).


You can book your tickets now!

Register now


Building the Right Thing: How Testers Can Help – Lisa Crispin / Emma Armstrong

Has your team ever worked hard to deliver a feature, only to find that no customers want to use it? That’s a frustrating waste of everyone’s time. Just about every software delivery team has limited resources. The product we deliver must provide the maximum value for customers and the business.

Testers can apply their unique skills to help business stakeholders and the software delivery team identify the most valuable features to build next – and gain a shared understanding of exactly what that includes. As testers, we can keep an eye on the big picture, while defining the details of software behavior. Lisa and Emma will discuss how testers can explore quality attributes in all four Agile Testing Quadrants, using examples. They’ll introduce techniques such as example mapping, story mapping, structured conversations, data capture, observations and feature usage information gathering techniques to help decide business priorities and ensure those priorities are met.

About Lisa

Lisa Crispin is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014), Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002), and a contributor to Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011) and Beautiful Testing (O’Reilly, 2009). Lisa was voted by her peers as the Most Influential Agile Testing Professional Person in 2012. Lisa enjoys working as a tester with an awesome agile team. She shares her experiences via writing, presenting, teaching and participating in agile testing communities around the world. For more about Lisa’s work, visit www.lisacrispin.com, www.agiletester.ca, and follow @lisacrispin on Twitter.

About Emma

Emma Armstrong is a test engineer, who has been testing software since 2000. In that time she’s carried out both manual and automated testing and had the opportunity to dig into everything from compilers to web applications.

She’s worked with most methodologies, gotten to grips with technologies ranging from chipset hardware to UI (and everything in between), managed test teams and is currently working on financial modeling software.

Test/QA a Gate Keeper’s Experience – Michael Wansley

I got into testing at the beginning of 2000.  I had been driving a delivery van in Seattle, delivering hair products for a local distributor for 10 yrs prior.  My kids were getting older, things were getting more expensive and personal computing was rising in popularity and becoming more affordable.  A friend of mine gave me one of his old 486 boxes after an upgrade and told me I could record music on it.  After buying a copy of Cakewalk, a hard disk audio recording program and installing it, I found out that Windows 95 wasn’t the most stable of operating systems.  Errors led to questions and that led to me finding those answers.

Being a ‘gate keeper’ has many meanings.  After my years at Microsoft, particularly while working on the imaging team and being responsible for the digital image transfer wizard, it’s inbox drivers and UI experience, I’ve discovered and have come to believe that testers are the user’s advocate. It is a tester’s duty to emulate as many different user skill levels, understanding of systems and process, workflow as well as be able to interpret highly technical input.  We do this to verify business requirements are met by dev and what has been designed works as expected.  Business will always ship when it’s right or good for business, but it is up to test and QA to establish and raise the quality of the software being released.  Not every issue will be found, not every issue found is a show stopper, but to sign off on a product or feature with the greatest assurance that the user won’t realize the software is working for them, that is optimum goal.  Software is a tool.  A transparent tool that allows the user to accomplish tasks.  If a product is well tested, the user never has to think about how the software works and can focus entirely on whatever it is the product is designed to do.  I mean, no one actually thinks about how notepad works anymore, do they?

About Michael

Michael Wansley aka Wanz has been performing music since 1967.  Singing for anyone, anywhere at anytime, he made his way through school and off to college to learn how to be a music educator, but by 1984, he’d been in a few bands and tasted a bit of local success.  This, combined with other econimic challenges, compelled him to give up being an educator and move to Seattle to become a star!

After over 13 years of failure on the music side, Michael began teaching himself about computers, landing his first real computer gig at a local store that built and sold their own systems.  One of his workmates had gotten on at Microsoft’s Direct Music team and they needed another tester…Michael got the call and the gig!  This led to 11 years of contracting, testing on Win98, Server 2000, Me, XP, Server 2003, IE7, Vista, Office Communicator and other Microsoft products.  The experience landed him a full time permanent position testing medical software.

Feeling as though he’d found the best job in the world, Michael established himself as a ‘jack of all trades’ tester.  Able to switch from waterfall to agile testing, moving from one product to another and always developing solid test plans and cases.  Not many testers at this company had worked with multiple products, but Michael always seemed to fit in then excel.  Customer issues post release dropped significantly on features and products Michael had guided or worked on.  Then came ‘the call’.

While content to spend the rest of his testing career at what Michael often called “the best job” he’d ever had, a call from a friend turned into an musical opportunity that became the now legendary song “Thrift Shop” by Macklemore and Ryan Lewis.  Michael left his full time job to tour the world, living the dream he’d had since single digits!! But all things come to an end.  The music hadn’t panned out as Michael had hoped and in August of 2015, he returned to the second love of his life, software testing.  Michael currently is a QA Engineer on the Sustaining Team at the Seattle home office of Tableau Software, a data visualization company.

A Pairing Experiment – Katrina Clokie

Are you the only person in your organisation who has heard of pair testing? Would you like to pair, but you’re not sure how to begin? Perhaps pair testing is something you tried once, but then you decided it wasn’t for you? Did you encounter resistance to the idea, or feel that you didn’t get much from the experience? Don’t give up!

Listen to my experience of implementing pair testing. I will share how I introduced the concept of pairing to my team of over 20 testers, describe the logistics of the pairing experiment we used to share knowledge between testers in different agile teams, share feedback that the team provided during the experiment, detail the outcomes we achieved, and describe how we adapted and evolved our pair testing as we improved our understanding of the benefits it provided.

Pair testing is about having two people test the same thing, at the same time and place, continuously exchanging ideas. It creates an environment for creative, collaborative and productive testing. But you cannot pair alone. This session aims to inspire you to try pair testing, and provides practical tips so that you can take others on the journey with you.

About Katrina

Katrina Clokie serves a team of more than 20 testers as a Testing Coach at the Bank of New Zealand. She is an active contributor to the international testing community as the editor of Testing Trapeze magazine, a co-founder of her local testing MeetUp WeTest Workshops, a mentor with Speak Easy, an international conference speaker, frequent blogger and tweeter.

Model Fatigue and How to Break It – John Stevenson

Many of us are familiar with the various testing models from Rapid Software Testing for example FEW HICCUPPS and SFDPOT. These models have been used extensively with my teams for forming coverage maps and creating testing missions utilizing mind maps. However over the past few years I have noticed that templates have appeared with the same details and the same type of thinking or in some cases no thinking. To me many, including myself, have followed the path of least resistance and used what others have done without engaging our creativity. To try and resolved this I have over the last 9-10 months introduced some creativity models to try and overcome what I have come to call ‘Model Fatigue’. This experience report looks at these creativity models and discussed their success and failures.

Main points:

  • Models can become stale
  • We suffer model fatigue by not revisiting our models
  • Creative models can help ‘refresh’ exiting testing ideas.

About John Stevenson

Having been involved in testing for over 20 years and within the IT industry for more than 25 years I am still surprised with how exciting I find it and how much I continue to learn about things that are new.

I have a passion for learning and love to learn about new things. I have an interest in many things such as social science, psychology, photography and gardening. I keep involved within the testing community and write a testing blog and can be found regularly tweeting.

I am keen to see what can be of benefit to software testing from outside the traditional channels and as such I like to explore different domains and see if there is anything that can be linked back to testing. I care about the testing community, like to be involved and like to be social.

I feel I have a wide variety of experience within testing and currently I am mentoring and training others in exploratory testing and SBTM whilst looking for opportunities to introduce approaches from other crafts such as anthropology, ethnographic research, design thinking, cognitive science and many others. I am currently writing a book about the psychology of software testing based upon my interests in psychology.

Accepting Ignorance – The Force of a Good Tester – Patrick Prill

“The only true wisdom is in knowing you know nothing.“ – Socrates

When I say ignorance, I mean the positive definition of identifying, and constantly striving to discover (and possibly know) what you don’t know.

In this experience report, I will describe the journey I took in the past 3 years of my 12 years as testing professional that simply started with attending a webinar. I will share with you my discoveries about the importance of ignorance and the benefits to use it effectively.

Together we will explore some common examples of everyday testing terms, and discover where the frontier of ignorance might already exist. We will look at psychological phenomenon that influences the awareness of knowledge. And I will share a few handy tips how to utilize ignorance.

The key takeaways for participants of my talk are:

  • Ignorance is the driver for your self-learning
  • Basic idea of psychological effects that might influence your self-learning
  • The helpfulness of re-evaluation of your knowledge to gain confidence and precision in using it (for bug reports, test reports, risk assessments, etc.)
  • Some starting points how to utilize your ignorance

About Patrick

Patrick Prill has over 12 years of experience in software testing. After four and half years as a tester he became test manager, coordinating the work of ~50 people for another 5 years in a big test project. His new job as test lead for a software and consulting company for the automotive industry brought him back to a smaller test team and the hands-on experience of testing software again. This experience and following the discussions and articles of the testing community relighted his fire for testing and bug hunting.

Patrick is living outside of Munich, Germany and is a proud husband and father of a wonderful daughter. In the little spare time he is a wood turner. Patrick tweets at @TestPappy and blogs at http://testpappy.wordpress.com.

Having All Your Testers Code: It Doesn’t Have to be a Big Deal – Anna Baik / Andrew Morton

This is our story of how we introduced test automation in our company, and discovered that testers learning to code isn’t a big deal. Code isn’t the hard part. Everything else is the hard part.

We’ll talk about what we got wrong, and then how we put it right, and what’s still a work in progress. Some of that is technical, but most of the interesting problems weren’t technical, but around getting backing from senior management (it’s awesome when your CEO tells you “I want the whole company to be focused on quality”, and then backs it up by giving you the time to work on that), figuring out good ways of working together, and staying together while we climbed up that learning curve without leaving anyone behind.

We’re not promising the ultimate solution here. This is just our story, and what worked for our context. Making it work for us involved ignoring some things other people said wouldn’t work because we knew it would for us, so we’d be the last to prescribe a context-free script for you.

About Anna 

Anna Baik – @testerab: About five years ago, I was seriously considering just getting out of testing forever. So I signed up for Rapid Software Testing, came back thinking “no, dammit, I don’t have crazy ideas. I have perfectly sane ideas in an insane environment”, and quit to find somewhere that would allow me to put these ideas to good use. That took me to Brightpearl.

I help with building the test community in Bristol and elsewhere, having originally started the Weekend Testing Europe chapter and arranging Software Testing Club and South West Test meetups in Bristol.

About Andrew

Andrew Morton – @testingchef: A similar story to many, I fell into software testing about 8 years ago and have not looked back since. It was a couple of years into my career I decided there has to be a better way to test, which led me to find Context-driven testing and I consider myself to be a Context-driven tester. My current context involves a lot of programming, the majority of which is Ruby and Java, and trying to create testing tools and practices to help our development teams.

Do Testers Need a Thick Skin? Or Should We Admit We’re Simply Human? – Nicola Sedgwick

As a profession we are constantly striving to move away from the stereotype of QA with success defined as zero bugs in production. Instead we strive for our companies and teams to understand that testing should be considered throughout and within the ideas brainstorming, design review and coding activities rather than purely at the end of the development process when a build becomes available. Then, if a bug is found in released software we aim to look at how that bug escaped detection and improve the team’s testing, coding and design processes going forward.

However, hearing the phrase “there’s a bug in production” still drives a lightning bolt of self-doubt and blame through my very core. I start questioning internally whether I’m being blamed for the failure and kick myself for missing the bug as I feel the adrenaline flow and my heart beat faster. Even in the best agile project team where blame is never mentioned – I still blame myself for letting the bug through, even though logically I know that I did no such thing.

I’m sure I’m not alone.

The truth is that the adrenaline and self-doubt can be great drivers of understanding problems, finding or confirming fixes and staying alert until the situation is resolved. But, when these situations occur on a frequent basis, or in batches without sufficient recovery time then the blame and self-doubt can take hold.

Even in the best projects with collaborative teams experiencing minimal production issues – It can be hard to maintain a healthy and happy sense of self whilst also being the ‘bad guy’ pointing out the problems.

There’s no perfect solution to this situation but I have a few ideas to share, drawn from my own personal experience. Hopefully this talk will inspire other testers to share stories, share experiences and (potentially grudgingly) admit that testers, like their team mates, are human too.

Testing or Hacking? Real Advice on Effective Security Testing Strategies – Dan Billing

Most of us never know who does the security testing for our development teams. Sometimes it’s an internal team, maybe external. Sometimes it doesn’t even happen at all. Some of us are building security testing into our current practices, from the ground up. Some managers may feel that there isn’t the time, skills or resources to do security testing. Many testers may feel they don’t have the skills. A few of you might not feel empowered to take the lead. Inevitably, they might feel that they don’t need to worry about it, as it is someone else’s problem. And this is a serious dysfunction. Let’s look at the essential steps to build and execute your own security testing strategies. Let’s examine how learning and mentoring can aid in the development of strategies. You can and should build up your own skills with integrated security testing. This will ensure ongoing relevance of your role in a security context, and the success of your organisations.

About Dan

Dan ​has been a tester for 15 years, working within a diverse range of development organisations, mostly in the south west of England. He currently works as a test engineer at New Voice Media, where most of his time is spent working on the security testing needs of the business. This includes mentoring, supporting and training members of the team to use these skills also.

Dan’s love of testing drives me to become an active member of the testing community, helping to organise local tester meetups in the Bristol and Bath area. He is also a co­facilitator with Weekend Testing Europe, and also organises the South West Exploratory Workshop in Testing.

Dan lives in Frome, Somerset with his wife Rae, and cat, Misty

Nowhere to Hide: Adjusting to Being a Team’s Sole Tester – Nicola Owen

I’ll share my experiences on how I adjusted from working in a group of testers to being a team’s sole tester.

I’ll start by describing the context:

  • Many testers
  • Multiple testers covered the same functionalities – no-one was in ‘sole charge’ of testing any one area
  • I was surrounded by people intent on doing test cases
  • During this time I was content and felt rather safe – there were no real consequences in failing.
  • After consistently being one of many testers I moved to a company where there is only one tester per team.

The new context:

  • Team’s sole tester
  • Testers were specialised in their area
  • Testers could choose how to test e.g. Mind-maps, SBTM

Now there was nowhere to hide. If I messed up, customer care received many calls. If I did did well, our NPS improved for that area.

Not only did I learn the importance of QA reviews, but also of getting input from the developers and business analysts. I initially had to learn this the hard way because I was too proud to ask for help and consequently poor quality software was deployed.

Soon I was making an effort to share mind-maps with the developers before they wrote their code in an effort to prevent bugs. This helped in two ways. Firstly, I didn’t get pushed for time, and have to do a lot of testing at the last minute. Secondly, I didn’t need to pull other testers from their projects.

Being the my team’s only tester encouraged me to work on the craft of testing. Since the consequences of not doing my job well were greater, I wanted to feel confident when software went live. I did this by attending meetups, attending conferences and reading blog posts about other people’s experiences.

Nicola Owen

Nicola Owen is a Test Consultant with House of Test in Sweden, originally from Auckland, New Zealand. After studying Economics and German at university she decided to delve into the world of testing and hasn’t looked back since. She’s well involved in the testing community as a co-instructor of the BBST Foundations courses and a frequent meet-up attendee. When she’s not at work you’ll find her watching cooking shows, making cookies or running as she listens to dance music. Nicola blogs about software testing at nickytests.blogspot.com. Follow her on Twitter @NicolaO55

Smart Algorithms – Are We Ready For This? – Bill Matthews

It’s common these days when visiting websites to be presented with helpful ideas on what books to read, films to watch, where to eat or buy next or where to go on holiday. Sometimes we marvel at (or get freaked out by) how well these sites seem to understand our needs and preferences, but have you ever thought about how you would test such a system? While such recommender systems are becoming commonplace, they represent the tip of the iceberg of the range of smart, learning and artificial intelligence based systems that are coming our way. With much of the exiting testing literature, approaches and test design techniques are geared towards testing systems that are generally static in nature, it raises the question “Are we ready to test such dynamic and adaptive systems?” In this interactive talk we will explore a wider range of smart, learning and artificial algorithms, consider the unique challenges they bring to testing these in the context of other related challenges such as Big Data and the IoT (Internet of Things) and explore ideas on how we might approach testing such systems.

About Bill

Bill Matthews has been a testing specialist for 20 years with the last 17 years as a freelance test consultant working mainly on large migration and integration projects as a Test Architect, Manager and Technical Tester. He spends much of his time focusing on helping companies deliver the more technical elements of system and operational testing such as integration, performance and security. A regular part of Bill’s work is coaching and mentoring testers in thinking tactically and strategically about testing as well as technical testing skills.

He is a regular speaker at testing conferences mainly on technical topics such as web and mobile security and teaches course on both Web and Mobile Application Security.


You can book your tickets now!

Register now