The Agile manifesto states that you should value working software over comprehensive documentation, but as we all know, this does not mean no documentation. If you’re following an Agile approach for your programme of work or project then we would always recommend considering and documenting your Agile Test Strategy. Here are three things to consider when creating yours.
As a multi-award winning software testing consultancy, nFocus live and breathe Agile. So much so that we decided to run our Marketing Team using Scrum. If you're interesting in learning about the benefits of adopting Agile from a testing perspective, check out this white paper instead.
In today's post I thought it would be useful to consider Agile Test Strategy and the quality challenges associated with implementing Agile and Scrum. If you have time, we would also recommend taking a read of the white paper - The quality challenges associated with implementing Agile and Scrum.
So I get to see lots of different organisations all trying to implement Scrum to varying levels, several themes come out:
Here's the second in our series of bitesize blog articles on Agile Test Strategy. If you missed the first one, you can read it here.
Now that you are ‘Ready’ to test, you want to test as often and effectively as you can; not only will this increase the chance that you'll find defects but will improve application quality. In the short-term your costs will increase as you’ll need to set up a defined framework and create re-usable test artefacts…
Welcome to the first in a series of bitesize articles we're writing on Agile and Testing.
Creating a robust and practical Agile Test Strategy should exist in all organisations that employ an Agile approach to delivering projects and programmes of work. Being ‘Ready’ to test is vital to the success, having just a set of requirements isn’t enough….
There have been challenges in the adoption of the Agile principles (an Agile Test Strategy) and Scrum Framework particularly with poor quality of the delivered software. This has resulted in delays and a mismatch of the expectations of stakeholders and delivery teams. There is no specific mention of testing or quality assurance in Agile or Scrum; it is implied as an integral part of the principles and framework. This has caused some confusion resulting in inconsistent approaches to quality management and testing. Often formal testing has been reduced to ad hoc ‘try it and see’ during a sprint. This loses the testing rigour that delivers quality by use of industry accepted full lifecycle testing.