Author Archive

Companies often spend a lot on performing test automation to reduce the efforts spent by testing team. We read a lot about how to make the automation projects successful, but, have you ever thought on how you can achieve it otherwise. If you are one who want to make any of the automation initiatives unsuccessful, do proceed reading further.

Don’t involve team during planning

Planning is not important. Just tell people what areas they will work and they will deliver. This will ensure that people are spending time in delivering what they are asked to do without putting their brains behind.

Select tool based on team knowledge

Irrespective of the technology used by the application, use the tool that the team members assigned to the project knows. Don’t waste time on hiring or updating the skill sets of people.

Estimate based on your scripting speed

Don’t consider test case complexity/team skill sets/learning curve/hiring time etc while estimating the efforts. Just estimate based on how much you alone will be able to achieve.

Automate areas having high probability of changes, first

Consider that the critical areas from the point of testing are the ones that are getting changed in every build. Start automating them first. This will ensure that the team spends the time on maintenance rather than new development.

Freeze the build for the complete duration of project

Before starting the project, be strict on not changing any product build, irrespective of releases made to the testing team in between. Just make your scripts compatible with the initial version of the build provided to you. This will ensure that your scripts do not run on the latest build and hence will help in failing the UAT.

Avoid any communication with stakeholders

Stakeholders always ask for reports that often decreases the productivity. They also do not have any rights to get information on the challenges that the team is facing. If you want to fail miserably, it is seriously advised not to tell stakeholders anything about the project before the final delivery.

Keep Script integration at low priority

Do not estimate for script integration and do not even care for it. If time permits, then do it immediately before UAT so as to ensure there is enough evidence of script not working.

In case you have any other tip, request you to share it in comments and I will add it up in the upcoming post.

There are many instances where it has been seen that organizations complain of not getting enough ROI from their automation initiatives. When they get to identify this, the blame game starts and people start pin pointing the test automation team for not creating the right strategy beforehand.

One of the major issue that I have seen is that many a times people are reluctant to admit that there needs to be a dedicated effort and plan in place for automation. They feel that if they outsource the work of framework development to any third party contractor / vendor and then ask the vendor to train the current manual/business team, the job will be easy. In case of optimization of efforts, they might be correct, but they fail to understand that this will put a lot of burden on the automation solution and it might not be best designed based on product needs.

Another issue that I have seen is that the current testing team (with manual mindset) is asked to upgrade the knowledge and start the automation work in their free times. This again puts a lot of risk on the whole initiative and at last it does not work for the long term.

We all definitely need to understand that the automation is not a part time activity that can be done by part time people. It is a niche skillset that is equivalent to development. As any product success depends on a good architecture and team, automation solution is also dependent on a good framework architecture and good team.

On a high level, the automation plan / initiative should consider the following from team perspective

  1. What do we want to achieve from automation?
  2. How will we achieve it? Do we need to hire from outside or do we have experts inhouse?
  3. If we hire the complete team from outside, what will people do once automation implementation is completed?
  4. Can we hire experts using subcontracting? What is the rampup and rampdown plan?
  5. How to handle the maintenance phase?

In any software company, wherever you go, you find typical species of people who want to just break the software, do not want to bow down under business pressure to release low quality software and are often termed as fussy. This species is specifically termed as ‘Testers’.

Nowadays, there is a special requirement that is being given to this species. It is to automate as much as possible. This poor specie is under pressure to learn automation and implement it and behave like a developer. So what is happening? Is the automation that is being proposed or done under such pressures really worthwhile? Are the companies really getting benefits out of it?

I am seeing it a fact that reusing a framework has become a fashion nowadays. Everyone is talking about so called ‘Hybrid’ framework. Even if the application is complex and steps are repetitive, testers end up developing a keyword driven framework (which they call hybrid as well) for it. I have been confronting with these people about why they are doing so when that framework might not yield a good return in the longer run for that particular application. The answer that I get is.. I developed it in the past in one of my projects and hence it is a proven way to automate!

