Thank you.

Your uploaded files are waiting for moderation.

CLOSE

Blog

Get Automated Testing “done” in Agile Development

Go Back
  • Posted by
  • 12/10/2015

One of the benefits of the agile project approaches is their friendliness towards testing. The testing activities, and the testers with it, are integrated into the teams, and testing and quality are redefined as team responsibilities. Automation nowadays is a must-have that needs to be addressed. Automation happens on multiple levels in a system, starting with unit tests. In this blog we’ll focus on functional tests at the UI level.

For functional tests timely automation can be hard due to UI dependency. A team might be “done” with work items in a sprint, but the development and automation of functional tests might not have been finished yet. Having to do such automation later is unattractive; it places the testing and automation out of sync with the other activities in the team, making it harder to cooperate.

Getting automated testing done requires a few steps. A first step is to make testing manageable in short sprints is to use a domain language approach. This can help the whole team express and communicate tests quickly. We use keyword based “actions” that are easy to manage, use and implement, and is supported well with our product TestArchitect™. We also have a tool to translate actions to and from BDD scenarios, another domain language approach.

Actions become the basis of the modular test design method called Action Based Testing (ABT), which organizes the tests in “test modules”. A main distinction is made in ABT between modules for “business tests” and for “interaction tests”. In a business test one would use business level actions like “rent car” or “check balance”, while in an interaction test the actions would be at a lower level, like “select menu item” or “check window exists”.

Fitting Testing in Sprints

 

To get to automated testing “done” in agile sprints we ended up with a process that is shown in the picture. When the sprint starts the testers will create the higher business level tests. These tests stay at the same level as the user stories and acceptance criteria. Further into the sprint interaction tests will be developed when the user interfaces have become stable enough to make it worthwhile.

Also very early in the sprint interface mappings are made. We recommend that those are created without the use of an interface viewer or other spy tool. This encourages the team to define easy to maintain identifying properties for upcoming UI elements, like the “name” property in Java. This also encourages better collaboration between QA and Dev teams

When the UI becomes available the team is ready with the following:

  • Test Modules
    • Business Level Tests
    • Interaction Tests
  • Interface mappings
  • Actions – At this point actions are well thought out and finalized but not yet automated

The automation focuses on the actions and only happens when UI’s become fairly final (if you follow the approach last-minute changes will be accommodated easily).

An additional way to relieve teams and keep automated testing in sync with development is something we like to call “Outsourcing 2.0”, which is part of our services offering as a company. In this model excess workload for test development and automation is handed over to a service group that can grow and shrink over time, and can service multiple agile teams. This way the attention of all team members can be focused on new functionalities.

About the authors

Hans Buwalda is CTO at LogiGear Corporation in California. Subu Baskaran is Product Marketing Manager, also at LogiGear.

See Also

Go Back

Blog Post Added By

Profile photo of Hans

Join the discussion!

Share your thoughts on this article by commenting below.

One comment to Get Automated Testing “done” in Agile Development

  1. Matt Griscom says:

    This is a nice application of what I’d call state-of-the-art technology in automated verifications, but I’m pushing the limit with MetaAutomation, which offers hierarchical and self-documenting check steps so that the “business tests” and “action tests” are actually the same thing and there’s no need to write both.

    With MetaAutomation, the artifacts of check runs are pure-data XML (with XSD schema) so very efficient to persist over the whole SDLC, very efficient and robust to query, and completely flexible in presentation to anyone on the team who cares about quality. The checks are very fast, so they can be run to gate check-ins, which ensures that quality issues don’t impact the other developers *and* that quality is always moving forward, never backward.

    Best of all, for outsourcing, because what the product does through a check and the results are always transparent by design (unlike keyword-driven automation, which is not, and I know this because I’ve been there in the trenches fiddling with them out of necessity) communication about product quality is efficient, detailed, accurate and precise. The check steps are hierarchically arranged (based on the XML) and any team member potentially has the option to drill down to see what the product did and what the parameter values were. Outsourcing works better because the QA team/role never needs to interpret; it’s all there in the data that the checks generate.

Leave a Reply

Your email address will not be published. Required fields are marked *

Skip to toolbar