Tag Archives: ABT

Agile Test Development with Action Based Testing – by Hans Buwalda

Agile methods are becoming more and more popular and successful for developing IT systems. Typical properties of an agile method, like Extreme Programming, are continuous user involvement and an emphasis on the testing role (‘Users’ may be the actual users of the system you are creating, customers, or business analysts who provide the requirements on behalf of the end-users). Testing is positioned in agile system development as a driver for system development, with tests often created before the functionality they are verifying.

In LogiGear we promote and support Action Based Testing (ABT), a very successful method for creating maintainable automated tests. In ABT the focus is on development of products called “test modules”, an activity that can be independent from system development. It has no specific preference on when in the life cycle those test modules are developed. That makes it easy to integrate the methodology into an agile life cycle. In this article I want to give some perspective on how this can best be achieved.

In my view there are the following ways to enter ABT into an agile project:

  1. Closely couple test development to system development
  2. Keep test development as a separate life cycle and use an agile approach to build the tests
  3. Hybrid approach: business-level tests are developed early; detailed, typically UI-specific tests are created in parallel with the development life cycle

Allow me to expand on each of these approaches:

  1. Closely coupling test development to system development would mean sticking to what most agile life cycles prescribe. The tests, in the ABT test modules, are created together with users, whenever the life cycle needs it. The advantage is that this is highly recognizable as an agile approach, and it allows for better interaction between users and developers, with tests serving as a means of communication.
  2. The alternative is to have a separate life cycle for developing the test modules. In my experience, this is the most common approach. This might be a good choice if there are experienced testers available who can work with the users to develop good and representative tests. Those tests are then input for the developers, who can still interact with the users, but have a finished product to work with: the test modules. This alternative is probably the more manageable one, since test development can have its own life cycle, and can be dealt with in an early stage when the users have room in their schedule. Another advantage here is that even if your software development cycle is following a traditional ‘waterfall’ approach, your test and automation development can still be ‘agile’.
  3. The hybrid approach is in my view the most attractive proposition. In the test development life cycle for business level tests, the users and test developers can concentrate on the business process and business specific issues, like how to calculate a monthly premium for a mortgage. Then when the developers are ready to define the user interaction with the system the users can create tests like “if I click on a customer, I see a list of his/her account balances”.

No matter which alternative is used, I would make the following recommendations:

  • Plan well, and make every effort to create good efficient tests, with a high level of re-use and automation
  • Make sure participants know what is expected of them, and have the experience and knowledge to deliver their part

Agile methods are a relatively new phenomenon in the software world, with great promise and many early success stories. Carefully fitting testing into the agile life cycle will improve both system development and test development, and lead to successful test automation.

Action Based Testing: The Solution for Agile Test Automation

Hans Buwalda, CTO, LogiGear

To address the challenges and fears of implementing automation in agile projects,  LogiGear CTO Hans Buwalda presents Action Based Testing as the answer.

Test design focused on expediting functional test automation

David W. Johnson

Test organizations continue to undergo rapid transformation as demands grow for testing efficiencies. Functional test automation is often seen as a way to increase the overall efficiency of functional and system tests. How can a test organization stage itself for functional test automation before an investment in test automation has even been made? Further, how can you continue to harvest the returns from your test design paradigm once the test automation investment has been made? In this article we will discuss the factors in selecting a test design paradigm that expedites functional test automation. We will recommend a test design paradigm and illustrate how this could be applied to both commercial and open-source automation solutions. Finally, we will discuss how to leverage the appropriate test design paradigm once automation has been implemented in both an agile (adaptive) and waterfall (predictive) system development lifecycle (SDLC).

Giving an Atomic Bomb to a Caveman…

rman2739l - retouchThe challenges with any automation effort is to know your capability. I’ve seen too many automation efforts begin and end with a tool decision. Generally these tools are very complex pieces of software that do many more things then we would ever use in our normal everyday testing. It even adds more misery to the situation when we give this new tool to people who are entirely incapable of using and scaling the “newly” selected savior to our automation effort.

When I teach, I call this moment .. “it’s like giving and atomic bomb to a caveman”

Why do I call it this? well, because if I gave an atomic bomb to a caveman and then said to the caveman, “hey, I just gave you the most powerful weapon ever designed by man, and go use it against your enemies”… he would look at me and say, “thanks, but how do I use it.. “.. and I say.. “you’ll figure it out, just don’t be near it when it goes off..”

The caveman takes his spear and axe and hits the bomb, shakes it, kicks it around, and finally say to his clan mates.. “see…this thing doesn’t work.. I have no idea what that guy was talking about when he said it was the most powerful weapon, he’s full of it..”

That’s what happens to most automation tools that are not properly setup for your teams.

If you give a complex Integrated Development Environment (IDE) to tester who doesn’t or hasn’t programmed in years, you are just asking for trouble. However, this practice continues to this day, and what I’ve found it happens far more often then I think most companies would care to admit.

So how do you fix this problem?

Test Design…

Our solution to this problem was to develop Action Based Testing.

“Action Based Testing” is an attempt to give testers/biz analysts who don’t program a test design model that easily supports automation. When we talk about automation, we aren’t talking thousands of tests.. we are talking millions of tests. That’s the level you want to get to, since automation affords us the ability to geometrically scale our testing coverage. But you can only do this, if you have a test design framework that supports the scale and supports your testers. AND!! – if you have a tool that has adoption characteristics that support all members of the team, otherwise, you’re back to giving nukes out.

There are tools out there, cucumber, which is a context aware automation tool that is designed around the subject matter experts, that is the blackbox testers or business analysts. I’ve used this framework in addition to the framework (ABT) I helped develop at LogiGear.

The point of this post is to get you away from thinking tools are panacea’s and get down to thinking about test design and how the tools fit into this framework. I tend to use a lot of tools in my automation strategy, since I’m not one that believes in one size fits all.

Go out and choose a good automation friendly test design framework, learn it, get others involved with it and see how they interact with the new framework, and see if they are capable of applying the test design parameters you’ve setup for them inside the tool.

Good luck.. and don’t press the red button.