It seems to implement an already known framework has become a fashion in the industry. The reason is simple. No one wants to take risk and try something new or may be no one wants to understand the exact need of the application under test.

REQUEST -> Please do not treat test automation as an activity that can be based on a poor framework. The framework should be designed to fulfill the application needs and not your personal needs.

Using automation to overcome Agile testing challenges

Organizations globally are adopting the Agile development methodology for enhanced collaboration and faster delivery. Agile is a set of software development principles that lays emphasis on individuals over processes and tools, working software over documentation, collaboration over contracts and responding to change over following the plan. Through Agile, organizations can collaborate with their customers by delivering live and working software to them. Despite its benefits, embracing Agile in the Testing practice is not an easy task and fraught with challenges.

Challenges in adopting Agile in Testing

While selecting appropriate tools that are usable as well as flexible is an issue, encouraging the entire team to contribute towards the tests is another problem. Enabling open-source integration and promoting test-driven development are some of the other concern areas in Agile testing.

Agile also brings with itself a few technical problems like difficulties on account of distributed teams and obstacles faced by individual testers within the Agile team. In the case of Agile development methodology, it often becomes tough to keep track of the number and speed of changes in user stories, requirements or the code.

Another issue with Agile is frequently changing requirements. Due to this, the code is refactored quite often.  Agile testing can be further bogged down by the fact that the testing team has to continuously collaborate with other cross-functional and geographically scattered teams.

How Test Automation can help

Test Automation can help organizations resolve the challenges associated with Agile testing.  Test Automation ensures that the application is and continues to be in a good shape with each new sprint. It encourages the Agile development team to collaborate with the testing team, seeing it as a  partner, rather than as Quality Police. Running the tests over and over again gives the development team an assurance that the new code, which was added to the system, does not break or destabilize anything.  It also certifies that the system is working and the new code is doing what it is supposed to do. As Agile teams need to test continuously, Test Automation provides the required speed, and helps ascertain that the feature implemented during a given iteration or sprint is actually deployed.

Think, before starting

Overall, Test Automation is useful in addressing and fulfilling critical testing demands and essential for Agile projects due to their need for frequent regression testing. At the same time, while Test Automation may be needed, just deploying an automation tool is not the solution for an organization.  What companies also need is a proven automation testing strategy and a skilled test team. This involves designing an effective automation solution that supports quicker maintenance, faster ramp-up time and distributed ownership.

Do look at Jim’s comments to complete reading

Agile is being adopted by most of the organisations to achieve quicker deliveries. But, looking at the usage and implementation, they are still struggling to milk the actual benefits that they can reap while being Agile.

Testing is one such area that is making testing teams lose their sleep.

One of my friend and colleague, Garima Mishra, has prepared a 40 mins webinar that aims to showcase how testing teams can  get benefited by Automation and how it can help address the challenges that are usually encountered while testing time-boxed agile projects.

The webinar is scheduled on Nov 30, 2011 at 10 am PT / 1 pm ET

Register to learn more.

Ask questions, but keep the context right

Posted: September 26, 2011 by Vipul Gupta in Testing

Right communication is important among stakeholders. It is often that people do not follow it and get into meaningless communications during project meetings. One should keep the context in mind while asking questions. For a tester, this Dilbert really says a lot!

I am excited about my upcoming webinar scheduled for June 22, 2011, being hosted by Impetus Technologies. In this webinar I will be discussing about cloud computing capabilities and how a testing team can actually utilize the strengths and benefits that it offers.

If you want to learn and understand about cloud and its usefulness in testing, do register yourself at http://www.impetus.com/webinar?eventid=43

This session will be full of practical information that can be utilized by the testing teams while deciding to harness the capabilities of Cloud.

See you all at 10 AM PST / 1 PM EST / 10:30 PM IST tomorrow.

Agiltomation – Successful Automation in Agile

Posted: April 15, 2011 by Vipul Gupta in Testing

What is Agiltomation?

Whenever we think of Agile, we think about Automation. It has been seen that whenever a discussion on automation comes up in Agile teams, they often start discussing the starting point or the challenges that will be faced for achieving the automation.

