• Rails Basics
• REST
• Plugins/Gems (will_paginate)
• Deploying with Heroku
• Authentication
• Testing
• Localization/Globalization
• Mobile
• Print

I think the course will be based on my demo app, daibatsu.heroku.com – over the course of 4 days we’ll build out the app with all the features mentioned above.

What am I missing?

Over the past two years, I’ve had a number of ideas for other ways to use TroopTrack. For instance…
- Civil Air Patrol Units
- Old man clubs (elks, rotary, etc)
- Karate schools (dojomama.com is available)
- Church youth groups
- Home schooling organizations

There are probably lots more.

I’m looking for a partner who will explore these opportunities, get good at configuring TroopTrack, set a few of them up, work with me to make the public TroopTrack pages support multiple products more effectively, and then figure out how to sell the accounts.

For each of these, you’ll get to set your own price and take a large chunk of the revenue from your particular unit type. A civil air patrol captain I met said he thought $2500 per unit was a pretty good price. A karate school might be willing to pay $200, I don’t know…

We can also sell a stand-alone license to organizations like church youth groups. In those cases, they would have a dedicated TroopTrack instance that supports only their organization. Then, we can also provide a business intelligence tool (like Pentaho) for creating any kind of report they want on their units. The price would vary depending on the size of the organization, but you would get to set it, as long as I can still make a profit after the cost of hosting.

Your responsibilities would be level one support for all your customers. In other words, you would look at all the support tickets and emails from your customers and take care of any non-coding issues, such as:

• Adding new achievements
• Resetting passwords (soon to be automated)
• Questions about how to do something
• Etc

Remember, this is software as a service, so once you sell a customer you keep getting revenue for as long as we keep them happy.

There you go. Let me know what you think. If you want to try this, send me an email: dave@trooptrack.com.

Peace out.

• Making controllers restful
• Making the user interface easy to use and consistent
• Fixing bugs
• Removing or simplifying needless complexity
• Replacing home grown bits with plugins/gems as appropriate

My prioritization process has gone something like this:

1. What parts of the app make me want to punch my monitor?
2. What do I have a good plan for fixing?
3. What will matter to my customers?

A year ago the list of answers to #1 was really pretty long. Today, it’s down to just two bits – TroopTrack’s homegrown authentication system and the user_profile controller and views. This is not to say that TroopTrack is now perfect, but the remaining problems do not reach my punch-the-monitor threshold required to be on the list of things I hate.

Is This a Quality Metric?
I think it is. It might be a good idea to keep a list of all the things people (including you) really, really hate about your product. Consider opening this list to developers, product owners, testers, and yes, customers. Set some threshold for what you mean by “hate”. It needs to be stuff that is more than just irritating. It needs to inspire rants, push people to take walks to calm down, tempt ex-smokers to reach for a pack, etc.

Getting Past Hate
I think I will have 0 punch-the-monitor features left by mid-September at the latest. Then what?

Will I take a break and just tweak the app for a bit? Will I launch into new development for features I haven’t thought of yet? Will I focus on marketing and business development, something I’ve completely ignored for the past year?

Maybe.

One thing I’ve been thinking about lately is the applicability of TroopTrack to other things. Even though it is currently focused on Boy Scouts, it has the capability to support any organization that has similar needs to a Boy Scout troop. Some examples I’ve thought of include:

• Paramilitary organizations like the Civil Air Patrol
• Church youth groups
• Home school education providers
• Girl Scouts
• Scouting program outside the U.S.

TroopTrack has finally reached the point where adding support for these organizations is simply a matter of configuration, not coding. Perhaps it’s time to start adding support for them as well.

Another thing I’d like to do is really flesh out the capabilities of my web page editor. I want to create a catalog of hooks back into the application so they can make data-driven web pages using their troop data. I also want to give them some more flexibility in the design and layout of their pages. I don’t really know how to do this yet, so it’s a good opportunity for some learning. Perhaps I will finally conquer the dreaded javascript.

