Maintain Quality Continuous in Agile.

In standard – let’s say – waterfall approach, testing is just another step in the process. When development is done, here comes the test stage, and usually some kind of QA branch is responsible for testing the product of preceding development stage. This approach have been proven correct in case of large systems, with stable and well know requirements. I still see there is part of world deals with this model but again its with the well known requirements.

However, today’s way of delivering software differs from this. There is huge demand for network based, distributed systems, delivered as quick as it’s possible. Going further, business requirements tend to change more often. As well as software development methodologies changed, turning into lighter, agile methodologies like Scrum or Kan-ban, software testing needs to change also. There’s no room for separate stage. Rather that, testing should be done at each stage of the process.

Gathering Requirements: Starting from gathering requirements, ones should validate them in terms of consistent, logic or comprehensibility.

Development: Through the development stage, testers should continuously test smaller pieces of the feature, working close (or pair) with developers.

Testing: During dedicated test time, features needs to be validated in terms of acceptance requirements. I believe our role here is to be bridge between product owners and developers, checking correctness of the implementation with business guidelines.

Continuous Integration/Continuous Deployment: Nowadays, when software delivery introduced CI/CD and DevOps, there’s huge demand for test automation. I’m far from saying that manual testing is dead and I think will never be, but in my opinion – test automation is the future, whereas manual testing would become limited verification of some narrow test cases. Having said that, automated test should be part of the CI/CD pipelines. Of course there is no need to run for eg. all selenium acceptance tests (which are usually slow) while building every pull request, and in those cases we can limit automated test scope to unit and integration test. However, full blown test suite should trigger at least once a day, could be in separate job, and also ideally before every deploy on production.

Maintenance: Obviously, bugs will always happen – also when our feature is on production. Depending on organization of your company, usually product owners are the ones who enter them to backlog. Role of the tester here is to analyse bug reports and provide product owners necessary technical knowledge, to make issues fully understandable both to business and developers.