Sunday, March 6, 2016

Mapping lean principles to testing


Do's and don'ts for testers is my most viewed post so far. Because of that (and because it's always better to leave various doors open) I wouldn't focus on technical posts only. Time for something my colleague accurately calls computer science belles-lettres.

I you had read my Management 3.0 review you know that I like to get familiar with views on software testing not only from our (QA's) side, by also from our peers (team members, managers, project stakeholders and clients) perspective. Actually, in my opinion focusing only on testers view is probably ISTQB's biggest flaw. Never mind ISTQB, and let's move to the business.

Today I gave myself rather ambition task to map Lean principles to testing activities. Why lean? I read recently Mary & Tom Poppendieck Lean Software Development - an Agile Toolkit and Aaron Hodder blog post which inspired me. Also I like how lean practitioners focus on system thinking, trying to optimise the whole instead of single activity.

So how we, as testers, can adopt lean principles?

1. Eliminate waste

Anything that does not add value to a customer is a waste. In many old software testing books we can read that every release candidate has to be blessed by testers and deployment to production without manual regression is not acceptable. If you are familiar with Netlflix deployment cycle you know that  smart deployment is possible without any testing at all. However in most of the cases that's not possible, so how do we decide when to go live? 

I think we should measure two things - cost of delayed release (due to testing) and cost of finding a bug in production. I can't tell you how to measure it, because it depends on your type of business. Make sure you're not delaying your awesome feature release because you want to find all bugs in manual regression process. We can't find 100% of bugs anyway. Simple as that.

So to summarise it I suggest:
a) expanding automated checks suite (according to test pyramid)
b) hiring skilled exploratory testers which can quickly find flaws in release candidates
c) automating deployment and measurement how it's working on production (all those continuous delivery and devops stuff)
d) calculating costs of activities which I bolded above

2. Amplify learning

This one is simple and hard simultaneously. Software testing is technical activity which require more and more skills. You may like it or not, but the best testers I had encountered in my short career had broad knowledge on almost every do's from my post. So recipe here is simple: learn, analyse, make mistakes, fix, learn. Adopting right mindset may be helpful here (see my 'Obstacle is the Way review').

I'm planning to write a post 'Recommended resources for testers' soon. This may be helpful for you. Stay tuned :)

3. Decide as late as possible

Throughout every software project the product under development changes considerably (if you don't believe just see screenshots from any alpha version of video game - Starcraft for example). Because of that preparing detailed scripted test cases before is a waste of time. We should focus on building common understanding of business goals. If you are BDD practitioner you probably know that's the key to success.

The most popular testing design style - Page Object Pattern was implemented to simplify maintenance work. When you write automated tests have in mind not only stability, but and maintainability. Product will change eventually.

4. Deliver as fast as possible

Make successful delivery of right product (and in right quality) your goal. We shouldn't block release just because we think more will help us find more bugs. I had discussed it already in point 1. Testers should not be considered as project bottleneck, because smart people tend to focus on them. Yahoo probably thought that, and they fixed it in spectacular way. Once again, because I think it's important: make successful delivery of right product (and in right quality) your goal.

5. Empower the team

That's right, the team. Not developers, not managers, the team. This means that lean practitioners want to empower you. All you need to do it to take this responsibility. In healthy companies power depends on knowledge and experience. So, theoretically tester can be the most important person in a team. Because why not?

6. Build integrity in


According to Poppendieck team we have two types of integrity:
a) Perceived integrity - a system is perceived to have integrity when a user thinks, 'Yes! That is exactly what I want. Somebody got inside my mind!'
b) Conceptual integrity - a system has conceptual integrity when it's stable, expandable, fast, releasable, meets legal constraints and all those *ility testing types you may have encountered in books

It's tester job to think about that and ask developers unwelcome questions during standup meetings. :)


7. See the whole

Last but not the least. As I said before, we should always try to optimise the whole project, not just testing. This means that tester should do some quality control (QC) work too. If the process is inefficient, if we build bad product it's our job to report it and give it to consider. We should measure quality be project revenue, not by number of bugs.