I will be talking about “Agiltomation” during our 5th NCR testers monthly meet scheduled for tomorrow. In case you are not attending, I will be posting a blog post soon on the subject.

Stay tuned!

Bind teams for best product results

Posted: February 1, 2011 by Vipul Gupta in Testing
Tags: ,

In my previous post, I discussed about the 3 M’s—Miscommunication, Misrepresentation and Misconception—factors that can play havoc with what a product looks like at the end of its development cycle. I had also said that it is improper collaboration between the business stakeholders, and the development and testing teams that could derail the product, and impact its overall quality.

In this post, I would be focusing on the steps that companies can take to avoid the pitfalls of the 3 M’s, ensuring complete coordination and cooperation between all the teams, hitherto working in silos. In simple words the solution is as simple as binding these different teams together, so that they think as one and work as one. By eliminating the barriers between the teams, aligning their different and distinctive working styles and unifying them in a single environment, it is possible to beat the bottlenecks.

The three challenges, need three solutions, or should I say, three simple steps.

Step 1 - identify the Tools and Frameworks that are used by the project teams on a recurring basis. There is also need to figure out the various Frameworks that are being used either to develop or test the applications.

Step 2 - Identify the Practices that are followed by the team at each phase of the development and testing process and further segregate the Tools and Practices based on their areas of usage.

Step 3

Step 3 is to rightly blend the tools and practices that have been identified in step 1 and 2; and integrate the same, bring them together.

Step 3

The three steps make it possible to understand how the practices are linking up with each other using various Tools and Frameworks. By rightly blending the Tools and Practices that have been identified in Steps 1 and 2, and bringing them together, companies can reduce various ambiguities that remain in the teams while performing testing.

It is also possible to develop a platform that integrates the tools and activities performed during development and testing. This platform can help in synchronizing the tasks, finally leading to productive testing. Furthermore, this platform can be made generic so that the teams do not need to change or replace the tools to enjoy its benefits.

Do let me know what in your view the solution to the 3M’s conundrum is, and how you have managed to overcome these challenges on your own turf.

Problem on the table

Posted: January 26, 2011 by Vipul Gupta in Agile, Testing
Tags: ,

This idea came to my mind when I, alongwith Ajoy Singha and Vipul Kocher, were discussing on the agenda of first NCR Testers Monthly Meet (NCRTMM) that we started in December 2010.The main motivation behind developing this idea was to provide an informal space during NCRTMM where testers can discuss the problems that they face and get the resolution from other testers present in the room.

We have already implemented this in the two NCRTMM and attendees have found it beneficial. The testers  have utilized this space to resolve the problems that they face in their live projects.

This post of mine will provide the complete details about “Problem on the table”.

What is “Problem on the table”
“Problem on the table” defines a space that allows group of testers to interact in a simple and organized way to enable valuable dialogs that addresses the day to day issues that they get stuck with and want some expert help to get them resolved. This space encourages people to discuss and resolve the issues and be more productive within their organizations.

Fundamental Rules

  • No one will control your discussions
  • Whoever wants to provide help is the right person
  • Allow owner of the problem to steer his or her topic in the right direction
  • Always thank individuals whose suggestions have actually helped you

How “Problem on the table” works?

  • Come up with some interesting problem area that you would like to discuss during any NCR Testers meet to ITB NCR Chapter with as much detail as possible.
  • After receiving an email from your side, there will be a space allocated during the meet to discuss about your “Problem”.
  • Anyone attending the meet is free to walk to the designated area for your listed “problem” and provide their frank suggestions.
  • It is upto the owner how they would like to steer the discussion.
  • At the end of the session, the owner of the “problem” needs to present their “problem area” alongwith the best solution, that fits in their context using a defined template.

Benefits of owning “Problem on the table” session?

  • You manage and define your own agenda
  • As most of the test experts from the industry are joining the NCR Testers Meet, there is a high probability that you will be able to find the answer to trivial issues that remain unanswered elsewhere.