An Introductory Acceptance Test "If you don't know where you are going, you will wind up somewhere else." Yogi Berra This article is an excerpt from Ken Pugh’s upcoming book – “Lean-Agile Acceptance Test Driven Development” to be published by Addison-Wesley. Debbie, the developer, and Tom, the tester, are introducing acceptance test-driven development to Cathy, the customer. The Triad – Tom, Debbie, and Cathy – are in their second meeting together. Debbie describes an example of an acceptance test and four ways that an acceptance test can be executed.
|
||
Continuous Testing: Building Quality into Your Projects I buy new cars infrequently, typically every 10 to 12 years. So when I bought a new car in 2003 I was surprised at the many advances in technology since I’d purchased my previous car, a 1993 Honda. One advance I was particularly pleased with was a sensor that automatically detects low air pressure in my tires. It is sometimes hard to tell by looking at a tire if its pressure is low, and checking tires manually is a dirty job, so I did it infrequently. A continuous test of tire pressure was, I thought, a tremendous invention.
|
||
Managing the Transition to Agile During these challenging economic times there is a dramatic increase in the need of organizations to adapt the software delivery lifecycle processes to the rapid changes often imposed on them. Leadership is making the decision to transition its development organization – not than just small teams but large numbers of engineers, working on a broad portfolio of development projects from many different locations around the world — to a more agile approach as part of an effort to vastly improve performance, be more responsive to customers and improve quality. However, there are many challenges that an established software organization faces when shifting to Agile.
|
||
Getting the Product Backlog Ready for Sprint Planning Most sprint planning meetings I have attended were fun. The ones that weren’t involved a poorly groomed product backlog, whose high-priority items were not workable, not ready to be pulled into the sprint. When the backlog hasn’t been prepared prior to the meeting, the product owner and team often carry out impromptu grooming activities. These consume valuable planning time and usually result in poor requirements and weak commitments. Plus, everyone is fed up and exhausted by the end of the meeting. As a consequence, the product backlog items that are likely to be worked on in the next sprint have to be prepared prior to each sprint planning meeting. Although it is the product owner’s job to make sure that the work gets done, preparing the product backlog should be teamwork involving the product owner, ScrumMaster and team. We begin the preparation work by choosing a sprint goal.
|
||
Software QA vs. Software Testing on Agile Development Projects Bob Small and Janet Gregory share their thoughts and experiences relating to the difference between software QA (quality assurance) and software testing on agile software development teams. |
||
Agile Portfolio Management I've heard people criticize agile methods as being too reactive and focusing too much on the little picture and ignoring larger goals. This is a misunderstanding of a basic idea of agile. Agile methods are't about thinking small and taking small steps towards a goal, applying programming an management discipline along the way. |
||
The "One Right Way" For those who believe there has to be one right way to do something, especially in software development - there can be. But that one way isn't likely to come from a single individual. Through collaboration and teamwork, some of the greatest single ideas have evolved. |
||
Estimation Poker Planning aoker, an estimating method popular with tgile teams can address some of these issues. Briefly, planning poker involves getting the developers on a team together to estimate stories using a deck of cards that have numbers that represent units of work. |
||
Fixing the Quick Fix Demands on businesses these days tend to make speed a priority—often at the expense of other areas. When it comes to correcting a problem in your organization, you should make sure you are, in fact, fixing the problem and not just a symptom. In this article, Esther Derby takes a look at the issue of the quick fix and offers some tips on how to get to the heart of the problem. |
||
The Indivisible Task One of the things that makes agile work well is a daily sense of progress that can be reflected in, for example, a burn-down chart. For burn-down charts to be meaningful, the estimate of amount of work remaining in a sprint need to be accurate. Re-estimating work remaining in a task is helpful, but the best measure of progress is the binary "done/not done" state of the items in your backlog. |
Pages
Upcoming Events
Sep 22 |
STARWEST Software Testing Conference in Anaheim & Online |
Oct 13 |
Agile + DevOps USA The Conference for Agile and DevOps Professionals |
Apr 27 |
STAREAST Software Testing Conference in Orlando & Online |