Wednesday, 27 July 2016

Tester’s role in Agile

Thank you for all the responses and requests. This post is for all of them who have requested to share some more information on “Agile” projects as well as the tester's role in the project.

While working on different projects in Agile, I have understood that the testing skills required for agile projects are tested more with in very little time. In my previous post, we have seen the skills required for testing and now we will see how these skills are applied in Agile.


In agile testing, tester is a part of development team. He will be closely working with development team to help them improve quality of the deliverables. This is a critical task and required good communication. Usually communicating to the development team and communicating to agile team is different.
Agile manifesto - Individuals and interactions over processes and tools.
Agile teams are expected to work as one unit and hence the communication between each individual team member becomes paramount important.

Business Knowledge

Within team, most of the time development team rely on the tester for quality. In agile due to quick deliveries and shorten cycles development team expects that tester should provide good reasoning for any quality issues identified. Hence business knowledge required for tester to work in Agile is less important to none.

Technical Knowledge

As tester is closely working with developers and tester is a part of the team, it becomes essential that tester understands the technical discussions. Most of the time testers are exposed to all such technical discussion and then expected to provide some thoughts from improving quality. If tester is very well aware of the technology then it is very useful to help developers to understand the quick quality issues which may otherwise surface.

Issue Resolution

Sometimes in Agile developers are ready to fix the issues within given time if the issues are recognized early in development stage. Well experienced tester can point out issues in the functionalities, design or code and also have courage to explain it to the development team.  The tester helps team to make the demo successful for acceptance of the deliverables by product owner. Any issues if found should be recorded and should have a proper schedule for rework. The success of agile team depends on the tester and his involvement in issues resolution.


All the repetitive task should be automated at the earliest possible to utilize all the available time for process improvements and quality deliverables. Most of the time functional testers involved in the Agile with no or less automation appetite will results in time consuming testing process. The overall result is not so good which is otherwise possible. Automation can be as simple as checking if the environment is ready with the automated scripts rather than manually accessing the environment. Also running sanity scripts as soon as the code is deployed.

In Agile, testing is quite different than otherwise. Tester is individual contributor as well as responsible for team’s quality deliverable.

We will see more on testing in upcoming posts. Till then,   

Keep Agile!

Thursday, 21 July 2016

Myths of Software testing

Following are the some common myths of Software testing –

1. Anyone can test the application and couple of hour’s session is enough to start testing

Reality – Testing is a skill and an art. Testing is not as easy and as pie. Tester becomes great tester with experience. The tester should have qualities like Observation, Reading between the lines, Probing, Patience, Understanding perspectives, Knowledge about testing practices, Ready to dig deep,  Fearless and Strict follower of quality process.

2. Everything can be tested and application will be 100% bug free

Reality - The testing is to uncover the defects or bugs in the applications. Testing is related to cover the application functionalities with some definite scenarios. This is also called as coverage. With all the possible coverage only critical defects will be uncovered from the possible finite paths. There are always possibilities of having more combinations of inputs, process and could be different negative scenarios. These may uncover more defects and still it is not possible to assure 100% bug free applications.

3. Testing is less important than development and testing can be done any time during development lifecycle by any developer

Reality – In real world testing is as important as development or sometimes carries more value than the development. There are many examples of great looking software failing due to inadequate testing and quality checks. Developer as mentioned above will not have the art of testing and more important will not have the objective of testing. Hence developers cannot be testers unless formally trained and worked on couple of projects with actual testers. There are a few real life examples where developers who tried to enter in testing failed miserably. Testing starts early in the lifecycle, as early as the requirements are drafted. The static testing will uncover the requirement defects; here the domain experienced tester plays a critical role.

4. Everything can be automated and will not require manual testers. Any automation tool can be used to automate and QTP / Selenium are the only options to automate.

Reality – Purpose of Automation is to avoid repetitive manual tasks. If the task is not repetitive then investment on automation is not worth. For example one of the web applications required a few field validations on one of the form which manually takes 2-4 minutes, if this is automated it will take a day’s efforts, and automation tool. Such single features cannot be a candidate for automation. Technically functional testing alone cannot be considered for automation. However the regression suite can be a good candidate of automation. Manual testers will test the application manually and then those functional test cases which are critical to business will become a part of regression suite. This suite can be automated. Apart from automating regression suite few other repetitive tasks like smoke test and sanity tests can be automated.
Automation can be only feasible once the application feasibility test is done. There are many tools available in the market. Few tools are free to use and others may have some licensing fees. The application feasibility to involve but not limited to checking application technology, application environment, application architecture, deployment frequency and regression test cases are available.


Thursday, 14 July 2016

Protractor – Open Source - End to End testing

I would like to thank each one of you for your responses to all my earlier posts. Let’s continue our journey to open source testing tools.

Recently I got a request to write on Protractor. In one of my earlier projects I got an opportunity to work on Protractor. So I am writing on Protractor in this post.

Protractor is an open source end to end Node.js framework, primarily for Angular.js web applications testing. Before we get into details of Protractor, let’s quickly look at Angular.js.  

To know Angular.js, we must know HTML, CSS and JavaScript. If you have followed my earlier post on BDD then that will help to understand the Angular.js and Protractor.

Typical webserver request – response is as given below -


However, the request response will load the network with heavy traffic and will result in slow websites. The solution is instead of requesting for every time for each user action; add little functionality on client side. To achieve this we have JavaScript and one of the client sides JavaScript framework is Angular.js. This way we can have interactive and fast responding webpages.

Above diagram simplifies the concept of fast responding web page. Within HTML pages where ever it finds directive (marker of html tag) it tells Angular to run or reference java script code. I need to stop Angular.js here as we are interested to know Protractor.

 However if you are more interested in Angular then please take a free course on Angular.js -

Now let’s move on to Protractor. As we discussed in the beginning, Protractor is an open source end to end testing framework. It will test how users will see the web application, is the communication right between backend and front end etc. This is BDD with more of a white box testing. So as shown in below diagram we will use Cucumber to write high level scenarios. These scenarios will be further using Protractor tests. Protractor tests will then send requests to Selenium server. Selenium server controls the local browser.  

Webdriver (Selenium)
AngularJS App

Protractor needs following files
          1.  Spec file
          2.  Configuration file

Protractor communicates with Angular.js and waits for browser to finish the task. Hence Protractor does not need to wait or sleep. This makes it most optimized approach for automation.
Protractor allows tests to be organized based on Cucumber, thus allowing you to write both unit and functional tests on Cucumber as discussed in my previous post.

We can use Protractor on real browsers (Chrome, Firefox, and IE etc.) and headless browsers. For Protractor we need to have Selenium standalone server.
Protractor is useful if you want to test end to end however if anything fails during end to end tests, it is difficult to debug and find the issue.  

Protractor basic code is available at-