Agile testing tutorials and how to content : Test-Driven Development (TDD), Behavior-Driven Development (BDD) and other agile approaches for software testing.
Software testing during the transition to Agile is not easy. This third part explains how your software quality assurance processes should change. It discusses how to cope with rapid development cycle and frequent code changes that are at the heart of the Agile approaches.
Software testing during the transition to Agile, particularly if you’re moving from a classic waterfall system, is not easy. This part discusses how to perform software testing when you don’t have the classical workflow of documented test cases and bug requests than in a traditional approach.
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.