Some really big news, I’ve been selected to give a talk at Test Bash Manchester in October. My talk will be on record and playback features in test automation. I will be discussing how they can be useful for testers with little experience or a great deal of experience in test automation. I will also demonstrate how tests generated using record and playback can be adapted and improved. It is a really exciting opportunity.
I’ve written articles about this before for testproject.io. I look forward to exploring this subject more throughout the year. In particular, I plan to explore how different automation tools use record and playback and how easy it is to adapt them.
Ask Me Anything – Whole Team Testing with Lisa Crispin
This week I watched the brilliant webinar in which the testing community was given the opportunity to ask Lisa Crispin anything they wanted about Whole Team Testing.
All questions that could not be answered during the webinar were shared on the club and answered at a later date. This included an answer to a question that I asked:
The following blog post includes a summary of some of the questions that were asked and answered during the webinar:
Test talks podcast – What is Programming with Edaqa Mortoray
Do we actually know what programming is? In this podcast episode, Edaqa Mortoray discusses his book ‘What is Programming’ in which he attempts to answer this question. He talks about how programming is not the lone activity that some think it is. It should be a social activity that includes communicating with fellow stakeholders. This is demonstrated in the way the book is split into 3 sections: People, Code and You.
- People are the reason software exists.
- At the heart of any software is source Code.
- Behind the screen is a real person: You.
Test talks podcast – Discover The Personality of Your Application with Greg Paskal
In this episode, Greg Paskal suggests that we should not just be looking at the way tests pass and fail. When running daily tests, we should look at their behaviour over time in order to identify issues that are often overlooked. For example, a test may gradually take longer to run. Monitoring this over time could provide an insight into an emerging problem.
Test talks podcast – Chaos Engineering with Tammy Bütow
This is something I’ve not heard much about before. In this podcast episode, Tammy
Bütow explains what chaos engineering is and how it has been used to identify issues in a companies ability to recover from disaster using methods like fault injection. One example that was discussed was Netflix’ Chaos Monkey application.
The Good, the Bad and the Buggy – Season 2 recap
A recap of all the previous episodes. This episode discusses how different technology has improved the user experience and changed the way we do things in certain industries.
The Guilty Testing 11 – 7 ways I sabotaged myself as a testing
This episode was inspired by the UKSTAR 2019 talk by Claire Goss (Testers: Is It Our Own Fault We Are Underrated?). This episode provided a list of ways in which testers might be sabotaging our own testing efforts. One which interested me was the idea that developers should not be developing a new feature until it has been tested. Allowing demos to take place gives the opportunity for stakeholders to provide early feedback. Testers aren’t the only ones who should be assessing the quality of the software application.
Logging, Monitoring and Alerting with Kristin Jackvony
I’ve been looking into how logging can be used to aide our testing efforts. This article defines logging, monitoring and alerting and discusses how each can be used to benefit the team as a whole as well as testing.
Testing the Adversary Profession! by KimberleyN
KimberleyN decided to reshare this blog post which was originally published last year due to Lisa Crispins Ask Me Anything webinar. This post discusses the relationship between developers and testers and why some bugs may find their way into production. Reasons suggested included fear – fear of starting an argument or making enemies by reporting bugs.
For Just a Few Lego Bricks More by Michael Fritzius
An interesting analogy to explain how modular approaches to programming are recommended. There are usually only a small number of standard designs of lego bricks, and each one fits easily with the other design. This allows the same design to be reused millions of times. The same goes for programming. There should only be a small number of standard functions which can easily connect with the other functions.
Other blogs that share lists of test related articles
Feel free to recommend anything that you think is of interest.
Main image taken from http://www.publicdomainpictures.net