Content tagged with: agile
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 …
In this short article, Mahfoud Amiour introduces the PURIFF acronym as a reminder to all the software testing to be conducted during the Scrum sprint. In PURIFF, P stands for performance testing, U covers unit testing, R deals with non-regression tests, I represents integration testing, F is for functional tests and the last F covers non-functional tests. A Scrum team can use it as a checklist to determine which categories of tests are relevant in the given context.
Software testing is a major activity in any software development project and a large part of the budget is spent on it. If we want to effectively spend your money, the ease of software testing should be addressed when you design your system in the early stages of building your applications. In this article, Gil Zilberfeld explains that thee adoption of test first practices like Test-Driven Development (TDD) or Acceptance Test-Driven Development (ATDD) by the majority of agile teams shows how test automation needs are addressed from the initial steps …
Many teams have tried to implement agile software development practices and failed. When you read about transitioning to agile development, it sounds so easy. Why don’t all of them succeed and why do so many agile adoptions go so badly? In particular, testing seems to get off track.
This article discusses the traditional software testing aspects that should be changed before adopting Agile practices. Testing teams face a significant impediment when they have to unlearn the traditional practices.