A former client asked:
“What does Scrum say about User Acceptance Testing? I am wondering if it should best be done within 24 hours of delivery, or at the end of a sprint…“
I’ll dodge scrum, but answer how we do it here by framing this in terms of risk and velocity:
We prefer to get acceptance as soon as a story can be delivered to the acceptance/demo server. Intra-day is the best, but certainly within the same sprint when the work is done so as not to muddy velocity measures (a story isn’t done until it is accepted, so there’s incentive on all sides).
The longer a story sits out there (waiting to be accepted), the bigger the risk that it is “wrong” and needs re-work. Since the code base continues to evolve, fixes are harder the further they are away (in terms of commits) from the original change-set. This can slow down velocity. We want to reduce risk and maintain a steady velocity. Thus, the sooner a story is accepted by the stake holder, the better.
- Project Sprouts from Luke Bayes “an open-source, cross-platform project generation and configuration tool for ActionScript 2, ActionScript 3, Adobe AIR Flash and Flex projects”
“Project Sprouts was originally designed (as AsProject) to solve a specific set of problems and was later entirely refactored to become a modular set of libraries that are built on top of Ruby, RubyGems and Rake.” — Luke Bayes
“So how will Sencha monetize? The company plans to sell its tools, like Sencha Animator, at a premium. It’ll also offer premium support plans.” — Tech Crunch
“Does anyone have experience with (slower) performance on EC2 compared to Heroku”
- Test network lag
- The small instance, the default, is just too wimpy to run as an application server
- Make sure your database instance is big enough, and has enough memory
- Any experience with RDS?
“Can you run cucumber with its own database instance?”
- By default, Cuke creates its own environment, but piggy-backs on the test database
rake db:test:prepare is wired to :test and won’t support a :cucumber in the database.yml without extra rake tasks that have continuing maintenance costs
- I’ve used the parallel_tests gem in the past, which has managed to retrofit db:test:prepare to work with multiple test databases, but it did require an extra step after each migration (and it didn’t play well with postgres text indexes).