A tester’s job is to make the product better
I admit this is a simplistic claim, so I think I’d better explain what I mean.

Being a tester is much more than just finding problems. I’ve seen testers who are extremely good at finding bugs but fail to turn those bugs into substantial improvements for the product they test. Why is that?

Sometimes it’s because the tester is not a good bug advocate. They aren’t able to convince developer’s, managers, and stakeholders that a bug needs to be fixed. They try, are ignored, and then become irritating jerks when the bug is exposed in a production environment and begin taunting everyone else.

Sometimes it’s the result of crying wolf. A tester thinks every single bug they find, even the obscure boundary bug that only happens when you paste 10 million characters in a text field, is critical and must be fixed now. They escalate on everyone who tells them to chill out until everyone is sick of them and their bug reports are all ignored.

Sometimes it’s because the tester is out of sync with the development team. Maybe they are testing so far behind the dev team that they’ve lost interest in the area the tester is focused on. Or perhaps they have gotten ahead of the dev team and are testing stuff that doesn’t make sense contextually.

These are skill issues that can be taught, coached, and improved. More concerning to me is the third reason this happens.

Sometimes it’s because a tester doesn’t believe it’s part of their job.

“I just find the bugs. What you do with them is none of my business.”

I don’t care for this detached approach to testing software. You can’t coach a tester into caring about the product they test – first you have to remove their head from the dark body cavity in which it is embedded.

But… but… you argue. If they find the same bugs as a tester who cares what difference does it make?

Well, that’s not likely. They won’t find the same bugs. Their testing will be cursory and focused more on creating the impression that adequate coverage has been achieved than finding the bugs that matter the most in the context of the product development effort.

It’s sad to see a tester with otherwise good skills who is so ambivalent to the outcome of their work that they don’t even try to see it in the larger context of effectiveness as an individual CONTRIBUTOR.

A tester cannot succeed independently while the team fails

A tester who doesn’t make the product better is failing. It might not be entirely their fault – maybe the organization has unhealthy incentives to ignore them. Maybe the developers are sensitive jerks who can’t take criticism. Maybe the managers don’t know a critical bug from a mis-spelled word in a EULA. Whatever. It doesn’t matter. If all that stuff conspires to make you fail as a tester…

You still failed. You did not accomplish your job.

Sorry. It’s a cold cruel world kids.

Nobeoka was the first Japanese city I called home. I lived there for six months and it served as my indoctrination into a world that was both completely alien and totally fascinating. I loved the food, the language, the land, and the people. Every morning, as I rode my bike through town, I marveled at the ingenious ways in which the Japanese had merged their world with the natural (and sometimes harsh) beauty that surrounded them. Green was everywhere – it surrounded the town in every direction but the east, blanketing the mountains that pinned Nobeoka against the sea.

One thing that took a bit of getting used to was the toilets. Although I understand that Western toilets are very common in Japan now, in 1992 rural Japan they were neither unusual nor were they commonplace. At any given public restroom, you had a 50/50 chance at best that you were going to push a stall door open and find yourself face to face with a squatter.

Many gaijins are bothered by squatters. It can take a bit of getting used to if you haven’t grown up squatting in the brush on campouts to relieve yourself. Some gaijins had mental lists of which department stores and restaurants had western toilets and which did not, but that wasn’t me. I didn’t care. Once I had figured out the basic mechanics of the thing I was pretty comfortable with it.

Except for one time. One day, I rode my bike about 20 miles out of town to call on a family that lived fairly deep in the forested mountains around the town. The ride was spectacular and exhausting, winding up mountainous roads with steep drop-offs on one side and walls of rock and exploding greenness on the other. At last we arrived at the house we were looking for, a beautiful home in an idyllic forest glade. The house was old, at least a hundred years, probably much more.

