“Build the right software” with the “Need for speed” and “Do it the right way”.

I have always asked myself during the period of my MBA study: Are agile methodologies good for software projects? My answer is “Yes”, they are good but not enough. And then I asked myself why they are not enough? What I have seen in the last 3 years shows that just following the Scrum methodology does not solve all problems. Let’s take a closer look in the three fundamental goals of agile software development to move forward into the future mentioned in Michael Dubakov’s post “The future of agile development”. Every other company in the market wants to „Build the right software” which is also the ultimate goal to generate revenue by catering their users with what they want to see and use. Most of the companies following scrum methodology have done reasonably good and has also generated huge public interest. To understand the needs of its customers, they have created a feedback cycle where the customers are also involved directly or indirectly. These interactions with the customers provide valuable information and many of them are golden opportunities to improve.
The second goal which arises is „Do it the right way”. Often when you create the right software, the job is half done and if it is not done the right way your mission is not complete. Users might be able to solve their problems but with an in-stable software which might crash now and then. When software is poorly coded it is very ambiguous, it might look good on the user interface and also might prove helpful but a reality check could reveal it is a train-wreck which could rattle anytime.
Most of the software companies have already implemented a methodology with a goal to test ideas first and check its viability, which also highlighted the third goal of agile software development: “Need for speed”. Normally these test ideas are transformed into working software with very few unit tests and a lame architecture/framework in the need to launch the idea to a targeted audience as fast as possible and prove that the product concept is viable. Eventually when the product concept works, the whole software block is rewritten right from scratch, keeping in mind the architecture, framework, scalability, and performance with lots of unit tests which might take a few more sprints. So this shows that „Do it the right way” is time-consuming and sometimes fails to catch up with the needs of the users.
When projects are getting complex, the speed drops due to the various factors attached to “Do it the right way” and this speed factor is very important for any competitive company. It is necessary to create software fast so that the firm can test the product concept and its viability. Once this is done the company gets a second chance to try various options to tune it to the user’s behavior and also “Do it the right way”. If a firm does slow work, there would be no second chance and probably would fall to the competition in the market.
Therefore, agile development process should “Build the right software” with the “Need for speed” and “Do it the right way”. Thus we have a development process with clear goals which should guarantee success (hypothetically). But the question that arises in my mind now is: How do we keep all these three goal in sync?

Representation of Agile Development Goals

The circles in the above figure depict how the three goals would overlap each other and also show some pros and cons. It also shows the ideal situation for software development. When “Build the right software” overlaps “Need for speed” without taking “Do it the right way” into consideration it would work for trying out new product concepts. But it would also mean putting off problems to a later date if the product concept is viable. This could be expensive at times.
When “Build the right software” overlaps “Do it the right way” without taking “Need for speed” into consideration it would mean that the company is likely to hit the jackpot if it has no competition. But the firm could completely miss out on market opportunities if the product concept is viable due to slow speed or the company would make huge losses if the product is not accepted in the market.
When “Do it the right way” overlaps “Need for speed” without taking “Build the right software” into consideration meaning the company will have a wrong product in the market which no one needs. The company could learn from the market reaction and understand what went wrong and make fast changes. Ideally this situation should never happen if the product team has done its homework.

Capture Screenshot with PhantomJS for RWD test

Here is a little script that could be used to capture screenshots for a responsive webpages with different view-ports and save them as *.png

