Agile testing tutorials and how to content : Test-Driven Development (TDD), Behavior-Driven Development (BDD) and other agile approaches for software testing.
Testing during the transition to Agile, particularly if you’re moving from a classic waterfall system, often means throwing out every expectation you have about how a project will be run, how long you’ll have to prep or test a drop, and when new code will arrive.
This presentation shows how to easily go from user stories to automated integration tests that themselves read like user stories. You can accomplish this by using custom domain-specific languages (DSL).
A Reflection on Up-Front Testing As we were saying, up-front testing really isn’t testing at all. It is really up-front design through the analysis of our tests. Can we take this testing even further? When XP came out and suggested doing unit tests, many of us realized that if we combined a series of unit tests together, we could get the equivalent of automated acceptance testing.
Many organizations are adopting Agile development practices and the Scrum framework for project management. With a software testing perspective, one of the main challenges of this approach is to complete all software testing activities during iterations that could last only one to two weeks. In this article, Clemens Reijnen provides five tips for getting software testing done in a Scrum sprint.
This is not a session about how or why to practice Test-Driven Development (TDD). Based upon research conducted during the first quart of 2012, I will outline the most common objections to TDD and describe in detail, with examples where appropriate, how to refute, avoid or mitigate each of them. The coverage will acknowledge that there are risks inherent to all techniques and will not promote the idea that TDD is some kind of silver bullet.
Traditionally, software testing occurs after the software is written. From a Lean perspective, this is waste because the software needs to be reworked, retested and often reworked again. Instead, Lean says that quality should be built-in to the way of working.
Elisabeth Hendrickson shares her experiences and lessons learned about how testers can play well and succeed on Extreme Programming (XP) teams. One of the things testers often notice about XP is that there is no defined role for testers on the team. Yet XP teams describe themselves as “test infected”. They practice Test-Driven Development (TDD), writing executable unit tests before writing the code to be tested. Many teams practice Acceptance Test-Driven Development (ATDD), writing executable acceptance tests before implementing a feature. They use continuous integration to give them rapid feedback about the effects of changes. They practice pair programming, a technique that results in all code being peer reviewed before it’s checked in. In short, XP teams test continuously from the very first moment of any given project. You could even call them “test obsessed”.
Copyright © 2009-2024 Software Testing Magazine by Martinig & Associates