We are all a bit lazybones, or at least looking for the most effective way to do our daily tasks. Looking at my Roomba robotic vacuum cleaner, I have been thinking today that in terms of domestic cleaning, automation has just as many
advantages than disadvantages in the field of software testing, and that it quickly shows its limitations.
Evaluating a Software Tester with a hiring process is not easy. A very experienced candidate with a resume apparently fulfilling your needs might be a very bad team member. Unlike a newbie with the right mindset, the will and a true passion who will become an asset to the project and the team.
What should you do to avoid the former and not miss the latter? The question is interesting, and no single answer exists but I suggest you a series of articles to help thinking about this and find the proper tactic.
I was at the MiXiT conference in Lyon last week to co-host a workshop/game with Ard and François using TestSphere that the community of testers (at least those who follow the Ministry Of Testing news) can not ignore.
The workshop is structured around the card deck which has several categories (techniques, heuristics, feelings, quality aspects and patterns) and each card describes an idea that helps the participants to think about a story they have to tell.
Testing an open source project has some advantages compared to proprietary softwares:
- everything is public and can be shared with anyone interested
- you can communicate about your project, issues and features with no fear
- you can use tools that are free only for open source projects (like Atlassian suite, Saucelabs…)
- you may be helped by contributors and benefit from the community of open source lovers
Mobile phones are everywhere and almost every service in the world has its own application. If not, the website is responsive and can be used on a small screen with bad network, and not only on your desktop with a fiber network. As a tester of a website or an Android/iPhone/WinPhone application, you need to test it as a real user, meaning on one or more smartphones or at least on the most used by your users/customers. It includes manual and automatic testing though. What if you don’t have one billion €uros/$ollars/£ounds to buy all the smartphones needed to be tested? Will you rely on Chrome dev tools for browsers application, knowing that developers already “quickly” test their work with it?
Here are the reading recommendations collected these last 15 days.
Is manual testing dying? Is manual testing dead? When manual testing will be completely replaced by automation? Or is it “Manual testing” vs “Automated testing” that is dying? This blog article by Albert Gareev tries to give answers: Automation beyond blog.
This is the fourth and last article of the series about cognitive biases. Please start with this first article if it’s not done yet: Manage your biases as a tester Part 1. In this last one, we’ll see some biases of the category “What should we remember” of the Buster Benson‘s categorization according to his article
What should we remember?
Something very positive will generally have less of an impact on a person’s behaviour and cognition than something equally emotional but negative.
Be careful not being too negative about someone else work, because it will have a greater impact on people than the opposite positive words. Because of the “Ikea effect”, everyone is very sensible about his own work and want it to be appreciated, not criticized. We, software testers, have this responsibility to be good communicators in all circumstances; for good news, but also for bad news. Also, giving some empathy will always be rewarded.
In the first part of this series dedicated to biases, we saw a list dedicated to biases due to “Too much information“. Then in the second, some cognitive biases due to “Not enough meaning“. If you didn’t read them yet, I suggest you to start with these two articles before this one. In this third part, we’ll see that the “Need to act fast” can also lead to some biases.
Need to act fast
Theory which suggests that people typically adjust their behavior in response to the perceived level of risk, becoming more careful where they sense greater risk and less careful if they feel more protected.
As a Software tester, you may feel more protected if you know that a lot of unit tests, integration tests and end-to-end tests are running on each build (and that they are green and enabled), but that doesn’t mean that there is no risk to evaluate in the new version, in particular if new developments have poor unit testing, useless integration tests and no end-to-end tests. You may have more checks and at the same time may have to be more aware and cautious with what is candidate to release. Please try not to compensate the risk.