Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!

Joel Robinson

Greenhorn
+ Follow
since Jul 02, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Joel Robinson

I'd like to get some real-world examples, both successful and not, of how people have incorporated QA into an agile process.

Our team uses 2 week sprints and so far the pattern has been that more features get implemented than get fully tested & signed off as shippable. Part of this was a staffing issue which we've been actively addressing but even with an equal ratio of programmers and testers, it's still a challenge to keep up. This is especially challenging if the features aren't testable along the way & only become testable at the end of a sprint. Some solutions that have been tossed around include:
--status quo but try harder (LOL, yeah, not a good plan)
--add test stories/tasks to later sprints so that QA work starts after the feature is code complete (this is probably what we will do, experiments so far have been pretty successful)
--run entirely separate development and QA sprints (this solves the timing issue but I fundamentally don't like having dev/qa separated like this)

One problem I don't have a good answer to is what to do about bug fixes. If we're doing simultaneous programming & testing in the same sprint, it's usually fairly manageable to identify story-blocking bugs that need to be fixed ASAP and most of these have been manageable without throwing off time estimates too wildly. However, if we decouple programming & QA efforts and because the # of bugs the QA team will find is unknown, the programmers are hesitant to stop current sprint work to fix bugs from previous sprints for fear of getting off-track on current work. Not only that, the mental context-switching between current feature work and bug fixing has an efficiency impact. Of course we can implement policies about the priority of bug fixing vs. current feature work but I'm looking for some insight from others about processes that have worked with less reliance on heavy-handed policies.

Thanks in advance for your input!

Joel
Do you have a .jar file? If you do, you should be able to use Abbot & Costello to automate your GUI testing. If your .jar is wrapped in an .EXE, I'm not sure what your options would be.
11 years ago