Agile Testing with Lisa Crispin

Agile is pretty mainstream now, but some folks still aren’t sure what testers do. In addition, the “Whole Team” approach to quality and the idea that testing and coding aren’t separate phases still mystifies some people. I think my team’s activities the past two days are a good illustration of how agile teams work together to produce high quality software, yet we testers still make valued contributions.

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!

InfoQ just published an article I wrote to try to inspire more testers to grow their skills. It begins:

The software industry is changing fast. More and more teams put testing up front and center; they use tests to drive development. New and improved automated test frameworks and drivers burst onto the scene every month. Teams with more automated regression suites need testers with sharp exploratory testing skills. But most people do not learn the needed skills in university: where will these testers come from? Read more…

I just reviewed a book proposal that raised my ire. The skills and techniques that would be taught in the book were fine. The emphasis on context-driven testing was great. But the book appeared to be framed in a setting where testing is all about dealing with crises, trying to figure what testing you can squeeze in to a very short timeframe, making the testers somehow in charge of quality.

Testing skills are important, of course, and we testers add value with our special experience and viewpoint. But we can’t have much impact on quality by ourselves.

On the plus side, I’m seeing more and more teams around the world figure out that the best way to deliver a high-quality product is to move testing to the front, make testing and coding part of one process, have the whole development team take responsibility for quality, and work incrementally, iteratively and at a sustainable pace.

On the minus side, I see things like this book proposal that ignore the evidence of how this new whole-team approach is working, and that keep pushing a way of working that is 20+ years old and hasn’t resulted in consistent, high-quality software.

I don’t care if you’re using a traditional waterfall process, or agile, or something else. There is a pragmatic, practical approach to software development and testing that works. It’s more than specific testing skills and tricks. Discipline, communication and collaboration are the key skills and characteristics we need. Continuous integration and automated build processes that run good regression tests are as just as essential as automated source code control.

Testers do need to learn new skills and techniques. More importantly, they need to get up from their workstations and (physically or virtually) go talk to other development and customer team members. We need to find out how we can all help each other do our best work and delight our customers.

What do you think is the most important thing testers need to do or know? What book is missing that would send newbie testers in the right direction?

Sometimes I’m the most helpful when I just sit there and mainly keep quiet – assuming I’ve gotten the right people together to talk.

Today was a good example. One of our stories this sprint is an algorithm to calculate internal rate of return on a 401(k) account. This is pretty complex (especially for me, given that my math education topped out at algebra). The product owner has done a lot of research and experimentation to come up with the formula. He documented the formula on the wiki, and created a spreadsheet with numerous real examples from production data. The developers have done their own research as well. They wrote code to do the figuring and a couple of FitNesse tests based on the spreadsheet examples to check the results, and their answers didn’t match the PO’s answers.

The developer came over and started asking me questions about the PO’s formula. I thought we ought to be discussing it with the PO, who fortunately showed up right at that time. We had the “Power of Three” going. I didn’t participate much, other than to ask an occasional question. I don’t grasp the details of the formula well enough to make suggestions. My main contribution was to have made sure the three of us got together and talked.

We worked through some examples, and the PO decided the dev’s ideas were good and agreed to change the formula, but brought up a suggestion from another dev that would make the formula more ‘elegant’. They talked about this for a few minutes, obviously neither totally understood this other idea, so I went and got that developer. After more discussion, the decision was to proceed with the current formula, see how it works, then later on, see if the more elegant solution is appropriate. I’m not even the main tester on this story, so I made sure that the person who is got filled in on what happened.

I didn’t contribute hardly anything to this discussion, other than to make sure the right people talked, that they reached a consensus, and that appropriate action was taken to document the new formula on our wiki. But let’s say we were a team without testers. Maybe the developer would have gone directly to the PO, but would they have gone and gotten the other developer? Would the decision have been made and documented? It’s possible, but the number of times that I’ve been the instigator in getting the right people together to discuss and decide is pretty high. I’m also often the first person to say “Let’s work through a real example”. And back when we first started Scrum, and direct communication between customers and developers was new, these kinds of impromptu discussions sure didn’t happen naturally.

I recently joined the KanbanDev mailing list, and there’s been a discussion there about whether testers should be involved with the dev team and how they would add value. As simple as it sounds, getting people together to talk has always been one of my major contributions. The Power of Three, as Janet Gregory calls it, is truly powerful.