Lean Testing

Development · Sep 30, 2013

At TELUS, our Digital Channel team has begun a long and loving relationship with lean and agile methodologies. For my team (the testing team), this incredible relationship means quickly learning how to translate or in some cases, rebuild our processes. Lean promises to produce Minimal Testable Products (MTPs) and Minimal Viable Products (MVPs). This also means a lot of broad team collaboration, information sourcing, trial and error. From day-one however, the department’s mantra has been: “One team, One dream”, so failing fast and recovering was done not only fearlessly but also quickly and collectively – truly an incredible experience.


As is the case with any good team, we applied the strengths of these methodologies, combined with good practice, to develop a framework that works best for us. Testers are more than just testers. They are a part of the team from the inception and remain heavily involved throughout the sprint cycles. This includes being, at a minimum, privy to all aspects of the sprint cycle. As such, cross functional teamwork and communication is at the heart of our scrums. Geographical barriers are knocked down with the assistance of universal and easy to use technologies such as Skype, G-chat, webcams, Basecamp, Trello and phone calls. You name it and we’ve likely used it.


As we move towards Test Driven Design (TDD), coding and testing (both manual and automated) happen side by side in very quick iterations. All activities are time-boxed and testers make decisions on how extensively to test each scope item. In essence, a risk based approach is used to determine which test activities are going to be carried out for a particular scope item during an iteration. The risk level of every scope item is determined by its sprint team, their stakeholders and our customers. This allows for the process to be transparent for everyone including customers.

Being involved in each sprint, gives the testing team a comprehensive understanding of that sprint’s scope. This knowledge allows a tester to ensure all aspects of the web development are tested. As such, testers have an in-depth understanding of all products and services. Furthermore, the bugs/defects found during testing are often used as a feature improvement. Testers are innovators. A Tester’s extensive knowledge and contributions make them an invaluable resource.

As efforts get underway and the developers become busy coding, we testers get busy with prepping our scope approach (including any changes encouraged by client feedback and validation), then begin testing items as soon as they are published.

Code is tested in a ‘working branch’ (a web URL that is similar to production) prior to being launched in staging followed by production. Consider the ‘developer’s branch’ as a developer’s playground so to speak. This is the initial branch which they built and experiment with new code without risking or breaking existing code.

Code defects (aka ‘bugs’) get reported back to the developers as they are discovered and then retested after they have been resolved. This cycle within a cycle – Code > Test > Fix – can continue throughout our pre-staging branch (or ‘working branch’). The code is then moved to staging followed by the production environments until we have a Minimal Viable Product (MVP) to launch and gather feedback on. Regression testing is also performed at each branch level to ensure there has been no degradation to previously developed (and cycled) code.

Bug Bashing

Working in an agile environment allows for us to identify bugs in their early stages. At the end of each sprint cycle, as developers finish publishing their code, they’ll begin dedicating more time to bug fixes and this sudden and acute focus on attacking the remaining bugs requires the initial management of those bugs be extremely well organized, clear and concise. As result, all associated activities are carefully scheduled, resourced and monitored to ensure that bugs are properly triaged based on relative severity and priority levels. This process ensures quality as the product is double tested prior to the first bug elimination.

So far it has been a roller-coaster ride. New concepts are being implemented that hold a promise in terms of improving existing process and methods. So as we settle down and embrace change, we realize that change is pretty cool.

Authored by:
Sana Minhas
Sana Minhas
Scrum Master