Could anyone please give some important differences between KANBAN and SCRUM with respect to testing? Any examples are most welcome.
With respect to testing they are the same.
Kanban and Scrum are both iterative Agile development models, the goal is to get the most important tasks fully done (including testing) as soon as possible. The product should be potentially shippable at the end of the iteration. The difference is with Scrum the end is a set date, with Kanban it could be anytime the features that need releasing are done. In Scrum you plan a fixed period of time and with Kanban you plan just in time.
As there is no testing phase after a Scrum or Kanban iteration, the testing must be completed during the iteration, preferably during the story/task scope. It is therefore very important to automate all possible test work, because during the next iterations there won't be time to do a full manual regression (unless you scale-up your test efforts over-time accordingly). Often teams use XP practices to asure continuous quality. In order to find automation candidates apply time boxed manual exploratory testing methods. The automation is there to ensure old features keep working and the team can keep delivering new features in a sustainable pace.
Suggested books to reads are:
Kanban is not a software development methodology. It does not prescribe any method of development or testing. You use Kanban for visualizing - and improving - what you are already doing.
So, if you are currently a Scrum team, and have specific testing/ test automation practices, you can continue to use the same with Kanban as well. If you are using other methods, including iterative or waterfall, you can use the test processes that you use there.
Having said that, what @Niels has said makes perfect sense. We ourselves are a product development shop and use Kanban to build a Kanban product. When a developer picks a user story, they not only write the code for that, they also write the test case(s) to test them and automate them at the same time. Like @Niels said, we usually make a release when we have 20 items in our Done column! Usually, that works out to about 3 weeks cadence - which works perfectly for our SaaS customers.
What makes Kanban interesting is this aspect of it - that you could be continuously developing, integrating, testing and releasing at a cadence that you feel comfortable with - and so the whole concept of Continuous Delivery becomes much more 'natural' with Kanban.
If you haven't read it yet, I'd highly recommend reading David Anderson's book that is generally considered the Bible of Kanban - "Kanban: Successful Evolutionary Change for Your Technology Business". If you are interested in using Scrum with Kanban, you should read "Scrumban - Essays on Kanban Systems for Lean Software Development" by Corey Ladas. Finally, you may also find this blog post interesting - "The NextGen (Agile) Tester".
Few definitions to focus on before jumping onto the differences:
Agile – A structured and iterative framework to track and manage projects. This approach is used in managing software development projects. It allows cross-functional teams to collaborate on users expectations. Kanban – A framework which utilizes visualization technique, limiting the number of tasks to be taken in “Work in Progress” column. The segregation of a similar type of tasks can be done here. To simplify it, allocate colours to tasks using the swimlanes. Scrum – The approach followed here is breaking down a complex task into simpler smaller manageable pieces which are easy to collaborate upon by the respective owners of the scrum.
Similarities between Kanban and Scrum
Frameworks of agile methodologies Used to track the progress of the project Provide the team transparency in tracking the work progress Make use of visualization
Differences between Kanban and Scrum
Roles – Scrum is dependent on the scrum owners and is worked upon by them respectively. Kanban is independent of cross-functional team members and parallel roles.
Release cycle – Scrum makes use of sprints whose duration varies from one week to two weeks. The user stories are then taken up for development, testing and bug fixes. Kanban does not follow any cycle and the process is continuous in nature.
Tracking parameters – Scrum makes use of velocity in planning upcoming sprints taking into account the complexity and number of user stories completed in the previous sprint. Kanban ensures limiting of user stories in “Work in Progress” column to avoid bottlenecks. It tracks the time taken to finish a task from the starting to the end.
The scope of improvement – Scrum does not encourage changes in ongoing sprints. Kanban is open to any changes before the completion of the project. It is flexible in nature.
Fit factor – Scrum is suitable for projects with clearly defined user stories. Acknowledgement on the same by the client for timely completion of the project makes it a fit. Kanban being flexible in nature allows variations in priorities on the basis of the current scenario.
Pick process – Scrum picks the entire batch of user stories from the product backlog for development. Kanban follows the maximum number of tasks allowed in the columns to maintain the sanity of the framework and to avoid bottlenecks.
Delivery – Scrum follows delivery based on sprint planning and prioritize based on the specifications given by the client.Kanban follows the continuous delivery model based on business needs.
The above points are easy to remember if you are able to visualize working on them. Ideally where the scrum follows a rather predefined set of principles. Kanban is backed up by the principle of flexibility. It allows you to track tasks that are of utmost importance for delivery.