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:
Ministry of Testing
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
- The need for testing
- Lots more…
But lots has changed:
- Inclusivity, think test first and code second
- Qualifications over experience
- 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 - http://www.fourhourtester.net/ 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: http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf taking notes and taking the time to reflect.
Fantastic exercise to allow you to elaborate requirements, test and document!
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!