Wednesday saw the only full day of talks. I definitely had the “I don’t want to miss anything” worry but took the advice that was given and had a session out and stayed in the test lab after lunch.
There I was hoping to meet Anne Marie Charrett for the first time but unfortunately she was not there. I had a go at her robot testing challenge anyways and pair tested with a lovely Norwegian tester.
You can find some snippets and contribute your own in the forum here.
The day however started with a very honest keynote:
Isabel Evans, Dolphin Computer Access
The emphasis was that we all make mistakes and how we can be recovering from set backs.
One big new take away for me were the influence diagrams – why things have happened and why things may happen – These don’t describe cause and effect but can be really useful in determining where a process is going wrong.
Isabel’s tale was about improving testing at a company. But it became clear very quickly that the problems were routed a lot deeper and the whole picture needed to be addressed.
She started by increasing defect recognition because the business gave the impression that it is not a good thing to find defects as defects hold up the release.
There was re-educating needed for the whole company on what the purpose of testing is.
To help the transition she demanded to sit with developers and made everyone work together including product owners to improve the beginning of the lifecycle also.
Improvements can make the situation worse:
increase of backlog
more pressure – more mistakes
better quality but longer to market
don’t just improve testing – all areas need looking at
greater workload means more mistakes
restore to factory settings when things went bad – need to push through the painful changes to be efefctive
3 types of people:
Change is hard and painful for all. And all will reset at any stage if things get too hard.
It became clear that trust needed to be established as she was not the first person to introduce change.
Key root causes needed to be identified:
fear of management
complexity of problem
desire for fast action
not a meeting/communicative culture – no discussions as they waste time
more time needed
globally change the way we manage and communicate
regain trust if change initiatives arent working
expert leader not always a good coach as they don’t understand when people don’t understand
we need a plan – vision as you don’t build a fire engine after we have had a fire
Management saw agile as a magical solution – but is it just a magical word?
Because pain is hard it needs to be managed, there is a right time for each type of change and people need to be given time to get used to change – maybe wait til they make it their idea
Leadership does not mean lead in front – let people make mistakes and then help them and guide alongside their own pace.
Every Tester Has a PRICE: Sources of Product and Project Information
Michael Bolton, DevelopSense, Canada
I am unsure if I have seen Michael talk live before so I chose his track next. Until the end I was guessing what the PRICE bit stood for.
Where do I get information from to test with? When have you felt like you did not have enough information? Michael then made the session interactive writing ideas from the crowd down and then organising them.
I liked the explanations of implicit and explicit knowledge.
As testers we need to learn to appreciate the implicit knowledge as well.
Explicit vs tacit – explicit is shown and expressed-tacit is more assumed – not shared for some reason.
Tacid knowledge – 3 kinds:
relational tacit knowledge is in people’s heads – assumed too obvious – ie the address of the school of your kids but you know where it is and how to get there
submatic tacit knowledge – embedded in the human body – juggling – needs practice
collective tacit knowledge – embedded in society
Side note: It made me laugh when Michael called the cloud the fog.
What we require from a product cannot be completely written down. For example products should have charisma – what this means is embedded in tacit knowledge.
Rayification – turn something abstract, a concept, into a thing.
Can we fully ever write down a test? He says we can only write down checks, as a test is all the things we may do or think or our decision process – we can only ever encode some of it onto paper.
Can we test the product without it in front of us? – as soon as we say/think “what if” we are testing
We can test the idea of the product through thought experiments.
Testing is learning about the product?
Are arguments and discussions just testing ideas?
What did the PRICE stand for?
Nathalie van Delft, Turien & Co. Assuradeuren, Netherlands
I first met Nathalie at expo:QA about 3 years ago! She still remembered me! Shows what an awesome lady she is! Why not discuss your innovations on her thread in the forum?
My main take aways where the whiteboard of wisdom that I want to try.
Change has to happen at all levels and this would be a nice visual way to share knowledge across all teams.
Change is also about awareness – choose a champion object, something we all understand – then make the team commit to using the same object and message.
One team approach!
People follow expectations – they won’t be inspired or motivated if not stimulated or challenged.
Motivation is built on goals – set a common goal.
Educate the individual to bring together the team.
Don’t just do something – let people know – echolalia
Fran O’Hara, Inspire Quality Services, Ireland
Being a tester on an agile team for the first time I chose Fran’s talk.
Focus on value over plan and embrace change.
Lots of planning in agile but need to understand the plans are lightweight and dynamic. Cannot base expectations on them alone.
Quality is not automatic – agile simply provides an opportunity to re evaluate the quality more often.
We can facilitate a better balance between verification and validation during the agile development process.
One side effect of fast development is technical debt which can easily bite us. He likened it to a financial loan. Initially we feel the benefit of being fast but in the long term the technical debt will slow us down and make development hard.
Technical debt symptoms:
bugs in production
hard to maintain test
Testing mindset – quality is not equal to test – Quality is mixing development and testing
How do you add value? support the whole team from PO to devs.
At release level are we thinking about the whole picture? we generally just dive into the sprint – only story level not interaction – need to consider interaction of all systems.
Lack of strategy for testing – don’t be prescriptive but consider the context – lightweight.
DOD make sure everyone is aware – shouldn’t be static but be reviewed regularly.
Cross functional teams – test competency addressed by placing a tester in? no! need right level of test competencies and sometimes this requires outside help or help from other developers.
Are stories too big?
Everyone is a developer – even testers and POs!
Testers need to prevent issues rather than detect them.
After lunch I had to have a timeout, so I sat with the test lab and did a pair test on some robots. We were set a mission and completed it for the little robot but not the big one in the time we had.
I did like this exploring technique though.
Innovative Testing for Take-Off
Christian Mastnak, ANECON Software Design & Beratung G.m.b.H., Austria
How to test an airport!? I went to this talk because I used ti live in Vienna and last year I lfew into terminal three and may have even flown home from it. So this was a fun anecdote of combining software testing with a construction site.
When construction is involved end to end is only possible at the end! This means the project was waterfall inclined with a 2 year plan phase. Most of the software came from various vendors and needed to interact with each other.
What was interesting is that the vendors were given the opportunity to test their software interacting with the other software but they chose not to so Chris’ team had a huge task.
Also they made the most of what they had learned by training the other airport staff on the new system which I found admirable.
I love the idea of paying 400 students to simulate passenger flow through the airport and that the tools the testers used are now being used by the security staff.
It was a nice change of pace and fun to listen to. I hope I also get to do something like this one day even though it sounded super challenging.
Declan O’Riordan, Testing IT, UK
My company is moving to a service orientated architecture which means I took in interest in security testing recently.
The talk started with a harmless prank where an autocue was hacked on live TV of a news show.
Often you find the security team only working on network and host security and web application is ignored.
The web was not designed to be secured – by default it is vulnerable!
In development security is an afterthought more often than not. We need to shift this and be more defensive when coding and more assertive when testing.
As much as it is a specialised industry we can do small simple things!
Actually I had a lightbulb moment during this session and understood SQL injection! So for most of the talk I was thinking about this and how to apply it first thing Friday! Oops.
Fran was a great speaker and happy to share his security documents, so be sure to give him an email to get his documents which he is happy for you to adapt to your contexts! How amazing is that!?
Julian Harty, Independent Consultant, UK
Julian is a great speaker and has an inspiring history of software testing behind him.
He stressed that by using monitoring tools we should not only monitor but also listen and act on our findings.
Analytics can help our testing as it will be more focused and less blind.
He works on the mobile business which is very new to me, so it was interesting to listen to the challenges of his industry and how a flashlight app used to reveal sensitive data in its analytics!?
SideNote: Before the keynote we saw an employee from smartbear sing:
Yes he covered a song from Frozen!