Agile is a big umbrella that covers a number of different approaches, and there is always scope for more. There are so many flavors because agile is a mindset that allows flexibility in its processes. Two of the more popular approaches are Scrum and Kanban.
Scrum and Kanban apply agile principles in their own way to empower effective delivery cycles. “Scrumban” is a term coined for a hybrid approach making use of both Scrum and Kanban principles.
In my article published at Testrail , I have explore the differences among the three methodologies – Scrum , Kanban and Scrumban. Check it out and see which of these methodologies may be right for you. https://blog.gurock.com/scrum-kanban-scrumban/
Here is a brief about the 3 methodologies –
Scrum is the most popular agile framework. It is iterative and incremental in nature and focuses on tight delivery timelines. The release time frame is split into small iterations called sprints. Work items are planned for each sprint in the form of user stories and tasks, which are prioritized based on value. Teams are small, cross-functional and self-organizing, with a product owner, a ScrumMaster and the development team.
Scrum provides channels for communication through ceremonies such as the sprint planning meeting, the daily standup meeting, the sprint demo, and the sprint retrospective, all of which contribute to the overall pace and a flexible approach to software development.
Kanban is focused on continuous delivery based on lean principles. It’s based on the flow of work and just-in-time delivery and promotes process improvement. Kanban aims to eliminate waste, increase productivity and efficiency, and have flexibility in production. The main goals are to limit work in progress (WIP), avoid multitasking and recognize bottlenecks.
The Agile Manifesto gives us 12 principles to abide by in order to implement agility in our processes. These principles are the golden rules to refer to when we’re looking for the right agile mindset. But are we getting the right meaning out of them?
In my latest article for Gurock TestRail blog, I examine what we mistakenly hear when we’re told the 12 principles, what pain points the agile team face due to these misunderstandings, and what each principle truly means.
Principle 1: Our Highest Priority is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software
What we hear: Let’s have frequent releases to show the customer our agility, and if they don’t like the product, we can redo it.
The team’s pain points: Planning frequent releases that aren’t thought out well increases repetitive testing, reduces quality and gives more chances for defect leakage.
What it really means: Agile requires us to focus on quick and continuous delivery of useful software to customers in order to accelerate their time to market.
Boris Beizer, in his book Software Testing Techniques (1990) coined the term pesticide paradox to describe the phenomenon that the more you test software, the more immune it becomes to your tests.
Just like, if you keep applying the same pesticide, the insects eventually build up resistance and the pesticide no longer works. Software undergoing the same repetitive tests build resistance to them, and they fail to catch more defects after that.
Software undergoing the same repetitive tests eventually builds up resistance to them.
As you run your tests multiple times, they stop being effective in catching bugs.
Moreover, part of the new defects introduced into the system will not be caught by your existing tests and will be released onto the field.
Solution: Refurnish and Revise Test Materials regularly
In order to overcome the pesticide paradox, testers must regularly develop newer tests exercising the various parts of the system and their inter-connections to find additional defects.
Also, testers cannot forever rely on existing test techniques or methods and must be on the look out to continually improve upon existing methods to make testing more effective.
It is suggested to keep revisiting the test cases regularly and revising them. Though agile teams provide little spare time for such activities, but the testing team is bound to keep planning these exercises within the team in order to keep the best performance coming. A few ideas to achieve this:
Brainstorming sessions – to think of more ideas around the same component testing
Buddy Reviews – New joinees to the team are encouraged to give their fresh perspective to the existing test scenarios for the product, which might get some new cases added.
Strike out older tests on functionalities that are changed / removed
Build new tests from scratch if a major change is made in a component – to open a fresh perspective