Tag Archives: agile

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.

Agile Retrospectives: The Preventative Medicine

3months

One of the features of using Agile methods is the opportunity for continuous improvement within a project. There are a number of improvement opportunities throughout a typical iteration or sprint─over the next few weeks I’m going to walk through a few, starting this week with the Retrospective. Retrospectives are one of the many tools in Scrum and other Agile methods that are absolute must-haves for continuous improvement.

Spotlight Interview with Mark Levison

Mark Levison has over twenty years experience in the IT industry, working as a developer, manager, technical lead, architect, and consultant. He  discovered Agile in 2001 and is now a Certified Scrum Trainer and Agile Coach with Agile Pain Relief Consulting.

Levison has introduced Scrum, Lean and other Agile methods to a number of organizations and coaches from executive level to the individual developer and tester. Levison is also an Agile editor at InfoQ and has written dozens of articles on Agile topics and publishes a blog – Notes from a Tool User. Mark’s training benefits from his study and writing on the neuroscience of learning: Learning Best Approaches for Your Brain. To contact Mark Levison, please email him at mark@agilepainrelief.com.

Book Excerpt: The Agile Samurai

Jonathan Rasmusson

Author Jonathan Rasmusson explains in his latest book how to successfully set-up, execute and deliver Agile projects. Download the excerpt below for “Chapter 7: Estimation The Fine Art of Guessing.” To read his interview in last month’s issue, please click on “Spotlight Interview: Jonathan Rasmusson” to read his views on the best practices for test automation in Agile projects.

Get High Performance Out of Your Testing Team

Michael Hackett

Testing is often looked upon by many as an unmanageable, unpredictable, unorganized practice with little structure. It is common to hear questions or complaints from development including:

  • What are test teams doing?
  • Testing takes too long
  • Testers have negative attitudes

Hans Buwalda: Agile Test Development

Agile_Test_Development.flv 

Agile Test Development

Hans Buwalda – CTO, LogiGear Corporation

VISTACON 2010


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.

Michael Hackett: Agile Automation

 

Agile Automation

Michael Hackett – Senior Vice President – LogiGear Corporation

Testing in Agile Part 5: TOOLS

Michael Hackett, Senior Vice President, LogiGear Corporation

To begin this article, it would be a good idea to, remember this key point:

Agile Manifesto Value #1
Individuals and interactions over processes and tools

Tools work at the service of people. People, particularly intelligent people, can never be slaves to tools. People talking to each other, working together and solving problems is much more important than following a process or conforming to a tool. This also means someone who tells you a tool will solve your Agile problems knows nothing about Agile. A disaster for software development over the past decade has been companies investing gobs of money into “project management tools” or “test management tools” to replace, in some cases, successful practices of software development, in favor of the process the tool or tool vendor told that company was “best practice”. That made certain tool vendors rich and many software development teams unhappy.

If your team wants to be Agile, and work in line with the value outlined above, I have a couple of rules to remember when it comes to tools and Agile.

Rule #1 – Tools need to fit teams. Teams should not fit into tools!
Rule #2 – Test teams need to grow in their technical responsibility.

These two ideas sum up how I feel about most tools that are part of an Agile development project. For example, when you add management tools, this will add overhead, reduce efficiency and limit the Agile idea of self-directing teams. However, communication tools can help in distributed development situations and scaling into large organizations. Some tools work to provide services to teams and others do not. This article is mainly about tools and how they relate to test teams. We are going to talk a lot about the different toolsets- that are most important to test teams. We won’t talk about unit test frameworks since test teams very rarely manage them, but we will discuss test case managers in the Agile world.
I’m also going to talk about the changes that the test teams need to undergo to successfully implement or use these new tools.

Often when beginning an Agile project, there is a need for some re-tooling in order to be successful. The same set of tools we used in traditional development may not be enough to support rapid communication, dynamic user story change and ranking, and increased code development.

The groups of tools of specific use to test teams we will focus on are:

• Application Lifecycle Management (ALM) – such as Rally, Atlassian’s JIRA Studio and IBM’s Rational Team Concept
• Test Case Management Tools – such as OTHER**, and HP’s Quality Center
• Continuous Integration Tools – such as CruiseControl, Bamboo, and Hudson ( Including Source control tools – such as PerForce, and Visual Source Safe (VSS) type tools)
• Automation Tools – we will not talk about specific tools in this section.

Application Lifecycle Management Tools (ALM)

Sometimes when we talk about tools, we discuss them in relation to the Application Lifecycle. Naturally then, the tool vendors refer to their large suites as Application Lifecycle Management Tools, or ALM. This is the major category of tooling and it is often an enormous undertaking to get these tools implemented. However, there are some minor category tools in the ALM spectrum that we can pull out that relate to testers.