We enjoyed a fairly luxurious amount of food in this setting, sitting on cushions around a low table, chatting with the family and eating an endless stream of Japanese favorites as the day wore away and the evening sky fell. Just as my stomach was starting to become uncomfortably full, our host presented us with a plate of about ten disks of round cuts of meat, each about the size and thickness of a large coin. The meat was almost thawed – soft and red around the outside, still a bit frozen in the middle. A small amount of blood pooled around the edges of the meat, thin and watery. Shika sushi, the host informed us. Deer meat. Raw deer meat. “I shot it myself,” he added.

I’d never had shika sushi before, and I haven’t since, but I wish I could. It was delicious. The other gaijin who was there with me wasn’t so keen on the stuff, so I was able to eat more than my fair share. I won’t lie. I loved it. It was like nothing I had ever tasted before. My brain told me it was gross, unsafe, and unhealthy, but my tastebuds told me a different story. My intestines, on the other hand, told me that it was the last straw. It was time for me to go to the bathroom.

I’ve always been prone to overeating, even when I was young. I still am, and it shows. That night was no exception, and out of some perverse sense of politeness I waited until my need was urgent to inquire about the location of the toilet. In a house this old, I could hardly expect a western toilet, but what I found instead terrified me. It wasn’t that it was a squatter. I was fine with that. The problem was the tiny closet the squatter was in. It wasn’t build for 6’1″ Americans. It was built for somewhat shorter Japanese people. The ceiling was practically on top of me, and the room was just barely wider than I was, and not much deeper.

I stepped into the room, pulled the door to, and proceeded to squat. I stopped half-way down when my knees banged against the door and my butt hit the plumbing behind the toilet. I pulled up and looked at the squatter in disbelief – the room wasn’t deep enough, or I was too tall. I couldn’t squat OVER the toilet. My knees would bump up against the bathroom door, pushing my butt out of range of the squatter’s gaping hole no matter what I did.

My intestines let out a rumble. They were unhappy with me. I had taunted them with relief and then denied them. They weren’t having any of it, but what was I supposed to do? I couldn’t use that bathroom, not without missing the toilet or … Was there another option? I knew there was, but I didn’t like it. The bathroom was too close to the room in which people were still enjoying each other’s company. The bathroom door might even have been visible from there. Still… what choice did I have?

In the end, I did the only thing I could do, as quickly as I could manage it. I opened the door, letting it swing as wide as it needed to, then squatted over the ceramic hole in the floor and took care of business. It was loud, it was humiliating, and soon it was over.

When I was finished, I collected my wits and prepared to face my friends. I decided that our hosts were probably embarrassed that their bathroom was so small and unlikely to comment. Only the American I had come with would be interested in humiliating me, and maybe he hadn’t noticed. There was a chance no one else was going to say anything about what had just happened, so why should I? I put on the most dignified face I could manage and stepped back into the main room as if nothing had happened.

No one said a word about the incident. Not then, not ever. Apparently my gastrointestinal exuberance had gone unnoticed by our host and by the other guest. Thank goodness. I knelt back down on the cushion, took a sip of my water, and helped myself to a dumpling. It was a great evening.

The Moral of the Story
What does this story have to do with software? How does it apply to Software as a service, testing, agile, or anything else I usually write about on this blog?

Not much. But I think it relates to yesterday’s post about how crappy some of my TroopTrack code is. Things don’t always work out the way they ought to. Sometimes you have to part with convention and do things a different way, just to make things work. Sometimes, you just have to do what needs to be done and not worry about what that means.

Sometimes, the best that you can hope for is to simply avoid the worst case scenario.

In my case, I had to settle for being happy that I didn’t wind up with a brick in my shorts and a 20 mile bike ride home.

I was thinking about these requests and feeling a little embarrassed by the notion of nearly complete strangers poking around in my code. Some of the code really, really sucks. That’s a bit humiliating to me. Also, there are hardly any tests, which is a complete embarrassment given I’m a freaking tester.

