Skip to main content

Leeds Testing Atelier - October 2017

Firstly, I’d like to pass on massive kudos to the organisers… Stephen, Ash, Gwen, Nick, Fred, Richie and Sophie… Apologies if I have missed anyone! AMAZING JOB J

Massive shout out to the sponsors:

Infinity Works
Ministry of Testing 
Tony Holroyd

Without the efforts of the organisers and support of the sponsors this event wouldn’t be completely free…

Fred on your imminent move back to Norway you will be missed by many, and I’ve been lucky enough to work with you for 3 years! Good luck on your move back home… you’ll smash it!

OK, so on to the talks…

Rosie Hamilton – Discovering logic in testing

Rosie wanted us to think of a time when nobody knew what testing was, there were no books, no conferences, NOTHING! But, you get offered a job as a Software Tester…

Rosie started out as a compliance tester in the gaming industry, for her this meant following basic instructions:

-          The game must do ‘X’
-          The game must not do ‘Y’

This soon became repetitive, she eventually moved in to functional testing where there were no test cases and no rules. This made it fun but also challenging.

As there were no experience in the team they were learning together, and over time they got better at thinking, observing, reasoning, learning and developed better intuition but still found it hard to explain exactly what they were doing.

We are wired to look for patterns in things but just because we can’t explain it doesn’t make it any less real.

Logic, it doesn’t invent or observe, it judges.

Never believe a developer if they say things like “It works on my machine”, “That’s impossible”

Rosie spoke about the different logical mind-sets:

The Developer Logic:

Deductive reasoning is a logical process in which a conclusion is based on the concordance of multiple premises that are generally assumed to be true.

The Primitive Testing Logic:

Inductive reasoning is a logical process in which multiple premises, all believed true or found true most of the time, are combined to obtain a specific conclusion. Inductive reasoning is often used in applications that involve prediction, forecasting, or behaviour.

Advance Testing Logic:

Abductive reasoning is a form of logical inference which starts with an observation then seeks to find the simplest and most likely explanation.

Rosie was eluding to the fact that we need to try things, create mini experiments and prove things that shouldn’t happen but do. The only way we can do this is interacting with the software, trying to recreate issues and keep generating new ideas.

Her final quote was – Remember that you are a black swan, be unique as diversity is important in testing.

Observation – Searching for the black swan
-          Observe with mindfulness and focus
-          Always look at things twice
-          Zoom in on the tiny detail
-          Zoom out and see the big picture
-          Be curious as it leads to discovery

Reasoning – Explaining the black swan
-          Search for the most obvious answer
-          If you get a gut feeling, follow it
-          Question everything suspend belief
-          Don’t be fooled by things you see
-          Don’t be fooled by things you are told

Chris Warren – To the left, to the left everything I test in box to the left

Chris wanted to tell us his story on how he has managed to fix a problem. Reduce the amount of manual effort, testers not having visibility early enough and reduce the amount of test technical debt on his project.

His main action was to start early, earlier than in some cases is expected.

Chris has changed the way he and his team work by creating a multi-functional team, he pairs with developers, understands what small code changes he could do himself and works with the developers to get them automating tests. This allows more emphasis on other elements such as exploratory testing, but the main reason is to encourage collaboration and make it fun.

A question we should all ask ourselves is, does a day’s planning really add value? Probably not…

Chris created a view for the project so the team were aware of what was coming next.

As they have a view of up and coming work it allows them to start thinking about BDD scenarios much earlier. You still have to be careful because lack of understanding and changed priorities will impact this step in the process but when the work moves in to analysis, elaboration and test analysis it will make this process much easier and will reduce planning time.

Analysis – BA explains the story. The development team have an opportunity to ask questions and the BA can take the unanswered questions back to the PO.

Elaboration – Developers discuss what is involved to complete the work, technical notes are added to the user story and other considerations like security are also looked at here.

Test Analysis – Development team discuss how best to prove functionality. Scope, scenarios and test data are some of the things covered here.

Nothing is ever perfect:

-          Do we understand what is testing what?
-          With developers writing automated tests is this them testing their own code? Is this a bad thing if the testers/team are defining what those tests are?
-          You could spend a lot of time not actually executing code, but this doesn’t mean you are not testing

Why do we do this approach?

-          Provides us with transparency
-          Helps bake in quality from the start
-          Brings “quality is everyone responsibility” to life

Less time in front of the application doesn’t mean you are not testing, get a blend and keep it enjoyable.

Get everyone involved in order to build in the quality form the start.

Lesley Walkinshaw – Thinking independently together

