Test Approach: Agile + Kanban

The most common question that pops up is- Do we have any standard approach for testing a application in Agile + Kan ban environment. The answer is simple- No. To justify my understanding lets look at what is Agile and Kanban all about. We will then see what is the most working testing approach in such environment- (I have taken most of the references from Internet which means all the credit MUST go to original authors. For the references please see end of this document )-

Agile

• People across functional areas (programmers, testers, technical writers, sales, services, product managers) all work together as one team rather than different groups working in 'stages'.
• Everyone in the team falls into category of ‘developers’ as they work together to develop and improve a product.
• Iterative development (work in short development cycles with focused objectives).
• Incremental development (frequent releases to client) .
• Focus on human communication 
• High visibility of team's progress to management, stakeholders, clients  using daily stand ups.
• Continuous feedback from customers and stakeholders.

Kanban

• You’ll find a lot of terminology in Lean software development comes from Japan and from the Toyota Production System in particular. Kanban translated literally: “Kan” means visual, and “ban” means card or board.
• Kanban is a new technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's "just-in-time" (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.
• Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top.
• Limiting work-in-progress reveals the bottlenecks so you can address them. Limitations that we saw in previous slides can be taken care of by Limiting work-in-progress.
• The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits on the number of cards allowed in each column.
• The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand.

Test Approach in Agile + Kanban 

• Create just ONE document- Overall test strategy. No one reads test plan during sprint execution.
• Test strategy should be important to the devs, testers, product owners, automation creation & maintaining folks
• Test strategy should have - which exploratory test charters are planned during the current sprint and put that into the Test column
• Describe a loose framework that describes what we are going to do for stories, what we are going to do for integration, what we are planning to do for our exploratory testing that doesn't fit in to stories, and then when we are going to review our test strategy?
• Write logical acceptance criteria.
• How to handle backlog items?
• Test strategy drives entire development team and explains HOW you plan to start testing
• Each story assigned to the sprint should have test tasks in it, that becomes your defacto test plan.