The fact that there aren’t many tests is also a total hassle, as it means a lot of regression testing for me whenever I change something. It also means an unfortunate number of regression bugs as well, which drives my users insane.

When I think about other Rails devs poking around in the code, all sorts of insecurities kick in, but mostly it boils down to two things:

1) What if they decide I’m a crappy coder?
2) What if they decide I’m a weak loser when I blame some of the bad code on other people?

Ah, well, it’s nice to have insecurities sometimes to remind you that you’ve still got plenty of room to grow.

So, specifically, here’s my TroopTrack dirty laundry. This is the stuff that I find emabarrassing:
1) Some of the controllers are still not RESTful. I’ve converted most of them, but a couple are still crazy.
2) The home grown authentication really sucks. It needs to be ripped out and replaced with AuthLogic.
3) The before filters for limiting access based on roles are inconsistent and out of control.
4) The UI metaphor is inconsistent.
5) There are a few places where cascading deletes were implemented in the database
6) Just plain crappy code and missing tests, as I already mentioned.

There are other problems that I don’t really find quite so embarrassing – features that aren’t totally mature, etc – that I consider a normal part of software development.

So, what to do about this? I thought about it and decided to put all my dirty laundry right on the README. That way, if someone decides to contribute, digs into the code, and gets all mad about it, I can honestly say that I tried to warn them.

Software is hard. Sheesh.

Step 1: Take a tour of the feature
A tour is an exploratory testing exercise that helps you create a mental model you can use for planning your testing where you simply clicky around the feature and get a sense of what it does. A typical tour is aimed at answering questions like the following:

• What does the feature do?
• How does the feature vary by user?
• What other features are related to this feature or impact the way it operates?
• What capabilities are included in this feature?
• What setup activities are required to make the feature operational or to customize it?

It’s important to take notes during your tour as you find the answers to these questions. These notes will provide the information you need for the next step: writing session charters.

Step 2: Write some session charters
Writing session charters is easy – all you really have to do is capture the mission of the charter. A mission is what you are trying to accomplish in a 30-90 minute testing session. Examples of missions include:

• Try to find bugs in the happy path of adding a new person
• Look for XSS bugs in the event data entry views
• Look for bugs creating forms using IE7

Use your notes from step 1 to create these charters. You can record them in a spreadsheet, a wiki page, a notebook, whatever. Just leave some room for notes.

Step 3: Test away
Doit! Grab a charter and start testing. As you test, try to think of different variations of what you are doing that might matter and try those too. If you think of something else that should be tested that isn’t captured in the charters you’ve already written, pause for a minute and write a new mission down. Make notes of any bugs you’ve found, but don’t go submit a bug report yet.

If you encounter something related to the mission you’re on that looks strange or interests you for whatever reason, focus on it for a while until something else distracts you (that is consistent with your mission of course). Following your instincts in this way helps keep you mentally engaged and avoid “brain-dead testing.”

Step 4: Isolate and document bugs
After you’ve done a charter or two, go back over your notes and highlight any bugs you’ve found. Take each one and try to isolate them. An isolated bug is one for which the simplest path to repeating it reliably has been identified. Once you get there, then document it in whatever way your team reports bugs.

There are good bug reports and there are bad bug reports. Good bug reports:

• Include information for reproducing the bug
• Clearly identify the part of the system in which they occur
• Clearly identify the outcome of the bad behavior (system crash, user confusion, etc)
• Include the reason you think it is a bug (see oracles below)
• Include supporting information such as screenshots and stack traces

Step 5: Take a nap

Testing this way requires energy. Most testers can only manage 3-4 charters per day before their brains start to melt and their productivity dips. It’s important to take breaks between charters and mix in meetings (the few we have) as well as other work. For instance, if you are planning on doing 3 charters, an expense report, a call with your boss, lunch, and some development, don’t plan on doing all 3 charters in a row after lunch. Instead, mix them in throughout the day to give your brain some time to recover.

Tips

