Whenever a new methodology or a new system is introduced, with it – certain terms and guidelines are introduced too. These terms and guidelines are meant to be followed to ensure maximum output. But during implementation, some of these guidelines might be deemed not-so-important and might not be followed.
Similar has been the case with Scrum Agile Methodology. Since it was introduced, it has been adopted by a majority of software development teams. But, the catch is that most of them are not following a basic guideline – the Definition of Done for a feature should also include testing and automation of the feature.
And just that is the reason why we are laying special emphasis on ‘insprint test automation’. This blog is a special ‘round up’ blog where we asked experts some important questions around ‘insprint test automation and have compiled their answers in the form of a blog here.
We have a detailed ebook that discusses insprint test automation, why it is important in detail!
Grab your free copy!
In-sprint test automation simplified!
Now, let’s hear from the experts what they think about in-sprint testing.
Below is what ‘Brijesh Deb, Sr, Test Consultant at Sogeti’ explains:
Q. How does insprint test automation fit in agile?
Let’s begin with the Agile principles. At any point during a project, working software is the primary measure of success. Now for a piece of software to be working, it is essential that the definition of done is met for all the user stories that have been worked on to build that working piece of software.
Now when we talk about the definition of done, it is incomplete to say that the stories will have development only and will be tested later. In order to meet the definition of done we need to build and test and only then the definition of done is met. So, if you are planning to implement a feature in a sprint, it must be ensured that the feature is built and tested in the same sprint to meet the definition of done and give a sense of in sprint testing.
Q. What would you say about teams that do testing in different sprints or wait till the end of the sprint to start testing?
Often it is seen that testing gets lesser time in a sprint or is done in a different sprint. Both situations are against the ethos of Agile and do not meet the idea of definition of done and give enough confidence to the product.
Testing playing catch up with development is not agile. The best way to deal with this is to involve testers early and ensure that the sprint planning is done keeping in mind the definition of done meaning if a story is a 5 pointer then it must be ensured that the 5 story points are assigned considering the effort needed to build and test the story.
Now let’s look at the other burning topic, automation. Often seen as a mechanism to reduce regression effort, Automation has far greater reach and can be of much more value than mere regression.
Smoke tests, sanity tests and regression tests are easy candidates for automation because they are repeated far too often. But let’s be honest, is that the only premise for automation? What about other tasks that can be automated like test data generation, test reporting? These are essential elements of every project and hence there’s immense value in automating these activities.
Q. Your suggestions on how to implement automation?
Now let’s look at automating the tests. It is of utmost importance to do a thorough feasibility analysis to choose the right tests that can be automated. Then the next important step is to choose the right layer in which the tests will be automated. Automating the tests in the right layer is always a wise choice and the Agile Test Pyramid provides a guideline for the same. With that as the guideline and collaboration with developers, fellow testers, business, PO and stakeholders, easily the right layer for automation can be established.
Once you’ve done that, it is also important to leverage the advantage of insprint automation which gives you feedback much faster and results in a quicker time to market. Note that, in sprint automation should also be a part of the established and agreed definition of done.
We asked Adebayo aka Tea Pot( Founder, Naija Test Crowd):
Q. how to make Insprint Test Automation possible and this is what he said:
“Insprint testing is quite important and should be the default way of working on any Agile methodology but there are a few things that must be done to make this possible:
Not in any particular order: The project must put all their ducks in a row: ensure that everyone understands the strategy, ensure that testers and developers attend scrum meeting where the sprint is the subject, ensure that the scope for each sprint is quite concise and achievable, test cases should be developed same time as the developers are developing the codes for the sprint and the codes should be delivered within time to allow the testers test, where the review of test cases is mandatory, this should be done during development so the test cases are reviewed and ready for execution as soon as the code drops. Also, and equally important, this can be automated as the sprint progresses into another sprint until the end of the project.”
Q. When we asked why he thinks insprint test automation is important he says:
In sprint testing will afford the tester to relate to the development more easily as each test is focussed on the latest release, equally focussed on the latest functionally. Conversation between developer and tester will flow so easily when both are discussing what they are currently doing, instead of what they did or shall be doing in the future. And the automation should probably be as per automation pyramid, with the right amount of overlapping and uniqueness of tests being automated on all the layers.
Q. When we asked him how much time can it take for an organization to fully achieve insprint automation, he says:
Automating the tests within a sprint is not impossible but it does take time to achieve, the process must be well defined and start from the earlier sprints, and everyone must have a very good understanding of the strategy, so all downtime is utilised rather wisely and efficiently too. Test cases that have been reviewed and executed in the previous sprint can be automated as the sprint ends and next sprint is being planned but there must be enough time for the tester to test otherwise, automating the tests is one futile effort that will simply result in a complete waste of time. Subsequent sprints can have the automated test included in execution while also making time to automate tests (reviewed and agreed) for the current sprint.
Ajay Balamurugadas points out 3 key principles in the successful execution of insprint testing.
Effective communication, common understanding of the goal and lots of collaboration are some of the key principles of in-sprint automation.
Now, let’s break them down.
i. Effective communication:
If you don’t communicate what you expect from each team, you are most likely not going to get it.
ii. Common understanding:
All stakeholders should know what is targeted. There is no point testers trying to automate and designers changing the design or functionality changes introduced by the product managers
iii. Collaboration:
Not an easy task, at the same time, not impossible either. Given the right teams, intent, tools and collaboration, in-sprint automation can be a reality.
Conclusion
Of course, just blindly implementing automation won’t ever be enough. Intelligent automation is the way to go where the time and effort is only invested in the automation of tests that need and should be automated. Along with it, to keep the automation current, the automation for the tests corresponding to the development work in the current sprint should be targeted in the same sprint.
Nikolay Advolodkin, Sr Solutions Architect at Sauce Labs also comments that he believes that testing within sprints is an absolute must. The product cannot be deemed finished until it has been tested and we are positive that we are releasing a quality product that works for our end users. Without in-sprint testing, we are risking the end-user experience by creating longer feedback and release cycles.
We agree with him and recommend that testers should keep up with the dev speed, leaving no gap between dev complete and test complete. And of course, when automation comes into the picture – it becomes crucial to adopt a tool that enables insprint test automation.
