Agile Testing with Lisa Crispin

When we have a new theme coming up, we usually start a few weeks or months in advance by having one or more brainstorming meetings with our Product Owner and possibly other stakeholders. The PO often draws examples on the whiteboard as we discuss: algorithms for calculations, or diagrams for workflow. We ask questions to understand the purpose of the theme, the business problems it will solve, who will use it and how. We talk through various technical implementation designs. These meetings are usually timeboxed to one hour. Having a few days between meetings gives us time to think about what we’ve learned so far and possibly do research.

Once we understand the theme, we work with the PO to break it up into user stories, prioritizing them according to dependencies and risk, and estimating them. Sometimes we just estimate the theme so the business can think more about whether they want to prioritize it. When we actually start work on the theme, we usually feel pretty well-prepared. Still, when we get into actual development, we sometimes find we missed some important aspect of the feature. Sometimes after the theme has been released to production we realized there was a ripple effect we hadn’t thought of.

Since participating in a workshop where Jeff Patton introduced his story mapping technique, I’ve been lobbying to try story mapping when we start work on a new theme. Our product owner, Steve, got his wires crossed and mixed up “story mapping” and “mind mapping”, and decided to mind map a new theme on our big rolling whiteboard. We’d had a couple of brainstorming meetings on this theme, and had written and estimated stories for it. He thought it would be a good idea to mind map everything we could think of about this theme, and take a fresh look at it.

Theme Mind Map

This mind map worked really well to help us review the theme. Steve’s color coding was helpful. Our current system has a one-to-one relationship between a “plan sponsor” and a 401(k) plan. In truth there could be multiple sponsors for each plan, so we have to break that one-to-one relationship, which is the green branch of the mind map. Those are the first stories we’ll do. Then we need to provide a way for one plan sponsor to have an ‘administrator’ role and be able to create accounts for other sponsors in the same plan. The management UI for this is the orange-colored branch. One sponsor will be the “Authorized Representative” (“AR”) and that is the name that will go on official documents. That’s reflected in the purple branch, along with reports, queries and email communication. The brown-colored branch is future functionality, which we want to keep in mind as we deliver the initial stories. In drawing the mind map together, we thought of areas we hadn’t considered in previous meetings, such as recording which users make which changes, and how this relates to other user types in the system such as TPAs (Third Party Administrators, who often do the sponsor’s work for them).

Right after the meeting, one of the programmers, Mike, had a flash of insight. We didn’t need to “break” the existing one-to-one plan – sponsor relationship. Instead, that one-to-one relationship would define the Authorized Representative, so we could leave the existing code and database tables as-is. To add the ability to have multiple sponsors, we can add a new table with the plan-sponsor relationship that will also have a flag to denote which sponsors are also “administrators” and can manage other sponsors’ accounts. You can see the database design in the top right of the whiteboard. This idea slashed a 13-point user story to three points – quite a savings! Would Mike have thought of this without the mind map? Who knows? Everyone agreed this was a helpful way to think of all aspects of the new functionality and come up with a good way to implement it.

Another plus of the mind map was that our remote team member could see it from his telepresence device’s webcam, which you can see at left in the following photo.

Remote Team Member on Telepresence Device at Left

Though I still hope we’ll try story mapping in the future, mind mapping turned out to be a productive technique!

I work for a mid-sized software company with around 27 development teams, mostly Scrum but also a few doing Lean and Kanban. We have a large and diverse product of HR-related software, I think there are around 6 million LOC, on three different platforms, including an ASP product and a .NET product. I’m fairly new, I started at the beginning of June, so I’m still learning about how everything gets done. We release four times a year and the software has won many prestigious awards. I’ve been impressed with this large-scale implementation of agile development. Just the speed of the daily Scrum of Scrums is amazing.

Many of the teams do a great job of automating their tests, and a few teams have their own continuous integration (CI) that runs multiple times a day. Other teams have automated tests, but must wait for the company-wide build to run, which is usually only once per day and sometimes not that often. They don’t get feedback fast enough, and that slows them down – a lot.

I’ve been asking why some teams struggle to automate tests, and why some teams don’t have their own CI. I’ve also asked my own team why most of our functional tests are automated through the GUI, rather than behind the GUI. We use FitNesse, but mainly to drive GUI tests with SWAT.

The answer I get a lot is “It’s the framework”. We have three architecture teams, and there is a framework (maybe there is more than one, I don’t fully understand it yet) that apparently makes it hard to test at the page or object layer. In addition, some teams’ code has tentacles into legacy code written in Delphi whose tests are written in WinRunner. Also, the current framework appears to not be fully supported with automated unit tests, it was developed a few years back. Programmers new to the framework seem to have a hard time understanding how to work with it. The framework clearly causes a lot of frustration. A new framework is under development, but it won’t be available for some time.

In order to understand the existing framework and find out whether the new one will facilitate testing behind the GUI, I was fortunate to get to meet with the leader of the architecture side of the development group. He gave me an overview of the new framework’s current design (which may change), aimed at making our product easily configurable by customers, using web services. It looks like this design allows testing under the GUI level.

Additionally, I learned that it is possible to test under the GUI in the current framework, and I met someone on another team who has automated many FitNesse tests at the object level. I plan to get her to show me how these tests work, and see if what she did would work for our code.

I haven’t worked at a company this large since the early 90s, and I’ve never worked in a company, agile or otherwise, that had “architecture teams” and “frameworks”. I get it that our product needs to look and work consistently across the board, so it does make some sense to centralize the design of the UI and perhaps other parts of the system. However, if the architecture is done by one team, what does that mean for programmers on other teams? Is the fun part of their job taken away? Do they get a chance to think for themselves and improve the product?

It also seems to me that there needs to be a lot of communication amongst the entire development community of our company, that all programmers should have some input to the architecture process. I’ve found that communication between teams in general is a bit lacking. Each team is so focused on delivering its part of the product, they don’t always feel they have time to go talk to other teams. So, for example, perhaps nobody on my team has talked to the person who did a lot of FitNesse functional tests.

Does your company have an architecture team, and/or a framework that everyone works with? Please comment and share your experiences. As a tester, I’d like to know what I can do to help my team deliver the highest possible quality when we have to work with a framework designed by someone else.