Application Lifecycle Management (ALM) tools have been making a splash in the development world for a few years now. Approximately 15 years ago, Rational (before Rational/IBM) had an entire suite of tools we would now call ALM. From RequisitePro to Rose to ClearCase through ClearQuest, the idea was to have one set of integrated tools to manage software development projects from inception to deployment. Now, there are multitudes of tool sets in this space. The use of these tools has grown in the past couple of years as teams have became more distributed, faster and more dynamic while at the same time coming under increased pressure from executives to be more measurable and manageable. When Agile as a development framework grew explosively, the anti-tool development framework got inundated by tools.

ALM tool suites generally manage user stories/requirements, call center/support tickets, also help track planning poker, store test cases associated with user stories, bugs – there are many tools that do this – but the big leap forward with current ALM tools is them being linked to source control, unit testing frameworks, and GUI test automation tools. Lite ALM tools satisfy the need for speed required by the rapid nature of software development – it’s a communication tool.

There are great reasons for using ALM tools, just as there are great reasons not to use them! Let’s start with great reasons to use them:

  1. If you’re working on products with many interfaces to other teams and products, ALM tools can be very beneficial in communicating what your team is doing and where you are in the project.
  2. ALM tools are essential if you’re working with distributed teams.
  3. If you are working on projects with large product backlogs, or with dynamic backlogs often changing value, a management tool can be very helpful.
  4. ALM tools are useful if you have teams offshore or separated by big time zone differences
  5. You are scaling Agile – for highly integrated teams, enterprise communication tools may be essential.
  6. If, for whatever reason, the test team is still required to produce too many artifacts- mainly the high overhead artifacts like test cases and bug reports, build reports, automation result report, and status reports (ugh!) – most ALM tools will have all the information you need to report readily available.

There are many good reasons to use ALM tools. But the tool can’t control you or the use and benefit of going Agile will be lost.

Most Agile lecturers, including Ken Schwaber, will tell you using Agile in distributed teams will reduce the efficiency. This does not mean Agile cannot be successful with offshoring, but it means it is tougher and chances of ending up with smiles all around are lower. Nothing beats all being in the same place, communicating easily and openly every day and working on our software in my bullpen in the office. If you are in that situation – good for you! However, this is the subject of another magazine article we will bring you in the New Year.

Now the great reasons not to use ALM tools:

  1. It is very easy for some people to become tool-centric, as though the tool is the project driver rather than the Teams. That is completely waterfall, bad!
  2. Paper trails and the production of artifacts, “because we always did it this way,” are anti-Agile. Most times the artifacts become stale or useless having little relevance to what is actually built.
  3. Management overheard is anti-Agile. The only “project management” if I can even use that phrase, is a 15 minute daily scrum. Not a giant, administrative nightmare, high cost overhead, project management process! When the ALM tool becomes a burden and overhead slows down the team, you will need to find ways to have the tools support you rather than slow you down.

A quick word about measurement: the only artifact about measurement in line with by-the-book Agile is burndown charts. Extreme programming espouses velocity. If your team is measuring you by test case creation, test case execution rates, user story coverage there is nothing Agile about it. End of discussion.

If you want to investigate ALM tools further, I recommend you look at a few – check out enterprise social software maker, Atlassian, maker of the famous Jira, and Rally a great, widely used product with dozens of partners for easy integration. These two are at the opposite ends of the cost spectrum.

Test Case Management Tools

Most test organizations have migrated, over the past decade, to using an enterprise wide test case management tool (TCM) for tracking test cases, bugs/issues and support tickets in the same repository. Many test teams have strongly mixed feeling about these tools- sometimes feeling chained to them as they inhibit spontaneous thinking and technical creativity.

To begin talking about test case tools in Agile, there are two important reminders:

  1. Test cases are not a prescribed or common artifact in Scrum.
  2. Most companies that are more Agile these days are following some lean manufacturing practices – such as ceasing to write giant requirement docs and engineering specs, and getting really lean on project documentation. Test teams need to get lean also. They can start by cutting back or cutting out test plans and test cases. Do you need a tool to manage test cases in Agile? Strict process says no!

If you are not using a TCM yet and are moving to Agile, or are beginning to use a test case manager, now is not a good idea If you already use one – get leaner!
Still, most ALM tools have large functionality built around test case management that can become an overhead problem for teams focusing on fast, lean, streamlined productivity.

Continuous Integration

In rapid development, getting and validating a new build can kill progress. Yet there is no need for this! In the most sophisticated and successful implementations of Agile development, test teams have taken over source control and the build process. We have already talked about continuous integration in this series (See Agile For Testers Part 3 Automated Build and Build Validation Practice / Continuous Integration for more discussion on this), let’s focus on tools. Source control tools are straightforward. Many test teams regularly use the source controls systems.

