Theme Testing Mind Map

We’re a financial services company, and this theme was a rewrite of one of the oldest and most critical parts of our system: sweeping a tiny percentage of the assets in each participant’s account as pay for our services.

My fellow tester Lori Thayer (who came up with the idea to mind map test cases) and I wrote the initial mind map, then discussed it with the rest of the development team, the product owner, the controller and other stakeholders. Our central node is “Run”, because this is a batch process that needs a way to be kicked off, make sure prerequisites are in place, provide a way to monitor progress, and be restartable in case of problems. Not only is it important to test these parts of the system, but they’ll be invaluable to help us execute and monitor tests.

Without boring you with all the details of this them, you can see that the map includes some primary nodes such as “collection” for sweeping shares out of the account, “sale” for selling the shares once they’re in our company account (definitely in our best interest!), and “instructions”, each representing one participant’s account. We drew dotted lines between related nodes, such as “collection” and “sale”, “sale” and “fast401k account”. The map includes details such as the internal account number where the funds should end up. On the right side, we wrote questions that nobody was able to answer yet. These got answered as we learned more through talking to stakeholders and doing exploratory testing on a design spike.

We referred to this map many times over the next several iterations as we implemented this theme. We checked off the areas that were tested, added more questions and/or answers, even added more nodes as we thought of more areas to test. We didn’t get down into level of test case detail, but the map shows the relationships we needed to test, in addition to the individual components. (Unfortunately, I neglected to take an “after” photo).

We got into more details on the team wiki, using color-coding to show questions and answers. Our most senior programmer lives in India, and the wiki is a good way for him to participate in discussions like this.

Wiki Page Example

Here’s a snippet of some test scenarios we wrote. When we’re satisfied with a test, we put our initials next to it to indicate it’s done.

Example Test Scenarios

It took us five iterations (ten weeks total) to finish this theme. At the end, we felt confident that we’d thought of and discussed all angles of the process, its potential impacts on other parts of the system,  talked to all stakeholders about their individual needs and concerns, and done adequate testing not only at the functional level, but also performance and usability.

Our software manages all aspects of 401(k) retirement plans. A “plan sponsor” is the company or employer that establishes the 401(k) plan for their employees. We’re working on a theme to allow more than one person working at a company log in and do “plan sponsor” functions for their 401(k) plans, such as submitting payroll contributions or enrolling employees.

Up to now, since only one “plan sponsor” account existed per 401(k) plan, we called that user role “plan sponsor”. This term appears all over our website. Now, we are working on a theme to allow multiple accounts to do the “plan sponsor” functions. These users are not plan sponsors – the employer is. Earlier this week, we had a couple of different discussions on what to call these users and what terminology to use on the user interface. Every manager and developer had a different idea, we kept going round and round discussing it in twos and threes.

Yesterday, I scheduled a meeting with ALL the stakeholders to make a final decision on terminology. You might say, “It’s not the tester’s job to call a meeting like that! Shouldn’t the ScrumMaster or Product Owner do that?” Well, they could, but our ScrumMaster was out sick, and our PO is always swamped. We needed to stop wasting time changing verbiage over and over. In 15 minutes, the various business managers agreed on the term “plan administrator” and on some other related terminology.

Changing terminology - from a mockup

Since the PO was too busy to do it, I mocked up all the changes for all the various pages, posted them on the wiki for our remote developer to see along with narrative requirements and test cases for the changes, and stuck them to our task board along with a task card. Our remote developer, who lives many time zones ahead of us, made most of the changes before we got to work the next morning, and another developer made the rest. I verified the changes, showed the PO, and updated an automated regression test.

We had an issue, though. The modules and classes in our code still used the “plan sponsor” term. We have a “plan_sponsor” table in the database and a column called “sponsor_id”. Eventually it would become very confusing that our UI says “plan administrator” all over the place, and the code has “plan sponsor”. One of our developers decided to copy the “plan_sponsor_mgmt” module to a new module called “plan_admin_mgmt”, and renamed anything in the new module with “plan sponsor” references to be “plan admin” references. This required renaming classes, config files, variables and more. He deleted the code from the old module and will delete the old module itself when the dust settles. (He found out later he could have done the renaming in the old module, but as he says, live and learn).

Later, we will change URLs, velocity variables and spring field declarations, but as that will change HTML Ids and names and cause automated GUI regression scripts to fail, we are coordinating that. And, we still need to change the database table and column names.

It’s a lot of trouble, but it would have been more trouble later, when someone wants to change the “plan administrator” functionality, and can only find “plan sponsor” in the code. We all think we’ll remember everything forever, but we have a big code base considering our team size, and what if we hire a new developer?

So what’s my point? As a team, we did what needed to be done to maintain a high standard of quality, and avoid technical debt. No manager told us to do that. Our Product Owner did not “prioritize” refactoring the code to have the new terminology, because that isn’t a business decision – we control our internal code quality. Though everyone on our team cares about quality, I made my own particular contribution by getting everyone to agree on terminology and verbiage, writing a task card and posting the mockups. It’s been a fun couple of days!

I got the “dolly” idea from Maykel Suarez. He and my other teammates set one up for me when I was a remote member of his team. They got the virtual presence idea from Hanselman, but added the dolly idea to make it easily mobile. My “Donkey Dolly” was on a wireless network and could be wheeled even from building to building – it was way fun to wave at people as I wheeled by them, and enjoy the grass and trees outside!

Our “Virtual Nanda” or virtual telepresence device consists of a rolling laptop cart, a good laptop with plenty of memory and speed, a good webcam that can be panned around the room, a good microphone and good speakers. (We definitely need a catchier name for it; since Nanda lives in India, we were thinking along the lines of the Bollywood Dolly). Any team member working remotely who wants to use it can VNC to it, log in, make a video call to it on Skype, and control the audio and video. The mic is good enough that conversations around the room are audible. The speakers are good enough that the remote person can be heard around the room. Here’s a picture.

Virtual Nanda

Here’s another picture showing more of the cart. Instructions for how to use it are taped to the front.

Another View

If more than one person is working remotely and wants to use the Virtual Nanda, we can’t use Skype for video. We still use it for audio, and use Yahoo IM for the video. All the components are securely fastened to the cart so nothing will fall off when it’s rolled around to wherever it’s needed. Unfortunately using a wireless connection isn’t a viable option, because our only wireless requires being on the VPN and that’s too slow. So we have a long network cable. The cart has a power strip attached to it that in turn has a very long power cord plugged into it. The network cable and power cord are long enough to wheel anywhere in the team room, and we just unplug when we have to roll it to another room.

Nanda uses the telepresence every day for the standup meeting, and for all other meetings. If he needs to talk to anyone in the office or vice versa, they just walk over to our area and talk to him just as if he were in the room. Anyone working from home is also free to use it. When I work from home, I stay on the virtual dolly all day, my teammates position it so I can see several of them when I move the camera around, and I just holler if I need anything. I wear a good USB headset to screen out background noise on my end and hear them better.

Look for a longer article about this and other aspects of making teams with remote team members work smoothly and successfully!