Author: Gregory Paciga
The myth of “unstable” code
The most common reason I get for people delaying test automation is that the code is “unstable”, and automating too soon will result in a lot of re-work of automation. Better to only automate after a feature is “stable”, i.e. development work is all done, they say, so you won’t have to rework any of… Read more
Three ways that “Manual Testing” is a waste*
* when done at the wrong time, and depending on how you define “manual testing”. Callum Akehurst-Ryan had a post recently that broke down much better ways of thinking about manual testing, but I’m using it here how it’s used at my current company and presumably many others: scripted tests that have to be run… Read more
The Secret Skill on Your QA Resume
There’s a particular skill that is on full display in your tester, QA, or quality engineer resume that you may not even realize is there: the ability to be concise. The most common resume structure I saw this year went something like: It’s not an exaggeration to say that each one of those components was… Read more
Bad reasons to test
“Complete” testing is impossible, so we have to do the best we can with the time and resources we have. Often, that comes down to making sure that there’s a good reason for each test to exist. If there isn’t, then you should remove it and spend that time on something more valuable. When evaluating… Read more
You might not need to fix your flakey tests
There’s a toxic cycle that can be caused by flakey tests. The more unreliable tests are, the less likely you are to trust their results. At best, it means wasted time as people re-run a failing step in an automated pipeline until they get the result they want. It then takes 2 or 3 times… Read more