Diversity in testing is important, are we facing a diversity crisis?

Some of the problems in this industry at the moment:

-          There are around 600k open tech roles
-          There is lots of competition
-          The cost of recruitment is high

We had a look at some stats:

-          Diverse companies outperform non-divers companies by 34%
-          People who feel they can be themselves at work are on average 12% more productive. A good example of this is Gay employees who remain in the closet are 10% less productive than those who are able to be themselves.

If an organisation stubbornly refuses to change its predominantly “straight-white-male” ways, then it will be increasingly difficult to recruit.

We went back in time a little to look at two ways of working:

Waterfall – Having to work in silos, lack of test involvement. This will encourages bad behaviour because if a spec is written badly you don’t start from good foundations on a project. Waterfall also gives a feeling of a blame culture passing off the responsibility to somebody else.

Agile – Is collaborative, you get the sense of a common/shared goal, it creates a much better learning environment where you can continuously improve your ways of working. You are able to deliver what is wanted, you are empowered to make more decisions and to be a part of the whole process. This is motivating!

What has this got to do with diversity? Lesley brings the ways of working and diversity together… they are the same thing.

Diversity is about how we attract everyone to an organisation and not treat them badly, make everyone comfortable and together you can work for success.

Be a role model, mentor/coach and make it an open an inclusive environment.

Your future is created by what you do today, not tomorrow.

Jenny Gwilliam – Software Testing, A trip down memory lane

What was testing really like back in the 80s?

Even back then you had to expect the unexpected, things did go wrong!

As you can imagine, everything in the 80s was manual, working in the industry today can you imagine having handwritten tests stored in a folder? Having files on a trolley that you needed to manually feed in to a processor? Spending the last part of you day writing up a defect report that actually got marked like you were at school?

Well, this used to happen!

Lots of things haven’t changed:

-          Acceptance criteria
-          Planning, Preparation, Execution and Reporting
-          The Squeeze, all testers will experience this at some point
-          Defects
-          The need for testing
-          Lots more…

But lots has changed:

-          Automation
-          Inclusivity, think test first and code second
-          Qualifications over experience
-          Tooling
-          Types of testing
-          Documentation does exist
-          Lots more…

One thing to remember, everything we do from the start is still testing whether or not its static or dynamic, this is still very important to remember.

It’s hard to believe that the first software test team formed in 1958!

-          1981: IBM personal computer goes to mass market
-          1984: First testing industry conference
-          1985: Windows 1.0 & Excel released
-          1986: V-Model published
-          1987: First defect tracking tool released (DDIS)
-          1987: CA7 job scheduler widely used
-          1988: Exploratory testing became a thing
-          1989: First version of Load Runner

Who else is thankful for the resources available to us now? I am…

Ash and Gwen – Four hour test workshop

I’ve been lucky enough to have the four-hour tester overview at a previous conference - you should take a look!

Let’s agree that we would never agree what the core skills of a tester are…

The 4-hour tester is a way that focuses on simple exercises that take at most one hour to complete. The format is quite simple: briefing, exercise, evaluation.

Ash and Gwen decided that we would be looking at YouTube, as a team writing down all the Data elements i.e. Comments, Likes, shares etc. with help from the heuristics cheat sheet:  taking notes and taking the time to reflect.

Fantastic exercise to allow you to elaborate requirements, test and document!

Try it…

Panel – Jurassic park

There are many ways to make testing fun and to get you thinking… why not use a film where we can all agree lots of corners were cut!

We watched mini clips from the film with the aim to openly discuss how the specific scenario could have been better tested and where in the project could they have been prevented/mitigated.

Ok, so it’s pretty hard to give you an example on paper… watch the film and pull it to pieces J

There was one scene where they breed female only dinosaurs to prevent them reproducing! Remember that? No! I’ll go on anyway. One ended up being male! This whole scenario was based on an assumption that something would work, and no mitigation was put in place for something going wrong.

We watched many clips and it highlighted so much to discuss, security issues, lack of communication, bottle necks, blame culture and much more…

What a great exercise to get your mind working!  

Defend the indefensible

What a great way to end the day! 30 seconds to defend a statement you just don’t agree with… there were some funny ones!

“Testers end up being scrum masters as the realise they are providing little value to the team in their current role”

“Ops people should stop whining and just do what development teams want, no questions asked”

“Testers will always be needed as the quality of developers is in terminal decline”

Its good fun, you should try this J

Overall, fantastic day and I can’t wait for the next one… Maybe I’ll submit a paper and speak!


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …