TestBash was true to its name! It was a celebration for testing folks to bounce around ideas in a safe environment, get inspired, get creative and most importantly meet awesome testers from around the world.
The conference day kick started with Lean Coffee at Brighton Dome. Armed with post-its, pens, coffee/ tea, everyone seemed to be enjoying themselves in the round table discussions. The main conference followed the Lean Coffee which comprised of 10 talks with lots of interesting concepts. Find the schedule here.
One of the skills I am working on this year is to improve note taking and reporting. I have adapted the Cornell note-taking method from a Whiteboard testing video to serve my purpose and I tried it out for the talks at TestBash. I found it useful. I would love to hear about your note taking methods. So please leave a comment.
The talks were recorded and will soon be made available. Watch out the Ministry of Testing space. This is a long post with my notes from the various talks. Read on if you are interested…
Talk 1: Building the Right Thing: How Testers Can Help – Lisa Crispin / Emma Armstrong
The key take away from the talk was about how to deliver what customer wants and not what we think the customer wants.
The talk started off with a fun activity where the audience were given a sheet of paper and asked to build something that flies through air without providing definition about how the product should look, how the flight of the product should be etc. Most of us took time and created paper airplanes…But we could have quickly crumpled the paper into a ball.
How can we learn faster, learn to build the right thing? Lisa talked about helping customers look for value, find the thin slice to build, measure, and learn. Lean startup was mentioned in reference to reducing the feedback loop.
One of the important traits of a tester is to look at the bigger picture. Emma gave an example of six blind men and an elephant while talking about accepting different perspectives to put together cohesive goals. As testers, we need to keep bigger picture in mind and engage whole delivery team, customers and stakeholders to succeed incrementally and iteratively.
SMART goals must be set where SMART stands for:
7 product dimensions by Gottesdiener and Gorman is useful to think about the different perspectives
- User: who are our users?
- Interface: how are users going to connect to the product?
- Action: what is the product capable of doing?
- Data: do we have test data? what data is persisted?
- Control: legal questions need to be checked with appropriate people
- Environment: where will the product be used?
- Quality attributes
Example mapping was suggested to
- elicit requirements
- reduce uncertainty
- test peoples’ understanding of the requirements
I found https://cucumber.io/blog/2015/12/08/example-mapping-introduction a good read about example mapping.
While building the right thing, there should be a loop for experiment, measure and learn which can be done by
- conducting retros
- embracing changes and adjusting tactics
- engaging whole team in building quality in
- accepting that even when we fail, we learn something
Talk 2: Testing or Hacking? Real Advice on Effective Security Testing Strategies – Dan Billing
It is common to hear about security testing being outsourced, considered a non-functional requirement or out of scope in projects. However, security is inherently a functional issue since it directly affects the product’s functionality says Dan.
An interesting quote from Dan was “Hackers are a user, a customer, just an unwanted one“. Hackers definitely deserve to be a persona in our projects!
Dan’s advice on effective security strategies were invaluable.
- Understand the userflow. It is useful to know our stack since the hackers can attack at different levels.
- Even when we try to protect ourselves at different layers there are always weak points and hackers tend to find this out. This can be compared to how predators have adapted themselves in attacking crunchy shelled armadillos at their weakest points.
- Power up your security testing skills to learn about underlying architecture, web services etc. – OWASP cheat sheets are a great place to start.
- Use tools effectively since they are in abundance for security testing. It’s just a matter of learning and using them.
- Scan using tools like ZAP and Burpsuite -> Verify/Challenge -> Explore using tools like bugmagnet, fuzzing tools on APIs.
- Be occasionally evil.
- Target security testing, e.g. Do not target the whole site, but look for a small area first, like trying out a new paint colour.
- Think about security testing in context of the entire system. Don’t do it alone. Get feedback from other testers/developers.
Talk 3: A Pairing Experiment – Katrina Clokie
I love pairing with my team members during exploratory testing since I have found that there is always something to learn from each other. In this talk Katrina narrated her experience in implementing pair testing at her workplace providing us with pairing ideas and practical ideas to experiment.
When Katrina joined the company, she found the testers isolated in their own bubbles i.e. they were unsure about whether they were doing the right thing in testing. Based on the pairing experiment that Katrina carried out, it was proven that pairing can be efficient and useful.
The picture below is a suggested way of pairing by Katrina.
My key takeaways from the talk were:
- Pairing is a high creativity activity for focussing and generating ideas about the same problem.
- Pairing can be a great training tool for transferring skills. It explodes the isolation bubbles and aids collaboration.
- New first impressions bring new ideas to bounce things off.
- Pairing can help people ask more questions and make fewer assumptions. It improves communication.
- New tools may be learnt and practised during pairing experiments since it provides a safe environment.
- Collaborative coding dojos is something I need to look into.
- Care should be taken about not making pairing a demo session.
- Pay attention to influencers while deciding on pairings so that the influencers can provide a good experience to their partners who can in turn influence partners they pair with in the future.
Talk 4: Model Fatigue and How to Break It – John Stevenson
I liked John’s creative presentation style. It was a short and sweet talk which started off with a techno! The theme was that everything is a remix; we continuously change, adapt and remake. Watch the video when it is made available – its great.
He shared his experience about using test models and suggested to constantly challenge the models we use rather than getting comfy or resist change.
Key takeaways for me were:
- Decide yourself, don’t let someone else dictate. Do what works for you.
- “Just Do It” and take the blame or credit later.
- Failure is success if we learn from it – if you don’t identify changes and continue as normal, then we haven’t learnt from our failures.
- Take models, change them and make them your own. Diversity matters. By this you may find more bugs some of which may already be live.
- Resist. Change. Adapt.
Talk 5: Accepting Ignorance – The Force of a Good Tester – Patrick Prill
Patrick’s talk was motivating! I liked his definition of ignorance in testing context which was inspired by Socrates and Firestein – “To be aware that you have insufficient facts, skills or understanding about a topic and remain curious to constantly improve and further discover what you don’t know“.
He spoke about James Bach’s challenges about redefining well known labels in the industry. For example what is integration testing? He asked questions like “do you have a dictionary within office workspace?” which is one of the common problems I stumble across at work.
Key takeaways from his talk were:
- Be aware of your borders of knowledge.
- Look into the work by Alexandra Casapu to create a repository of your testing skills. Use testing skills to find borders of your skills! See also http://www.testacious.com/2015/11/04/purposeful/
- The stuff you don’t know should be what drives you.
- Discover what you don’t know, who you can help and who can help you.
- Beware of psychological effects from ignorance
- Be a swamp of knowledge
- learn as much as you can
- some knowledge might help grow other knowledge
- When you have questions such as “What did I not test?” crop up in your mind, think about what you would test if you had more time to test. You would need skills to explore the unknown. Mind Maps are a great start to explore the unknown. Let random thoughts be captured since they are often insightful later. Maaret had suggested something similar during lean coffee. Asking newbies to draw out mind maps during their exploratory testing would help mentors to assess areas that were untested which is important to drive further exploratory charters.
Talk 6 – Test/QA a Gate Keeper’s Experience – Michael Wansley
Michael captivated the audience with his amazing stage presence. I didn’t even imagine that he was a first time conference speaker.
The topic was controversial but he supported his perspective with confidence which was impressive.
Key takeaways from the talk were:
- As testers we need to be aware of the beginning and the end of a product lifecycle.
- Whether or not you accept the “testers as gatekeepers” depends on what you think is behind the gate.
- Always know where you are in the process. Testers are gatekeepers since they should know what’s going on with the product – the right and the wrong.
- Product should be simple such that our grandparents can use it.
- We are the last line of defence.
- It is sometimes dangerous to know too much. It is good to feel like a newbie or have fresh pair of eyes looking at the product.
Talk 7: Having All Your Testers Code: It Doesn’t Have to be a Big Deal – Anna Baik / Andrew Morton
Anna and Andrew narrated their story about how they introduced test automation in their company when there wasn’t enough time to learn.
Below are a few quotes and advice from the talk:
- You need skills of pairing well. Pairing is a great way of learning, teaching and getting stuff done in a productive manner.
- Use pairing in teaching
- Give people the tools, resource and time to learn
- Get a test into CI as soon as possible. It makes a huge difference.
- Setting up CI requires different skills. Spread it across the team. Don’t let it be done by a key person.
- As long as we are all heading for the same destination, we’ll keep learning!
- Don’t choose an unpopular tool when trying to learn something new since it’s too hard to get info or help.
Talk 8: Do Testers Need a Thick Skin? Or Should We Admit We’re Simply Human? – Nicola Sedgwick
Kudos to Nicola for presenting her vulnerabilities and challenges of being a caring and passionate tester to a huge crowd!
For me the key takeaways from this talk were:
- A tester is not just an info provider, but a human who works with other humans to build amazing products.
- Stress can be a blessing or a curse based on how you cap it.
- Do not blame yourself if there is a bug found in production. You did not CODE it in there. Testers are humans too.
Talk 9: Smart Algorithms – Are We Ready For This? – Bill Matthews
Testing something complex is a challenging task and so would summarizing Bill’s talk! I would highly recommend people to watch the video when it is made available.
There were way too many questions coming up in my head since I could relate to several things he mentioned with my current work. So I will try to write up a separate blog post about this. Watch this space.
Talk 10: Nowhere to Hide: Adjusting to Being a Team’s Sole Tester – Nicola Owen
Nicola shared her experiences about how she adjusted from working in a group of testers to being a team’s sole tester. It was inspiring to see a young tester give a talk at the conference.
Phew! That was a long post. Good to see you are still reading.
Besides the lovely talks, it was great to finally map real faces to twitter handles, talk to them and also make new friends. The discussions we had at the social meetups were all constructive rather than having a battle about what is right or wrong. It was fun-filled day of learning. What more can a tester ask for?