February 24, 2017 at 10:03 am #15513@bygonesOnly available when logged in
we have in the company currently a more waterfally approach to testing. At the end of a release cycle (~6months) we have our testing/qa phase, where all development is done and the software is tested.
Though unit/integration testing is running continuously as automated tests during development, the manual testing and system tests are only executed in the dedicated time period after development is finished.
I would like to switch to a more agile (?) approach and have a testing period after either a dedicated time frame or when an new/changed feature is completed (whereas the latter sounds better for me).
The question is now – how/what is the best approach here. What test scope have these “smaller” test periods, how to they replace, reduce (?) the big test period at the end ? If feature 1 is done and tested and later on feature 2, how much of feature 1 and rest is included in the test run ? How long are usually these smaller test runs etc ? And what do testers in “pure” development phases ?
Sorry, a lot of questions, I hope to get a discussion out of it, that clears a bit my understand and view on this. Who ever has some experience with this, it would be fantastic if you could share this hereFebruary 27, 2017 at 2:39 pm #15526@jesper-lindholt-ottosenOnly available when logged in
So where is the challenge for change coming from – you or management? With the answer to this you can scope the change you want to happen. What things can YOU change, what requires decisions and what requires other to change? (It becomes an organisational change quite quickly).
Perhaps look at this:March 15, 2017 at 1:28 pm #15713@augusto-evangelistiOnly available when logged in
Hi Andreas, what you propose makes a lot of sense to me. The problem is, I am an agile coach and I have worked on transforming situation like yours into something more agile, but I am not the person you need to convince in order to make the changes required.
So the first thing you need to do is to identify and clearly state what problem you are resolving by changing the testing frequency from every 6 months to say every month? Or every feature, whatever is better for your context.
What benefits will you and your organisation derive from it?
Once you have that you will have the ammunitions to go to a stakeholder in your organisation that can help you. Why do I say that? Because without internal and external support unfortunately you not very likely to succeed.
Start by looking at the problems you are resolving, get support internally, get an external coach and drive the change from within.
GusMarch 16, 2017 at 10:32 am #15724@ronanOnly available when logged in
When we did that transition in my company (still on going, the journey is not over), a small group of highly motivated people started to apply Agile process at the beginning. After one year of experiments and progress in these small groups (2-3) in parallel (with regular exchanges on their progress / what worked / what didn’t), the lessons learnt were discussed with the management.
Based on those examples and first benefits for those pioneer tems, the high Management was convinced and organnized a general training for the whole company and imposed moving to Agile. Not all teams are fully convinced yet, but the practice is percolating step by step and more and more teams adopt Agile practices. Even if some do not apply every principles yet, they are already beneficiating from the change and the Agile spirit is growing 🙂
You must be logged in to reply to this topic.