Software testing metrics can be very difficult: there are thousands of them out there, it is hard to know which ones are important, many are hard to collect, its often difficult to extract meaning from the metrics, and everyone has an opinion on the usefulness of any metric that you might choose. So, what is one person to do?
A Coach’s Guide to Agile Testing is part of the nice series proposed to Agile coaches by Samantha Laing and Karen Greaves. This book provides a complete plan to run a workshop where members of a Scrum team can understand and learn the concepts behind Agile Testing.
The “refactor” step in Test-Driven Development (TDD) is deceptively simple: you just have to improve the code, without changing what it does, right? And the experts make it look so easy: “Look”, they say, “here’s some duplication, which I will remove by “insert magic incantation here”. But how should you decide which “duplication” to remove first? What happens if you fix the “wrong” smell? And how do you even see that duplication in the first place?
The Agile Testing & BDD eXchange conference is a two-day event focused on all aspects of Agile testing and Behaviour-Driven Development. It provides an environment to learn and network for all Agile developers and software testers.
With the rapid implementation of Agile development in most IT environments, the traditional roles of functional QA managers are changing. Testing is now the responsibility by the product team; day-to-day testing tasks and accountabilities are largely owned by the product team and defect status is discussed on a quick daily meeting. But yet all of the testing personnel report into the QA Manager from an organizational viewpoint.
This tutorial presents how to do Test-Driven Development (TDD) for a Spring Boot application and how some of the latest Spring Boot annotations and utilities make that easy. Ever wonder how to test a hard problem like caching or write an integration test without making an external API call? Or come across a situation where testing something was so hard that it never got tested?
Page-Object pattern is very commonly used during software testing when you use test automation frameworks. However, as the scale of the framework grows, there is a limitation on how much reusability really happens. It can inherently become very difficult to separate the test intent from the business domain. This presentation discusses the issues with the Page-Object pattern and the solution that you can implement – Business Layer – Page – Object pattern, to help your code staying DRY.
Copyright © 2009-2025 Software Testing Magazine by Martinig & Associates