Sponsored Link
Applying Object-Oriented Programming Principles to Test Automation Design
Do you want to learn the best test automation design practices? Join Angie Jones on August 12th, as she discusses the four pillars of object-oriented programming in test automation, and start writing automation code like production code. Save your seat now.
applitools.info
NEWS
10 Reasons Why We Really Don't Need Test Cases
You might have heard that detailed test cases are a waste of time. Why? Brijesh Deb provides ten solid reasons for that.
And here's another one from Maaret Pyhäjärvi who shows The Most Overused Test Example — Login.
medium.com
Eight Signs Your Agile Testing Isn’t That Agile
Many teams claim they do agile testing but not many do it right. Blake Norrish put together a really good list of common anti-patterns that occur fairly often (unfortunately).
medium.com
Feeling Testing
I love the way Maaret Pyhäjärvi explained the relationship with testing varying on the point of view. So simple and so true.
Additionally, James Thomas gives a great example of how to ask the right questions in Mass Testing.
blogspot.com
How I used communication to overcome 4 challenges as a test automation engineer
How important is communication for software testers? Very. Sérgio Martins gives a few valuable pieces of advice that can help you win in various situations.
Speaking of which, Edib Imamović explains how to Report a bug like you mean it! in a cool way.
medium.com
We need to talk about testing
This is an amazing, thought-provoking article from Daniel Terhorst-North — the inventor of BDD with 30 years of experience in software development — discussing what testing is, what it isn't, and what practices such as TDD, BDD and ATDD have to do with testing.
dannorth.net
What I learned from Mabl’s State of Testing in DevOps report 2021
Two weeks ago, I linked to the State of Testing in DevOps report. This inspired Beth Marshall to analyse and share what she learned from it. Thanks!
Similarly, Bridget Hughes shared some insights about The Changing Role of Software Testing based on the same report.
beththetester.com
AUTOMATION
All About Automated Tests — Part 1: Excuses
Mark Walsh correctly points out that many engineers still don't write tests for production code. And they find plenty of excuses for that, all of which Mark debunks here.
dev.to
Can Automated Execution find defects?
Sounds like yes is the obvious answer? Well, Alan Richardson might surprise you in this case. And I agree with him entirely.
eviltester.com
REST API Automation From Scratch
This is a very detailed guide to REST API testing by Abhishek Chauhan, including plenty of examples.
And for an equally comprehensive read, have a look at Handling REST APIs by Pricilla Bilavendran.
testproject.io
Scaling-out End-to-End Tests with 7Facette & Playwright to Infinity
Interested in testing serverless apps? Patrick Döring shares code examples showing how to test them using two open-source tools: 7Facette and Playwright.
And for more about serverless testing, check out Andy Blackledge's latest article on Step Function integration testing with CDK.
medium.com
Why Naming Tests Matters?
A good test doesn't only check for the regression bugs but also acts as a form of feature documentation. This is why it's important to do the naming well, as Dawid Sibiński explains.
yumasoft.pl
TOOLS
5 Things to Avoid When Writing Cypress Tests
If you're just starting with Cypress (or a similar web test automation tool), here are the key things to look out for. By Ashutosh Bhardwaj.
Moreover, Gleb Bahmutov shows a few examples of how to Avoid Cypress Pyramid of Doom.
webiny.com
A Guide to Appium — Our Top 10 Appium Tutorials in 2021
Danny Shain did a big favour to all Appium fans here by putting together this list of articles and guides on writing effective mobile tests.
applitools.com
Mobile Automation Test Frameworks
And if you want to learn about other mobile testing frameworks, Archana Jayappa and Lalitanand Dandge listed the pros and cons of the five most popular ones.
medium.com
BOOKS
Book Review and Highlights: "Accelerate"
Kislay Verma shared a nice summary of each chapter from the popular DevOps book: Accelerate: Building and Scaling High-Performing Technology Organizations.
kislayverma.com
Book Review: "Designing Data-Intensive Applications"
Here's a nice overview by Oleksandr Romanov of the Designing Data-Intensive Applications book about data storage, delivery and distributed systems.
github.io
VIDEOS
Can a Manual Tester Survive Without Automation Knowledge?
It's not all about automation, as Pramod Dutta explains in this short video, sharing a bunch of valuable tips on what manual testers can do to stay relevant in their field.
youtube.com
Video: The Cost Of Bugs
Referring to the theme of today's issue, here's a 2-minute video presenting Gil Zilberfeld's opinion on the cost of bugs. Good timing, Gil!
everydayunittesting.com
Sponsored Link
Future of Testing: Mobile @ August 10th
Join top engineers from Microsoft and Suncorp Group in a free virtual event to learn about cutting-edge tools and practices in mobile testing, automation, release strategies, and multi-platform integrations. The line-up includes industry experts such as Angie Jones, Sam Connelly, and Anand Bagmar, just to name a few. Register now for free!
applitools.info
AND...
Thanks for reading!
If you like this newsletter and it helps you become a better tester, you can say thanks and buy me a coffee.
Dawid Dylowicz
Welcome to the 82nd issue!
A few months ago, I mentioned the article about how Facebook is finding and fixing regressions faster stating that the later the bug is found, the costlier it is to fix.
If Google, Facebook and some research papers say so, why wouldn't it be?
Well, here's where it gets funny.
As it turns out, the most-quoted research about the cost of a software bug is not even existing! And there's more. Hillel Wayne explains that many others are full of bad assumptions or errors, too.
So, how is it? Are the late-spotted bugs costlier to fix?
It depends.
We've learned it's hard to prove or deny scientifically. But I still think testers should be involved in the early phases of the software development life cycle.
Spotting an invalid requirement when it's still on paper is — and always will be — cheaper to fix (in terms of both time and cost) compared to finding out about it when it's already delivered.
This is common sense. We don't need research papers for that.
Happy testing!
Dawid Dylowicz