The first Swedish edition of SIGIST (Specialist Group in Software Testing) was held in Stockholm 23:rd of November. The organization has existed since 1989 and has previously organized conferences around the world, e.g. in the UK and in Israel. Have a look at their website if you are interested in learning more.
The conference was run over a day and had five different speakers in the line-up. In between the speaker talks, there were short organized discussions called “corner talks”. Preselected topics were distributed to the four corners of the room. All conference participants walked to the corner with the topic they wanted to discuss and had a ten minute discussion of the topic. The takeways from each corner discussion were then presented to the other groups. I applaude this effort to involve all participants in the discussion, but I found it hard to get much value from the discussions due to the time constraints. I would suggest that next time, the subjects should be more specific. Maybe all corners should discuss the same specific question/problem and then the takeaways from each group could be compared.
Now on to the speakers. First out was Jörgen Damberg. Jörgen stated upfront that his talk might be confusing to some since it really did not have a read thread. Rather it was a collection of things Jörgen had learned during his career. The topics varied from what quality is, to different good (not best) practices when working with automation or integration and working efficiently with other roles. Some takeaways:
- What is quality?
-Quality is hapiness
-Quality is subjective
-Quality is context sensitive (e.g feelings for the product could differ between morning and afternoon the same day, depending on the mood).
- Pool-ball vs floorball metaphor. The requirements for a product are like a floorball, an empty shell with holes in it. Our mission is testers is to make sure that the product delivered is more like a pool-ball, e.g. a solid object without holes.
- Tres amigos approach can be useful, i.e. bringing testers, deveopers and requirements together to get a collective grip of quality.
- What to automate: test data preparation, enviroment configuration and test execution. Other testing activities needs a human brain.
- When testing complex systemst try to de-couple and test things seperately, integrate in the end.
The next speaker in line was Rikard Edgren. His talk had the title: “Rikard´s super-good testing practices” and delivered things he has found being extra useful in his testing career. Rikard is a great speaker with lots of useful knowledge, and while I have read a lot from him in the past, I still had some great takeaways from his talk. Some of the things he brought up:
- Earning your respect by finding valuable information (aka finding cool bugs).
To find useful information: ask the customer what quality aspects/functional areas that he/she finds important. Use customers words when talking about and reporting later on. Even if something is not reportable since it is too vague(i.e. charisma bug), you can still talk about it at the coffee machine.
- Information objectives as testing drivers
Find out how often to report, how to report and what to report. Testing is not better than the quality of the reporting (loosely quoted).
- SFDIPOT mnemonic is great to generate test ideas and to reduce the risk to overlook some important area/aspect.
- Recycle and add to others´ models. Share your own for common understanding.
- When describing your testing, the essence often suffice, e.g.:
-One-liner test ideas
-One-liner test reports
- A good tester is often lucky (serendipity). But it´s not purely luck, rather:
-Good observation skills
-Rich test data
-Variation in running tests
After a good lunch it was time for the late replacement Samantha Peuriere. She summarized what she had learned from working as a quality coach (my own wording) in an agile enviroment. The talk contained a lot of great pointers, especially interesting for myself since I am transiting to an agile enviroment myself in the near future. Key points:
- Early feedback,
-Invite yourself to meetings if you are not invited (e.g. early design meetings etc)
-Open up test environment, e.g. for customers if possible
-Test with real users in sprint.
- Release often:
-More releases reduce risk due to fewer changes in each release. Since the next release is not far away you might also monitor in production, and fix next release.
-Remove waste (don´t repeat tests)
-Moving things out to production without passing QA is a way to remove the quality gatekeeper. This trick could be used for low risk changes if you need to establish the culture of “quality is owned by the whole team”
- Visualize work:
-Put strategies etc on the wall
-When in doubt, whiteboard it to resolve ambiguities.
- Quality is owned by the whole team
-Review test plans as a team
-Follow on late bugs found (learn from mistakes)
-Celebrate both mistakes and successes (removes blaming culture)
-Make quality fun (mob testing sessions, provide food :-))
- I´m here to make you look good
-Rename defect or bugs to feedback or rework. Less negative wording has big impact on conversations and makes people less defensive.
- Don´t get blocked
-Get help from the community
-There is always a way forward
The next speaker in line was Andy Redwood who talked about his experiences as a test manager for a large bank. Some takeaways:
- Some things are quick fixes, but some things take many years and iterations.
- Flexibility is key, everything does not need to go through the same test phases. Somethings can even be picked up in production if they fail.
- As a tester. attend some training in facillitating. Learn to gather a group of people at a witheboard and to extract information from them and then package that in a presetable format.
- One cool thing they had implemented was an automated process for problems found in production routed to the correct test manager enabled continuous learning and improvements.
The last speaker of the day was James Bach. James was as always entertaining, with a strong and well thought through message. Even though I had heard or read most of the content in some way before, James always provides some twists or interesting side stories to learn from. Some of the things brought up:
- Testing is not test cases. Talk about performing test activities instead of test cases.
- There are many layers to testing that affect the performance, e.g. tester temprament, current role in project, test design etc.
- Tacit vs explicit knowledge is important to understand. The testing activity cannot be encoded, e.g. described fully in written language.
- Putting words on what you do is important, to make other understand and respect your work, but also to understand yourself.
After James´ talk there was a panel discussion about the future of testing. The panel consisting of Rikard Edgren, James Bach and Andy Redwood agreed that testing 10 years from now will be roughly the same as today. James´ vision was that testing will have a higher status and that it will be a profession people will enter later on in their career, for example after having worked as a developer. An intersting local counterpoint to that idea is the specialized testing educations that we have in Sweden, which likely will draw in more young people in to the profession. The increased amount of testing services offered was also under discussion. The panel concluded that we will see more of that but that there are challenges in having parts of your testing outsourced, far from the development teams. The topic of artificiall intelligence was also covered, the belief here was that it will not have a big impact in the near future, but that we will see AI assisted testing in some areas (e.g. test design suggestions).
To summarize, I really enjoyed this first edition of SIGIST Sweden and I would gladly attend the conference again in the future. The low price combined with the one day format makes provides high value to a low cost. Hats off to the organizers for all the work they put in!