Test cases as part of the staged deployment process.

Hi Rik,

why don't you add those test cases for the stages above TEST to the ones that have to be passed to go on TEST? A "done" story should be potentially shippable, that means it should be tested thoroughly and be production ready. Therefore in my opinion every test that is necessary to check if it is ready for productive use should be executed before it is done.
But since I think you already know this, what did I miss? :)

Best regards,

Peter

Hi Rik

if you are only deploying into a test environment then each increment is not potentially shippable. What you need to do is to look at how you can improve your Definition of Done (DoD) to include the sort of QA/UAT/System testing that is currently being done in your Test and Acceptance environments.

Part of the problem may be that you have work silos, with explicit tester roles being assigned. In Scrum, each developer should be able to do all of the requisite testing.

It sounds as though there is an implicit waterfall-style process in your organisation, which is represented by stage-gated deployments to successive environments. This is a very common barrier to agile transitioning. Using backlog items to facilitate the transitions between stage gates is also very common (I've done it myself) but it is only a sticking plaster remedy.

If I was you, I'd be looking to automate as much as possible of the deployment procedure across environments. In particular I'd want Acceptance to mirror Production in terms of its configuration. If I could get a deployment to Acceptance as part of the DoD then that would leave Production as a political battle to fight out with management and the infrastructure teams (rights to publish and/or getting change requests & release slots pre-booked etc).

@peter, @ian: Thanks voor your quick comments.

I've been thinking about what you're suggesting. Probably it is more a matter of terminology rather than possibility. I agree that each increment should be shippable, and that ALL testing should be part of the definition of done.

The point I am struggling with is that we have different environments for different types of test. Indeed Acceptance is (almost) a mirror of Production.
If we would make the deployments over each environment automated at the end off succesful passing of the test on the environment, I think the test, although they have to be succesive, can all be executed as part of each PBI.

The suggestionI an is making is maybe for the moment a nice in-between step untill most tests are automated.

I'll include all up to acceptance as part of the DoD.

Thank you again for your suggestions

Testing web apps has to be done using internet or intranet.Different points to be considered are: integration,security,UI,performance and compatibility with different browsers.

Hi

I realise I'm very very late to this thread but I wanted to share my input.

The DoD should be a list of tasks which must be completed for each PBI which will inform you whether the work is "Done". Scrum states that work should be "potentially shippable" at the end of each sprint so as a minimum the DoD should include what's required for that.

In my mind DoD should include:

•  Acceptance Criteria met (whether by automated or manual means)
• Non-functional criteria met
• Can be deployed (again, ideally through automated needs)
• Any static code analysis/CRs as appropriate

If the acceptance tests aren't passed then you can't state that the PBI is ready to be shipped. Likewise with the other points.

This means that testing, almost by definition has to be included in your DoD. Ideally these should be automated tests created by the team up front - but not necessarily. You can have manual steps in your Definition of Done!