Stay out of ruts

Use your domain knowledge
In TriSano, this means knowing things like

• which diseases occur most frequently
• which forms are longest
• what reports are used for
• how tech-savvy the users are

This could be different for your app, but what matters is that you have some sensible understanding of the problem your solving and how the solution is used in the real world. When you test, take this knowledge into account and put it to use by modeling real scenarios in your testing.

Pretend to be someone else
Here are some people you can pretend to be:

• A slow reader
• An angry user
• A malicious user
• A new user
• A distracted or bored user
• A user with a disability

Use oracles to find bugs

An oracle is a theory of error that tells you something is wrong. Here are the oracles I use most frequently, captured by the mnemonic “HICCUPPS”.

A bug could anything that is inconsistent with one of the following:

• History of the product
• Image of the product
• Claims made about the product
• Comparable products
• User expectations
• Purpose of the product
• Product itself (i.e. similar things work differently elsewhere)
• Statues or internal standards

For more information on HICCUPS, check this out: http://www.testingreflections.com/node/view/2635

I’m wiser. I’m older. I’ve got much better programming skills than I had two years ago. I’ve got a sustainable vision for the product and I’ve got a helpful, hopeful user base. I think I’ve come full circle.

I might be ready to bring on some help again.

The Ideal Contributor Agreement
In my older, wiser world here’s what I want to get out of a contributor agreement:

• Incentives that encourage long-term sustainable contribution
• Incentives that discourage get rich quick expectations or decision-making
• Clear system for ending the agreement fairly if needed

The General Idea
Mike Kelly gave me some good ideas about how I might structure such an agreement. There would be four components of the agreement:

• An Ownership Target
• A Contribution Target
• A Vesting Plan
• A Reverse Vesting Plan

The Ownership Target
This is the percent of TroopTrack the contributor would own after meeting the contribution target for three years.

The Contribution Target
The number of hours the contributor will spend working on TroopTrack each year to maintain their contributor status.

The Vesting Plan
For every quarter the contributor meets their contribution target they will acquire 1/12 of their ownership target.

The Reverse Vesting Plan
When a contributor decides to leave or I decide they need to leave, then the reverse vesting plan kicks in. This plan converts their ownership into cash over five years by giving them a gradually declining percentage of revenue based on their ownership level. Each quarter, they receive a payment proportionate to their percent ownership, and each quarter they own 1/20 less of TroopTrack. After five years, they get nothing cuz they own nothing.

What’s Wrong with this Picture?
Umm. I’ve got nothing to say here actually. I’m looking for your opinions.

Thanks!

This is crazy – how can slow growth be good?

I don’t blame you
When I started TroopTrack I thought I’d have $100k in revenue within a year, easy. We were gonna build web-based copy of TroopMaster, launch it, and watch the scouting market, starving for a solution that didn’t suck, flock to us.

That didn’t happen. Twenty-three months later over 300 troops have tried TroopTrack and only about 40 of them have purchased it. That’s about $1300 in revenue. The guys who started TroopTrack with me, disappointed by our slow takeoff, have quit and gone back to their normal lives. But I keep plugging along, perhaps delusional, refining the application for the 40 troops that care and the 3 new troops that click the buy button every month.

At this rate I’ll have $100k in revenue in 78 years or so. So how can this be a good thing?

In the early stages LEARNING is more valuable than a lot of users

When you start a business, you don’t KNOW jack about what will be successful. You have hopes, plans, strategies, concepts, ideas, but little knowledge. Replacing theories with KNOWLEDGE is a big freakin’ deal. You’ve gotta do it.

The thing is, you don’t need 100,000 users to turn your theories into knowledge. You may not even need a thousand. Heck, if your product is something you and your colleagues will use for yourselves you may only need 10. What you really need is an engaged user base that will tell you when you really screw up, will generate good ideas, and will be tolerant of the mistakes you make along the way.

Learn what users want

