150 hours of testing

Do you have responsibility for teaching people how to test?

This is a talk about a technical experiment - how I went from a tiny idea about Javascript training to delivering a full learning framework for a busy testing team.

This isn’t taught in engineering degrees. Anyhow, I did classical studies

The challenge
Working in a consultancy, there are any number of companies wanting any number of testers with any number of skills ALL AT THE SAME TIME. One of our problems has always been that no tester can have all the skills at once. Ok, they can, but it can take an individual tester up to 10+ years to acquire them if they are picking them up on the job or upskilling in their own time.


It’s not as simple as buying some training site subscriptions (I wish that it was)
Testers need a complex mix of technical, domain, business, methodological and soft skills. We could not find a single training site or provider delivering the consistent standard of training on all of the areas we wanted to be covered.

With this in mind, I had to find a way to bring my team up to a certain level of understanding regarding any of the testing that they could be called on to do. I concluded that the only way to do this would be in-house. Another reason for us doing it in-house was the estimated cost of getting a 3rd party trainer in - we were looking at a bill of 5 figures per tester!


Planning threw up some questions we needed to answer:
• From using the object model (or not!) to automate the testing of a UI, to monitoring traffic going over a switch, to interrogating a database via a new protocol - how (HOW?) on Earth do you teach all of this to testers?

• When teaching code, do we go down a computer science path or take a more basic concepts approach?

• How much code do you teach non-coders to make them proficient in tools like Postman?

• Keeping in mind some of my team came from single track specialisms (like Accessibility or BDD) - how was I going to take a tester like this and teach them the joy contract testing of a backend API? (Should we even try?)

• Where do you start when teaching an automation framework?

• Should we just install Selenium (yay!) and work backwards through the supporting libs to teach people the concepts that underpin it as we go or teach the bare bones of a framework without a tool? (boring!) (Bit of personal bias creeping in there!)

• How do you teach a tester soft skills like negotiation and conflict resolution?

• How do you stop the quickest tester in the room from getting bored while you wait for others to catch up?

As we went through delivering this training ourselves, we realised everyone learns differently and delivering courses in a format that worked for everyone IS VERY HARD (REALLY HARD) (OH MY GOODNESS, SO HARD) (HAVE I MENTIONED HOW HARD THIS WAS). The general existing dichotomy in online learning seemed to veer between the computer science approach of Edx and the learn by exercise/practice approach of sites like Sololearn. What level was our training approach best pitched at?


Why 150 hours of testing?
Answering these questions was how 150 hours was born. The name changed several times. Initially, it was 40 hours of test as we envisioned that about 40 sessions should cover all of the desired essential skills. Then 80 hours as we factored in the preparation time. As more testers came on board and requested that more training was added, this quickly became 250 hours. Finally, we agreed to stop debating the title and just settle on 150 hours on the basis this was the average amount of “new” stuff testers were being exposed to.


This talk is about:
* What solutions we came up with for the problems we thought about upfront
* What the unforeseen hurdles were that jumped up and hit us smack in the face
* What technical solutions we used to help us deliver the content to testers across 4 offices
* What people problems we encountered along the way and how we addressed them
* How we got other craftspeople (devs and UX) involved in producing sessions too


The takeaways
* How to plan for delivering a learning programme to a busy team
* How deep and wide to go when teaching a tool or a language or a component
* How to break down your learning into a logical flow to be delivered in consumable sessions
* How to solve some of the problems you may see along the way

Besides a screen and a microphone, I have no tech needs to deliver this talk above and beyond those of most speakers.

I am Irish, educated in Cork, living in London. For conferances outside of London, I will require that travel and accomodation are covered. As part of my travel, I will look up and offer to talk at local free events if the timelines work out.

The idea for 150 hours came from me. I am the designer of the training framework in collaboration with the testing team I support in London. I also received a lot of great feedback and input from the Scott Logic grad class of 2018 and 2019. I wrote the first tutoral on Feb. 2nd 2018. 150 hours just had its first birthday.

We have iterated through the plan nearly 3 times and I am proud to say that some of the first people to benefit from the framework are now teaching it so I know that it is an inheritable and repeatable process that any tester, coach or consultant can follow.