0

I'm on a new CRM dev team. And simply put, I haven't seen sprint execution such a mess in my whole professional career.

I have a deployment plan moving forward. I have an idea how I want continuous testing done in our test environment. However, I am torn on how often to push to test; because some sprints have alot of short user stories while others have few longer shorter stories.

I know there is no 'hands down' solution to my question, but am looking for recommendations for how often I should push my incremental solutions from dev to test in a 3 week sprint.

Kind regards.

J.S. Orris
  • 119
  • 5
  • 1
    Sorry, but I don't think some strangers from the internet, outside your team, can give you a sensible answer. This is a teams issue, you have to workout that with them. I guess you are after a discussion with us, but this is not a discussion site. – Doc Brown Apr 21 '18 at 09:12
  • @DocBrown Not looking for a discussion sort of looking for examples given certain other users development circumstances – J.S. Orris Apr 21 '18 at 17:18
  • 2
    Why are you "pushing to test" rather than testing during the entire course of the sprint? Testing should go hand-in-hand with development and not be an afterthought. – Bryan Oakley Apr 22 '18 at 03:09
  • Bc Im pushing CRM solutions. – J.S. Orris Apr 23 '18 at 01:41

2 Answers2

1

The longer your builds are not done the higher the entropy... better to do more frequent builds to assert the correctness. Ever have an application that hasn't been deployed in a while? It's nerve wrecking moving it to production.

Jay
  • 27
  • 1
  • I'm going through that right now. Im pulling my hair out at how our push to prod is is going. Thanks for he quick response. – J.S. Orris Apr 21 '18 at 03:25
  • 2
    Everything you wrote is true - but it looks to me as this does not have much in common with the question, which was not about builds, but deploying from a dev environment to a test environment, which is a different thing. – Doc Brown Apr 21 '18 at 09:14
1

You should push a new version to test as soon as your testing of the previous version is complete.

If you have automated tests then this can be every day. But I guess if you had reached that level of testing then you wouldn't be asking the question.

Manual testing normally takes longer than developing new features, and a 3 week sprint will add a 6 week delay to any bug fixes you need.

A key thing is not to push any new features in with a bug fix. Keep fixing and testing the same version with hotfixes until it passes. This will focus minds on getting a working product and prevent you adding new bugs faster than you can fix the old ones. The way you are talking about the impact of short and long stories makes me think you are not using feature branches?

If you want to move to a nice smooth Continuous Integration or Continuous Deployment setup you really need to push for three key things:

  • Automated Testing
  • Smaller components
  • Shorter sprints
Ewan
  • 70,664
  • 5
  • 76
  • 161