You start a company because you think you know what some group of people want, even if they don’t know they want it. The first year of TroopTrack taught me that I didn’t have a clue what users want, and the systems we had in place didn’t help me learn the truth. I didn’t have much more than a horrible conversion rate to tell me that my product sucked. I needed more information.

Things started to turn around when I added a real help desk, not the POS we rolled our selves that was nothing more than an issues table. I signed up for ZenDesk ($9/month), integrated it with TroopTrack in about 15 minutes, and voila, I had a first class help desk and a pretty decent user forum solution.

Once I had a good solution for keeping track of all the things users had asked for I started to learn things. I started to see TroopTrack from the users point of view and it stung a little.

TroopTrack sucked. It was little more than a really buggy web-based version of the POS desktop software that most troops already use. The interface was clunky and difficult to use. Many of the features didn’t work or were incomplete. The first-time user experience was totally lame and unconvincing.

It was pathetic and disheartening, but I just kept going, attacking each support request as they came in. Every now and then, users would go out of their way to encourage me. One even called me to tell me how awesome the application was becoming. Feedback became gold to me – what the users want was the thing I really needed to learn.

Incremental improvements add up over time
TroopTrack still has a long way to go. I try to do something good for TroopTrack every day, even if it’s just a small change or answering a user question. Most days I spend about two hours working on some part of the app, more on weekends if I can get away with it.

For a long time I was focused on adding new features like troop wikis, document libraries, etc. But things have changed lately. I’ve been focused on making the interface better, a little bit at a time. I’m slowly moving away from the traditional slow web page approach (fill out a form, save it, reload the page) to something more Web 2.0-ish.

I started with a simple, but frustrating, part of the application that had traditional index, show, new, and edit pages and converted it over to an AJAX driven interface that only had an index page that never did a fill reload. It’s fast, intuitive, and my users really seem to like it. They asked me to make the whole app work that way, a good sign that I had found at least a part of the path to awesome.

Since then I’ve converted more parts of the app, typically bits on the fringe that I can work on without tackling the huge core bits. I wanted to learn how to do it right before I attacked the core functionality and it’s been very educational (just an aside, if you know how to do AJAX right with rails it’s really pretty easy).

Yesterday I started on one of the core features – user profiles. I’m stoked and unafraid, because I’ve learned a lot and am prepared.

Learn how to make a buck
Entrepreneurs are searching for a business model that will make them successful. My business model boils down to two simple metrics:
- Percentage of troops who try TroopTrack and decide to buy it (conversion rate)
- Percentage of troops who buy TroopTrack and decide to renew their annual subscription (renewal rate)

These two things tell me how awesome my product is or isn’t and whether my efforts are paying off. In the last year, my conversion rate has gone from less than 1% to just over 10%. That’s pretty good, but it’s not good enough. I don’t want to go through 10 potential customers to get 1. I could live with 4, and until I get there I don’t see any point in aggressively marketing TroopTrack.

I’ve learned something interesting about the 9 customers who don’t buy. They usually only log in once. Their first experience somehow doesn’t create a compelling experience. This is something I’ve gotta fix. Hopefully it will drive the conversion rate up. If it does, I’ll be happy. If it doesn’t, then I’ll keep experimenting until I crack that nut.

I don’t know what my renewal rate is. My first paying customer’s subscription expires in the next month. Cross yer fingers.

That’s my simple plan for figuring out how to make a buck: two simple metrics and experiments to make them better.

One experiment my users have suggested is to raise the price. A few of them have told me I’m too cheap. That’s feedback I didn’t expect.

You must have AMAZING product support
My user base is pretty tolerant of mistakes I make. Sometimes I introduce bugs into the application, breaking things that used to work, but they put up with it. Why? Because we have a sense of knowing each other.

I can tell you the names of my ten most active troop leaders off the top of my head. I have interacted with them by email, IM, phone, and mail. Our interactions aren’t formal or unfriendly – they are casual and pleasant. They have become vested proponents of TroopTrack and what used to be just my goal – to create a troop management solution for the 21st century – has become our goal.

