Last month I started reading the book “The Lean Startup” By Eric Ries ( At first I was skeptical about the concepts, mainly because everyone and their mother was talking about it. However going through a few pages, it started making sense to me. I have never been a real fan of conventional process heavy development strategies. Finally someone took out the time and wrote down how successful software applications are actually made, and its not because they follow PMBOK to the punctuation.

I don’t want to bore you with the details, as you can find great synopsis of the book online ( The reason why I mentioned the lean startup is that working in an offshore software consulting services company, every time I talk to my QA team, they have the same complaints. They are being used as testers and not as QA engineers. That they’re just asked to do monkey click testing and there is no process. When I ask them about process they say they need double the time given, not only that, they need the rest of the team to write 10 different documents, in reply to which as you can image, I humbly say “Hell no!”.

Recently being put in charge to revamp the how QA works in our company, I needed some creative ideas around this. So I began to think, there must be an approach that fits with the Agile, Scrum, Lean startup projects of the world. And it has to be better than the conventional QA process of ‘Thou shall not pass without the holy manuscripts! Bring forth the FS and SRS’ (I never really understood why people got high on dropping acronyms on other people). So I googled Lean QA and Agile QA. To my excitement I found the following slide deck presentation and a documented process on Agile QA.


Introduction to Agile Testing –

Agile QA Process –


So if you have a project that follows some form of agile, scrum or lean startup process, you must have heard the complaints from your QA team that

    1. There is no compiled documentation. They need proper documented specs that are updated at all times
    2. You don’t give us enough time for test cases
    3. The hours may seem high, but we will need to test everything again each time there is a small change
    4. Don’t expect a quality product since you didn’t provide us the above

Dilbert trained on Agile


I believe we’ve all heard these and more. So what’s the solution you ask? Well first of all we need to change the mindset, its not us versus them, testing or the ownership of quality is not just for the QA engineers, the whole team is responsible. Roles and responsibilities will overlap.  So how do we do this?

    1. The QA engineers need to be part of brainstorming and planning meetings. This is where they get to know what the specs are. They can use their experience to clarify functionality and point out ambiguities, and scenarios that were overlooked by the PM.  Developers and QA have the same understanding of the feature and what it means to call it DONE.
    2. The brainstorming sessions needs to happen for each milestone/sprint/iteration, not just in the beginning.
    3. The QA team gives/updates their own estimates for each milestone or sprint.
    4. The QA team works with the PM and dev team to design the tests. Passing these tests means DONE. Devs know that and thus keep these points in mind while developing the features.
    5. Automate the designed tests, its not that hard and it saves a lot of time for exploratory testing.
    6. A QA representative should be part of demo/showcase to the customer/stakeholders at the end of each sprint so that they get first hand information of how the build was received.
    7. Each story will have some acceptance criteria, written against the story, that is the base test scenario.
    8. Understand the changes in each build, with the PM and Dev teams help, don’t work in isolation.


These were some of the tips summarized from the presentation and process document. Since Automation is a key ingredient for lean QA, you must be thinking that requires an expensive solution from the guys at Mercury or IBM. Well you should look at Selenium IDE and Selenium WebDriver instead ( It’s free, Google, Facebook and many big name companies use it! It has all the capabilities to automate even the AJAX heavy applications. If mobile apps is your thing, look at Appium (

As you can imagine, there is no one size fits all in application development. However I think the above is a good starting point, you can decide on your own process that’s not conventional and it lightweight enough that it can be repeated in the challenging timelines and changes we face in our projects.


Happy testing, less whining!