Agile Testing: Don’t Sacrifice It

Agile Testing

Agile testing — I will repeat the title of my post: Don’t sacrifice on testing!

Testing is an important, especially Agile in upholding the principle ‘Never compromise on quality‘. When on a project; and the deadline is looming — there is usually only one place to cut resource; the final step before deployment: testing.

Especially with large more traditional approaches, if there is an error with the testing stage — this usually means moving the deadline and spending more money; and there is no choice about this. With Agile, you need to continuously test as you deploy in iterations, so if there is an error with the testing; only a small part is affected which can easily be rectified.

Testing is an important phase in the software development lifecycle, and there are different concepts for testing in Agile, if following these you can optimise productivity when testing and maximise the features delivered:

Fail Fast

The earlier a bug or issue is found, the less it costs. With this concept the aim is to ‘Fail Fast’. The main areas within an Agile project Fail Fast can benefit are:

  • Early testing of requirements and the design of features during the early stages of the project.
  • First execution of the feature being developed. Don’t wait until a feature is fully developed to test it if you don’t have to. Try to find issues as quickly as possible.
  • Regression testing following changes and fixes.
  • Integration testing is carried out as soon as something is ready to integrate. Rather than waiting to integrate a mass of features, especially deliverables from earlier increments are integrated with current deliverables.

Collaborative Testing

Effective and productive involves the input and collaboration of all people involved; all stakeholders. This will increase the productivity of the test, fix and reset cycle. This is inline with the Agile concept of collaboration — any one who can test something should! This usually means the business owners testing the features they requested.

This concept only really works when teams are collocated. If this is not the case then a clear plan or process needs to be in place to ensure that there are working arrangements for testing,

Repeatable Testing

Since we are developing in iterations, then we should also test in iterations. Tests should be ran several times before the product passes the customers tests. Tests need to be designed to be repeatable.

End-to-End Experience Testing

Being collaborative, working together and ensuring that regular demonstrations take place allow you to test the full end-to-end experience of the feature. The full feature needs to be tested like this so you can ensure changes can be made to enhance the experience.

Independant Testing

As well as the developer and QA testing the feature, an independant user should also test. Involvement from the business teams ensures that an independent view is always maintained.

Prioritised Testing

All tests needs to be prioritised. It may not be possible to test everything exhaustively. Each test needs to be attached to a product or feature. The major or high risk tests should be carried out first — the ones with the biggest impact.

Test-Driven Development

With this method, tests are created even before development is created. This ensures that the acceptance criteria are confirmed before any effort is wasted on creating the wrong product.

Risk Based Testing

Some tests, if done first can reduce the risk with putting a new development in a production environment. It would be best value to carry out these tests first. All requirements should be assessed for risk, and will allow you to prioritise the tests for each one, so resource can be applied appropriately.

In Summary

In Agile, testing is there to ensure that the product is what is wanted, and is of a required quality. Testing should be done throughout the lifecycle of the product — and focus should always be on delivering maximum business benefit.

Testing should be part of the project plan, not something that is thought about after, especially testing early on which can reduce the risk of a project. Developers should be encouraged to demo their work early and try to get the business to test also. When you test, this allows you to create a feedback loop, and promotes communication on a project.

Finally, testing allows you to keep control of a project!

This post was originally posted on: theproducthub.io
https://www.theproducthub.io/2019/07/06/dont-sacrifice-testing/
Please check my site to get the latest articles first!

About the Author

Ashley-Christian Hardy
theproducthub.io

Product Leader. Over 10 years in product development; with experience in product management, UX & UI, product design, product & delivery methodologies and product leadership. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research, putting an emphasis on a customer centric design and approach.

Website: www.theproducthub.io

Twitter: www.twitter.com/achardypm

Facebook: https://www.facebook.com/theproducthubio

LinkedIn: mt.linkedin.com/in/achardypm

Medium: medium.com/@achardypm

Instagram: https://www.instagram.com/theproducthub.io/

Pinterest: pinterest.com/achardypm

SlideShare: slideshare.net/ashlychrstn

Tumblr: tumblr.com/blog/achardypm

Product leader. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research.

Product leader. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research.