var async = require('async'),
sizes = [
[320, 480],
[320, 568],
[600, 1024],
[1024, 768],
[1280, 800],
[1440, 900]

function capture(sizes, callback) {
var page = require('webpage').create();
page.viewportSize = {
width: sizes[0],
height: sizes[1]

page.zoomFactor = 1;
page.open('http://werkstatt.autoscout24.de', function (status) {
var filename = sizes[0] + 'x' + sizes[1] + '.png';
page.render('./screenshots/' + filename);

async.eachSeries(sizes, capture, function (e) {
if (e) console.log(e);

Have fun

Behavior Driven Development with 3 Amigo’s task

In Scrum, a story is presented in planning with a story template that would look like:

As a [X]

I want [Y]

So that [Z]

This can be elaborated as the following, the person or the role “X” wants to have a feature “Y” so that he/she could be benefited by “Z”. But this could often lead to misunderstanding as depicted in figure below:

Representation of Communication Gap in a Story Grooming Meeting

Representation of Communication Gap in a Story Grooming Meeting

Everybody in the team could have a different understanding of the story being presented in the sprint planning and could de-scope some of the more esoteric requirements (North, 2006). This misunderstanding could be avoided with the help of sketches which could be presented in the sprint planning as depicted in figure below.

But a more feasible solution to this situation would be the use of a domain specific language (DSL). Every QA engineer knows that a story’s behavior is simply its acceptance criteria and if the system fulfills all acceptance criteria, then the system behaves correctly or vice versa. Therefore a QA engineer needs a template to capture a story’s acceptance criteria which could be done with Behavior Driven Development (BDD). (North, 2006)

Representation of Good Communication with Sketches

Representation of Good Communication with Sketches

BDD is usually done in DSL a very English-like language that helps the domain experts to understand the implementation rather than exposing the code level tests. It is defined in a GWT format, GIVEN WHEN & THEN (What is TDD, BDD & ATDD ?, 2012). The BDD template is loose and structured enough so that it could break the story into different scenarios based on its acceptance criteria. A scenario template would look like:

Given some initial context (the givens),

When an event occurs,

Then ensure some outcomes.

The QA engineer could develop these scenarios from acceptance criteria in collaboration with the Product Manager/Owner. The scenarios with “given”, “when an event”, “then an outcome” are fine-grained enough to be represented directly in the code. The QA engineer could collaborate with the developer to represent these scenarios in the code which would then be part of the acceptance test for the story. A simple representation of the scenarios in coded form would look like:

public class someinitialcontext implements Given {
public void setup(Someinitialcontextsomeinitialcontext) {

public class aneventoccurs implements When {
public void setup(Aneventanevent) {

public class ensuresomeoutcomes implements Then {
public void setup(Outcome outcome) {

Test Driven Development (TDD)

Test Driven Development (TDD)

BDD is test driven development (TDD) in many ways except that the word “test” is replaced by the word “Behavior” and is meant for a broader audience which include Product Owners and stakeholders. In both the methods of software development, the tests are written upfront and made executable, then implementation of a unit is done and finally the implementation of the unit is verified by making the test successful.

Implementation of 3 Amigo’s Task

The decision to implement the 3 Amigo’s task solely depends on the team if they want it. In my case the Scrum team wanted to try something new in the field of testing. The following process evolved which was loosely based on the  “Introducing the Three Amigos” by Ryan Thomas Hewitt. It was accepted as a sprint task and was defined and adopted by the Scrum team. The “3 Amigo’s” were the Product Managers/BA’s, the QA engineer, and a developer who collaborated together to define the scenarios from the acceptance criteria for a story.

Steps involved in 3 Amigo’s:

  • For every new story a task “3 Amigo’s” is defined in the sprint planning meeting.
  • “3 Amigo’s” task is considered to be the first task for every story in the sprint.
  • Immediately after planning the Product Owner, the QA engineer, and a developer create a meeting and collaborated together to define the scenarios.
  • The scenarios are represented as code by a pair of developers or a developer-QA engineer pair.
  • Development of the code is started parallel to or after the implementation of scenarios as executable acceptance test.

Advantages of Performing 3 Amigo’s Task:

  • Performing “3 Amigo’s” task within the sprint showed high level of collaboration between the three parties involved in the sprint: the Product Owner/Manager/BA, Developers and the QA engineer.
  • Performing this task also means that the acceptance tests were written and automated even before coding started.
  • The scenarios where written in Domain Specific Language (DSL), which means everybody in the team could understand the scenarios and no coding skills were required.
  • The QA engineer had more time performing exploratory test as story acceptance test was already automated.
  • The story was accepted automatically when all acceptance tests represented as scenarios were successful.
  • “3 Amigo’s” task could be a pre-planning task, where the QA engineer could collaborate with the Product Manager/BA and define scenarios for each acceptance criteria.
  • The scenarios could be presented directly in the sprint planning meeting to the whole team.

Future Experimental Work

  • “3 Amigo’s” task could be a pre-planning task, where the QA engineer could collaborate with the Product Manager and define scenarios for each acceptance criteria.
  • The scenarios could be presented directly in the sprint planning meeting to the whole team.

Quality Stages in Definition of Done

Yesterday at work I was in a meeting with my team to redefine our definition of “Done”. During this meeting one of them pointed out that every level in the definition of done should include a quality gate/stage where QA Engineer’s can play some role if not the main role. In traditional development, QA Engineers were only performing functional tests and reporting bugs. But agile software development is a highly integrated process where each stage: requirements, design and development could impact the amount of effort needed for testing. I have noticed a number of releases which had quality issues and these issues were not found until or after the release. Some of these issues were also considered as “showstoppers” and needed an immediate bug fix release. If these quality issues could have been detected and prevented during the stages (requirements, design and development) then the effort required in final system testing would go down. I have  derived the idea of Quality stage from Quality funnel mentioned in Agile QA practices of Code71, Inc. (Rayhan, 2008).

Quality Funnel

Quality Stages in Software Development

Different Stages of Quality

Quality Stage 1: Requirements Review. Every story in the product backlog item should meet INVEST (Vaibhav, 2007) which means a story should be independent, negotiable, valuable, estimable, small and testable. This should be part of the ongoing pre-planning activities like story grooming/estimation. The QA engineer along with the team can collaborate and help the Product Owner identify requirements which are forgotten or gone missing and also identify issues which could result in an incomplete product. In general, issues which go unidentified in this stage are “hot issues” and can stop a live release(If you are not using Feature releases ;)) and result in “failing sprint”. Therefore, “Requirements Review” is the most important quality stage. Normally a story should go through this stage more than once for a story to be ready for sprint.

Quality Stage 2: Design Review. Make sure the design for the story is in-line with architecture guideline/style and related requirements are met. Normally if a bug/issue is identified in this stage it means the product does not work as intended. The issues found in this stage could be a “Hot” or a “Cold” issue.

Quality Stage 3: Development Review. Make sure all appropriate unit tests/behaviours are defined and automated. Coding standards are followed. Code review is performed and all unit tests are successful and part of continuous integration. In general bugs/issues that appear during this stage are regression bugs which appear when a new feature is implemented on the existing functionality. These bugs are normally cold issues and should be fixed in this stage.

Quality Stage 4: Test Review. Make sure all appropriate UI functional tests/behaviours are defined, automated and executed as part of continuous integration. All exploratory test session should be defined and executed. Similar to the previous stage bugs/issues that appear during this stage are regression bugs which are cold issues and should be fixed in this stage.

Proposed Usage of Quality Stages

Analyzing the current situation, a feasible solution would be to include the Quality stages in the definition of “done”. The QA Engineer can play the role of a Quality Consultant and collaborate with the team to perform requirements review, design review and development review. By doing this the QA Engineer would ensure better quality at every stage of agile software development and avoid situation like forgotten requirements or tasks within the sprint and reduce the effort needed in the testing phase.


Happy Easter!!!

From Traditional QA Engineer to Agile test consultant

Quality Assurance in Traditional Software Development

Quality is an inherent element in agile development and it is commonly told that agile professionals are quality infected or test infected (Ambler, 2005). In traditional development processes, QA had never worked closely with software developers and was also not involved in the project in the early phases. They often played the so-called “gatekeepers” role telling project managers “Sorry, the requirements are frozen; we can add the feature in the next release.” (Lisa Crispin, 2009)

QA never controlled how the source code was written nor checked if the developers tested their code, neither collaborated with them in testing the code. QA carried out testing only post development and had the power to stop software releases from going forward if problems were identified. They were also involved in a lot of documentation work like creating test plans, bug tracking and reporting, change request, etc.

Traditional development cycles were long and the development teams focused on making sure all the specified requirements were delivered in the final product by the release date. In my experience, most of the time release dates were not met and were postponed to a future date. The development team was usually made of experts, and most of the time the team had no idea on what features were going to go live in the next release.

It was the QA’s job to read the requirements and create their test plans for the feature which was going to be released. Often the test plans were created from requirements parallel to the development of the product. QA engineers often had to wait for work as testing normally took place at the end of the project (Lisa Crispin, 2009).

Transition of Quality Assurance into Agile Software Development

The transition to short iterations of agile development produced an initial shock wave. This was also felt in the quality assurance department. Most of the QA engineers now also called as Agile Testers/Consultant whatever…. had questions in their mind and some of them were: how can I define requirements and then test and deliver the production department tested code in 2 weeks? How can I test parallel to development and that too within 2 weeks?

QA engineers also had to learn that the quality criteria would be defined by the customers or the Product Owners. They also had to be prepared for the challenge of testing a product based on acceptance criteria without any test plans. QA engineers were now part of the development team where the role of QA transformed from merely a tester or a bug finder in traditional software development into a consultant’s role who had to educate the development team in how they could improve the quality standards of the product with combined effort. QA engineers also had to learn how to code automatic tests as it became a necessity to maintain speed and make timely software releases. QA engineers took part in all Scrum meetings and perform manual acceptance testing tasks when coding was completed.

Initiation of QA activities in Traditional Development & Agile Development

Challenges in Agile Quality Assurance

Agile being iterative and incremental meant that the QA engineers had to test each incremented piece of code as soon as it was completed. A Scrum iteration is about 2 weeks long where the whole team collaborates to build and test a little piece of code or feature and makes sure it works. But what I found unusual from my interaction with agile consultants and developers was the level of “done” did not apply to the testing tasks. Normally developers should never get ahead of the testers/QA, because a story or feature is not “done” until it has been tested. Thus the collaboration between developers and testers was weak when it came to manual testing tasks; testers were solely responsible for manually testing tasks at the end of the user story. QA engineers were also held responsible for final acceptance tests on a shippable story on the staging environment before it was released live.

Although being agile has a lot of key benefits, adapting to this new process can be a challenging task. More involvement of customers and stakeholders in agile development has introduced a unique approach to meet requirements and specifications. Being agile also means that this methodology is flexible to change and more effective for development. Yet, agile methodologies have been under critic and are facing challenges to get an overall acceptance over traditional software development.In the next post i will try to point out some challenges QA engineers/ Agile Tester  are facing in agile development based on inputs from  semi- structured interviews, personal work experience and a survey.

Agile Manifesto

Agile software development has changed the way software development used to work in the past. The agile approach prefers shorter iterations for software development processes unlike the traditional development approach. Agile processes also emphasize that the software development iterations should be shorter, incremental and people centric. The manifesto for agile development states:


Visual Representation of Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more (manifesto).

Agile software development encourages people collaboration as compared to the traditional software development processes. It also responds to changes more effectively because the development process is incremental and iterative. In a single iteration of agile development approach all required phases of software development (planning, design, development and analysis) take place one after the other (Malik Imran Ullah, 2009). After the completion of the iteration the software product is reviewed by the customer. The next followed iteration will start to add the required feature/functionality based on the customer feedback. In the following post  I will mainly focus on “Scrum” and “Kanban”, which is a light weight agile methodology and also focus on how “Scrum” has changed the way QA activities are performed.