There’s no reason why a test team can’t take over making a build. There is also no reason a test team does not have someone already technically skilled enough to manage continuous integration. With straightforward continuous integration tools such as Bamboo, CruiseControl and Build Forge, test teams can do it.

My advice is:

  • Learn how these tools work and what they can do
  • Build an automated smoke test for build verification
  • Schedule builds for when you want delivery

Test teams can use a continuous integration tool to make a big build validation process: scheduling new builds, automatic re-running of the unit tests, re-running automated user story acceptance tests and whatever automated smoke tests are built! Note, this does not mean write the unit tests – it means re-run, for example, the J-unit harness of tests. Test teams taking over the continuous integration process is, from my experience, what separates consistently successful teams from teams that enjoy only occasional success. Easy.

I suggest you visit Wikipedia on CI tools here: http://en.wikipedia.org/wiki/Continuous_integration) to see a very large list of continuous integration tools for various platforms.

Test Automation

I’m going to resist going into detail about automation here. Automation in Agile will have its own large magazine articles and white papers in 2011. Remember, when discussing automation in Agile with team members, scrum masters or anyone knowledgeable in Agile, the part of testing that a test team needs to automate is not the unit testing. That automation comes from developers. Test teams need to focus on:

  • Automated smoke/ build validation tests
  • Large automated regression suites
  • Automated user story validation tests (typically a test team handles this. But- there are very successful groups that have developers automate these tests at the unit, api or UI level)
  • New functionality testing can be difficult to automate during a sprint. You need a very dynamic and easy method for building test cases. This will be discussed a greater length in an future Agile automation methods paper.

In Agile development, the automation tool is not the issue or problem, it’s how you design, describe and define your tests that will make them Agile or not!

Here are the main points to get about test automation tools in Agile:

  • The need for massive automation is essential, clear and non-negotiable. How test teams can do that in such fast-paced development environments needs to be discussed fully in its own white paper.
  • That you need a more manageable and maintainable, extendible framework, like tools that easily support action-based testing is clear.
  • Developers need to be involved in test automation! Designing for testability and designing for test automation will solve automation problems.
  • Training is key to building a successful automation framework.
  • Tools never solve automation problems- free or otherwise! Better automation design solves automation problems.

Summary:
Tools in Agile need to be used to fit people, not the other way around.
Tools need to be easy to use (from your perspective- not the tool vendor’s perspective!) and low time and management overheads.
Employ lean manufacturing ideas wherever possible- specifically, cut artifacts and documentation that is not essential.

Article by Michael Hackett, Senior Vice President, LogiGear Corporation

Does Agile development need specialists

Agile is to software development what poetry is to literature.
It is 
very difficult to do well, very easy to do poorly,
and most people 
don’t understand
why a good poem is good and a bad poem isn’t…”
- from the web

Transition from a traditional development model to an agile methodology is often met with some degree of skepticism and doubts by testers. Books and programs on Agile development tend to emphasize the need for multi-skilled generalists who can take up different functional roles as needed. This tends to cause specialist testers to worry about losing their identity in an agile world. Is there a need for specialists in agile or is the agile world inhabited by generalists, the proverbial jack-of-all-trades ?

To answer this question, look no further than your favorite team sport. Agile software development is a team process involving members from the different functional groups coming together as part of one team to produce software. No longer are they members of distinct teams such as development, testing, technical writing, i18n, l10n, etc. Back to our earlier question on whether agile needs specialists or is the new world full of generalists ?

Like a team sporting activity, for a team to be successful it cannot be – 1) all members of one particular type or specialize in one activity e.g. development or testing alone 2) all members who are generalists and knowing part of all functions but not specialists of any function. How would you rate the chances of your favorite sports team if it were comprised of either types of members – a) all players who specialize in just one area e.g. of cricket which I follow: a team of just batsmen or just bowlers b) all generalists e.g. again of cricket: a team of just all-rounders – it might be better than the first choice with only players of one type but still not the best choice. An agile team takes a step towards success when it comprises specialists from the different functions coming together and working together collaboratively to produce software. Each member of the agile team brings to the table their unique set of skills that influence the software’s development and success of the project. However, an additional requirement for these specialists that are part of the agile team is to be able and willing to share in some of their non-core tasks. For example, a tester who can debug defects and make small fixes if need be, a developer who can also document their feature or do some testing, etc.

There is truth to the statement that agile needs generalists. However, it is better to have specialists who can go beyond their functional domains to help towards the release rather than specialists who just restrict their involvement to their functional area of specialization. Ultimately, agile development is a team effort and testers like others on the team must own the release from the beginning without merely trying to police it at the end.

***
From John Morrison’s Blog