ZenDesk has a lot to do with this. It makes it easier to manage my support requests and keep my users informed. It’s also priced appropriately for my little enterprise, but still supported really brilliantly.

Attitude is also important here. The support I provide has changed dramatically since I began to really appreciate its value.

You can’t do all this with a huge user base
So, this is a pretty long windup to the pitch, but here it is:

I couldn’t do all this stuff if I had 100,000 users. That many users would bury me.

Someday I’d like to have that many users. But not yet, not when I don’t know that my product is awesome. Not when I have to churn through 10 customers to get 1. Not when I look at parts of my interface and want to punch the screen. No way.

Persistent Patience
That’s my theme. Persist. Patiently. Do something good every day. Keep at it, knocking the rough edges off as I find them, looking at my product through the eyes of users until it shines.

Do it. Do it. Do it.

• History of the product
• Image of the product
• Comparable products
• Claims about the product
• User expectations
• other features within the Product
• Purpose of the product
• Statutes that apply to the product

*Not my invention. Google it.

Not Every Problem is a Bug
I have a tendency to enter any problem I find as a bug. There are lots of reasons for this, including:

• Users tend to think everything they don’t like is a bug, which translates into pressure for me
• Bugs seem less likely to be ignored than feature requests (stories) from a tester
• I don’t have to think about it if I just call it a bug
• I often can’t remember what stories have already been implemented and I’m too indifferent too do research to figure out if something was defined in a story or not before I call it a bug
• Part of me just doesn’t care. “It needs to be fixed whether you see it as a bug or a story”

This creates a tension between me and the devs because they look at a bug like “such and such list should be sortable on column headers” and they rightly call it new development. For lots of testers, this could become a regular argument. Lately, I’ve just been saying something like this:

You’re right. Change it to a story.

Be Wrong

I’m motivated here by a couple of things. First of all, I try to cultivate a belief in myself and others that being wrong is no big deal. One of the ways you do that is by practicing being wrong. In a situation where there is no compelling evidence that I am right other than I just want to be, I try to assume I am wrong when my peers disagree. The ability to acknowledge possible faultiness in your own smartiness is a key factor in having healthy relationships.

Testing Adds Value
Another reason I have become more liberal about logging problems as stories is to demonstrate the value that testing brings to the application. You see, the way we estimate development, the estimates are an expression both of cost and value. So, if I, through testing, create 20 points worth of new development in a given iteration, I have made it possible to add 20 points of value to the product. That’s kind of cool to be able to articulate the value created by testing in metrics beyond bugs found and bugs fixed.

Quality Has a Cost
Bugs aren’t pointed in our approach. This is because if it really is a bug, we already got credit for it when we shipped the feature I found it in. In other words, we probably should have found it when we built it, so getting points for fixing it is double dipping.

Stories, when they really are stories and not bugs, do get points. They have a cost. Pointing stories found through testing makes it easier to prioritize them. An eight point story that addresses a purely cosmetic issue is probably going to be prioritized lower than a 2 point story that addresses a functional one.

Knowing the cost of a story helps me avoid getting wrapped around the axle with some issue I think is mission critical but really doesn’t matter much in the grand scheme of things. It helps me put it in the context of the entire development flow and see it relative to all the other things we need to do.

Be a Liberal Story Writer
Don’t get bent about some problem you found being a bug or a story. If you suspect it might be a story, or your colleagues feel it’s new development, log it as a story. Don’t sweat it much. I’ve seen testers get absolutely irate about this, and developers too. Ironically, I’ve seen irate testers also say what I said above : “It needs to be fixed whether you see it as a bug or a story”, all the while making the case for its buggishness. Don’t do that. Err on the side of points if there is a chance you are wrong and trust in your team’s ability to refine the accuracy and criteria of such judgments over time.

Have a nice day.

Dave