You are here

Short tracks

Flaky Tests - Getting out of the Re-Run Cycle

If you have written and executed automated tests you have seen them doing their job very well, but most probably you have also seen some of the tests both failing and passing on the same code with no apparent reason. The kind of tests that give both failing and passing results on the same code and configuration are called flaky(nondeterministic) tests. Having flaky tests in your testsuite will make your tests unreliable and eventually they will lose their value. When you can’t trust your tests, why do you execute them at all?

During the presentation I will share real life examples of the steps that can be taken to reduce test flakiness and the amount of time spent on handling flaky tests.

Key takeaways:

The attendees will walk away with the following practical tips:

  • how to identify flaky tests how to reduce test flakiness
  • how to live with flaky tests (there will always be flaky tests, but it is possible to make them easier to handle)

Power of Orthogonal Pairing in Devops Quality

One of the changes between testing in a DevOps environment compared to testing in a more classical agile, or even waterfall is the ability to test and learn about the product in all phases. We don't so much follow the development and test sequentially but instead learn and analyze simultaneously from many angles. This provides a whole range of new opportunities to increase value provided, but also presents a lot of new mind sets and perspectives to assimilate. We realize that we provide, or limit, quality and value for all kind of users and crew. Do we know how to test deployment pipelines, monitoring tools and server fallback routines? One of the ways to get up running fast is to sit together, and collaborate.

Some but not all have been pairing like this for a long time within the team. We pair with other testers to share knowledge, we pair with developers on testing and coding to learn about the code and share testing mindsets.

Now we also get the opportunity to pair with so many others! Management, operations, marketing or IT-infrastructure teams and any other departments you have. Sharing knowledge is a goal, but pairing and tight collaboration also helps to build bridges. Closer and more personal relations and a shared language reduce friction and increase the momentum for change and improvement. They say that to know someone you should walk a mile in their shoes, so let’s do that. And also let them try on yours. Spend an hour and do what they do, and you will both see new ideas. For instance: Pairing with management and product owners made it easier for them to express their needs and see possibilities, but also taught me the importance of translating and express ideas, wishes and problems into dollars and cents. Pairing with customer support resulted in the design of a tool for express change requests, reducing their queue-times for unexpected problems and allowing the development team an new insight into day to day problems. Also, when invited into a bug bash they reported a new record of found bugs, clearly showing that our channels for internal communications where too much of an hassle for them to report through before.

Key takeaways:

  • Tips on how to get effective pairing sessions with other professions.
  • How to become a better tester by learning other jobs.
  • Why bouncing ideas in orthogonal directions generates value.
  • Pairing and learning is fun! Let's do more of it.

House of Cards - Software Testing Lessons from Frank Underwood

House of Cards is my favourite TV Show. It depicts the US politician Frank Underwood, and his struggle to gain power and influence in American politics. Now while it might not be immediately seen as a natural place to learn about software testing, it struck me that a lot of the ideas and comments made in the TV series can be directly transferred to our world of software testing.

Having gone through a bit more systematically I've found a whole series of great quotes from several of the characters in the show that I've set in a testing context and will present in a humorous way.

The short track should be lighthearted and entertaining, despite addressing some real testing principals that everyone should remember. Having seen the show is not a requirement, but might make it even more entertaining. And I'll keep it spoiler-free for those who haven't seen it.

Key takeaways:

Entertainment repetition of good practices in software testing, a different view on house of cards, and perhaps software testing.

The Four-Hour Tester

The challenge of teaching new testers useful skills is something that many testers face – either you’re a manager, a test competence lead, or an experienced tester who coaches other testers. What would you need to learn and practice to become a tester in the first place? How would you pick the things to learn and skills to practice to help a new team member learn the ropes of testing and start adding value? If Tim Ferriss can come up with the 4-hour chef, why can’t we come up with the 4-hour tester?

Armed with the hypothesis that it’s possible to identify the core skills and knowledge for testers and that it’s possible to become familiar with those in 4 hours, Joep and Helena set out to explore and discover what that core consists of. This talk addresses the process of discovery itself, how they found the hypothesis to be or not to be true, and what they learned along the way. They will also present the results of the experiment as a set of heuristics in a framework that can help novice testers to learn testing.

Key takeaways:

  • Sometimes learning means trying something with minimal instruction
  • What the five basis testing skills are that we identified
  • Inspiration to try the exercises at and/or to develop something similar
Subscribe to Short tracks