Sample Defect Tracking Link Widget for FitNese

WikiWidgets in FitNesse are a great way to extend the functionality of your FitNesse pages. Essentially they let you rewrite the content of you page in creative ways. My first forays into the creation of my own wiki widgets was to add some specially styled text to make things stand out on the page. This has been replaced by the new !style_class widget added by Uncle Bob a few releases back.

That doesn't mean there isn't a need for a widget now and then. I wanted to come up with a way to connect my wiki pages to our JIRA defect tracking and workflow system at work. I wanted it to be easy for me and my team to be able to do this with the smallest amount of wiki text. So I created a Widget for it !JIRA{TEAM-11111} which gets transformed into a proper link to the JIRA system.

I'm putting this out here for anyone who wants to reuse it. To make it work in your environment, you will need update the URL to match your environment. It can be further modified to work with any defect tracking system that supports URL as a way to access the system. And if you aren't using JIRA, and many of you probably are not, you can just rename the Widget as well.

    package common.wikitext.widgets;

   import java.util.regex.Matcher;
   import java.util.regex.Pattern;
   import fitnesse.wikitext.WikiWidget;
   import fitnesse.wikitext.widgets.ParentWidget;

   public class JiraWikiWidget extends WikiWidget {
       public static final String REGEXP = "!JIRA(\\{\\w+.*?\\})?";

       public static final Pattern pattern = Pattern.compile(REGEXP);

       private String originalText = "";

       private String token = null;

       public RpJiraWikiWidget(ParentWidget parent, String text) {
           super(parent);
           originalText = text;
           Matcher match = pattern.matcher(text);
           if (match.find()) {
               token = match.group(1);
           }
       }

       private String formatTestIdentifier(String text) {
           String tempText = removeBraces(text);
           return "<a class=\"dts\" "
                   + "href=\"http://jiraserver/jira/browse/"
                   + tempText + "\">" + tempText + "</a>";
       }

       private String removeBraces(String format) {
           return format.replaceAll("\\{", "").replaceAll("\\}", "");
       }

       public String render() throws Exception {
           return (token != null) ? formatTestIdentifier(token) : originalText;
       }
   }

It's not the trickiest code in the world. But it's yours to take and to use.

So far this is a small contribution to the community. At some point in the not too distant future I'll share my vim syntax coloring for FitNesse wiki pages. I still am looking to make a couple of improvements before that goes out.

Comments and questions are welcome.

Phone? MP3 Player? Software Testing Tool?

So often the focus on tools in software testing is on automation of GUIs, web testing, or even unit testing. Sometimes you hear about a little tool that has a special purpose that is very focused, such as AllPairs or PerlClip (via Satisfice).

How about a tool that you carry in your pocket? The iPhone and iPod Touch have revolutionized the smart phone industry. And, while the app store isn't about to do the same to software testing, it is pretty interesting how a tester can occasionally benefit from having a multi-purpose tool like an iPhone or iPod Touch at hand.

So you ask, how can you use one to test? Let's explore a couple of common tools I like to have in my pocket for testing:

Safari
A web browser is always a handy tool. Assuming you can get on the network at the office with a Touch, or have an iPhone You can:

• Look stuff up on Google.com
  
• Try out your non-iPhone web application for usability on an iPhone
• Kick off a FitNesse test (probably need wi-fi access for this one).

BigStopWatch (free)
I don't know about you, but I've often kept a stop-watch at hand to keep track of how long it takes for the software to do something. Having a reliable time piece to check loading time or responses can give you ammunition in a discussion later. Sometimes I haven't had that stop watch with me when I wanted it. Now I always have one with me. Technically I have one in my regular phone, but it is very clumsy.

Evernote (free)
Ubiquitous capture. That's what Evernote is good for. I use the Evernote client on my iPod Touch, my Windows computer and my Mac at home. If I had an iPhone, I could get pictures of the software behaving badly on someone else's computer. With my Touch, I can take notes in a meeting, at a co worker's desk or when I'm at lunch and have those notes for use later. You never know when inspiration will strike.

PCalc Lite Calculator (free)
A calculator is always a useful tool. Checking math is a common occurrence in testing. Sure, you could use the one in windows. But that thing is ancient. And it doesn't support RPN. OK, so i don't use the RPN option. I tried, but it didn't work. I'll try again later.

Read It Later (free)
Take your favorite Testing and Software Engineering thinkers with you. Don't be stuck with nothing to read when waiting in line for lunch. Catch up on Exploratory Testing, Agile Acceptance Testing, Scrum, or even what something neat from arstechnica. Either install the extension to Firefox or use a bookmarklet to select what you want to read later, and next time you sync up it will be waiting for you. There is a pay version that add some nice features. Instapaper is a nice alternative.

9-Toolbox (free)
Nothing like a handy tool that does the job of nine. Date calculator. Count-down clock (to release deadline or vacation?). Currency converter. And Unit conversion. All are nice to haves, though probably not infinitely useful.

Summary
So that's a list of some interesting options. By no means an exhaustive list. There are great ToDo apps, vim reference, html references, accessing safaribooksonline.com via the web, and it's even nice to use to listen to music while you work.

I love my iPod Touch. It is amazingly useful. Does everyone need one? No. Can't I do all of this with another tool, or even with paper? Yes. Is it the next place the tool vendors will go? I doubt it. Anyways, Apple won't allow capture-replay on the iPhone.

Now if no one beats me to it, I have an idea for an app.

Feeling more Slim than Fit

It's been forever again since I last posted. My last post was on FitNesse and my thoughts on the licensing scheme it uses. Well, Uncle Bob was already thinking about this and is hard at work making it possible to release under a more permissive license.

Part of how he is doing that is a move to a new table runner (interpreter) called Slim. I have to say, that for me and my work, Slim is the new Fit. My first forays into writing fixtures for FitNesse were less than perfect. Due to my weak Java skills and the pressures to get a solution in place, I came up with a solution that relied on inheritance and code generation. Neither of which are that bad a thing, but combined with a number of other factors, have proven to be less than my ideal.

Slim has already started to change that. Slim is much easier to write fixtures for. Slim eliminates inheritance on a very tricky parse tree concept and replaces it with lists of lists of strings. This has it's limitations (its a little stricter about data and it involves building the lists to return to the FitNesse server and the Slim table), but those limitations are worth it. One could argue that they aren't actually limitations, but good practices or more consistent approaches.

I was able to create a list fixture for listing sql select statements in about 125 lines of code and replace hundreds of code-generated classes in my old system, because it was so much easier to build a list of lists to return than to bend RowFixture to my will. I was able to replace hundreds of code generated RowEntry fixtures with a single class that is used in scenario tables and scripts. Eventually, I will be able to convert the 200+ tests I have to use the new table styles and shrink to a handful of actual classes that I, or someone on my team, had to write.

As for the classes that we will need beyond the one driver and the one list fixture, they will only be necessary for special cases where we need to condense table-like data into XML and where it would be a lot less elegant to build it using the scenario tables.

It's late and I'm getting tired, but I will be posting more about FitNesse. I doubt I can out-do the wonderful tutorial available here: http://schuchert.wikispaces.com/FitNesse.Tutorials. Brett is doing some great stuff there. I will try to contribute what I can to the community. So it might be some thoughts and pointers. Eventually it will be the vim syntax coloring file that I've been working on.

Before I go, I want to re-iterate my gratitude to Uncle Bob and all of the other great people who are contributing to the current Renaissance in the FitNesse community. There is great stuff afoot here and I'm glad to be in a situation where I can experience it and contribute in my own little ways.

FitNesse Licensing and Future Test OSS Tools

FitNesse and dbFit are both released under the GPL version 2. I have to say I find this choice of license frustrating. Don't get me wrong, I love the fact that this has been put out there to grow in the community. I've had it with the commercial tools.

The reason I am frustrated is the implications of the GPL on doing more with your tests. I've worked at or spoken with a number of companies that are looking at the possibility of delivering tests with their software so that the customer can run those tests on their installation. This is fine with FitNesse and other frameworks provided that the application is a web app or something that is loosely coupled and none of your fixtures reveal anything about proprietary nature of your product.

My concern is that with FitNesse being released under the GPL, which I am not an expert on, the fixture code often connects directly with the code under test. This is fine if you don't sell or distribute the tests along with the product to the customer. The GPL indicates that all uses within a company can stay within that company. However once you share it with one customer, you're on the hook to give all GPL affected code to the world.

Now I know that we're far beyond changing this, but it just seems to me that the testing community needs to think about this issue in the future. It seems to me that there is a real future in providing tests and testing tools to customers along with delivered software. It really goes a long ways to help the customer understand the product they are receiving. I'm not sure what license open source testing projects should use in the future, but I think it needs to be one that considers both the needs of a software vendor and the needs of the software community.

I am embracing FitNesse now and will continue to do so. It will mean that my company has to keep our tests to ourselves. These tests will still do a lot of good. But unfortunately this good will stop just before delivery.

Update 12/8:
Uncle Bob just posted on the FitNesse Yahoo group that his efforts with SLIM are intended to eliminate the GPL requirement from FitNesse by removing FIT. Additionally Gojiko, the author of DBFit is trying to do the same thing, as is John Roth of PyFit. This is good for everyone who wants to work with their customers and to deliver value to those customers in the form of tests and test tools for the systems.

It's been a long time since I've posted. As it goes with a lot of folks who think they want to blog, the commitment is hard to put ahead of family and paying work. So, that said, I'm going to attempt a revival of my efforts here.

In the time since i last posted, a number of things have changed. The biggest and most significant from a testing perspective is that I have gone back to my previous employer. I had a great time as a consultant, but a number of things have changed where I was and there is a whole new attitude on testing. It isn't a perfect change, but it is an improvement.

So I'm back. I'm digging into stuff I never thought I would use and developing skills that haven't been the focus for me in the past. It's exciting stuff and while I can't go into certain details. I will be posting my thoughts on software testing and the tools I'm exploring. More posts will be coming soon.

Tester, Know thy Role

Recently I attended a great presentation at my local SPIN meeting (Milwaukee SPIN Group). The presentation, "Separation of Duties: Why projects deserve a Project Manager and a Business Analyst", was on the BA and PM roles and why both are necessary and complementary roles. In the presentation the speakers discussed their experiences. Some discussion went to how people sometimes try to fill both roles at the same time and how they might not be as effective at both. They also discussed how a PM isn't necessarily as good at the details as a BA and how a BA isn't necessarily as good at keeping the whole project moving as the PM.

This made me think about Testers and their role in the project. In the presentation, it was stressed that the PM's role is to keep track of the project and remove barriers to completion. And it was explained that the BA's role is to understand the customer's needs and communicate those needs in the form of requirements. The Tester's role on the project is to test the product, identify issues with the software and communicate the coverage of their testing to the team. Each of those statements is a simplification, but a valid simplification.

I find that a significant number of testers really want to be helpful. Sometimes too helpful. Testers often have a diverse set of skills and like to show off how helpful they can be, and so they may find themselves volunteering to do most anything; including things that have nothing to do with testing. Is being helpful a bad thing? Not necessarily. The problem lies not within the desire to be helpful, nor in the act of being helpful. It lies in understanding the role expected of me on my project and letting the desire to be helpful take me out of my role and introducing riskh.

I was recently reminded of the fact a tester needs to be careful about being too helpful and keep in mind their accepted role on the project. It was in a context where there is a client implementation and Test Leads exist on both the client side and on the vendor side. The Test Lead at the client (Clint), who is doing their best to look after the risks in their project was asking about functionality that the vendor Test Lead (Vendi) thought might be possible, but wasn't sure. Vendi was also not sure if the functionality had been promised to the client and what might be the impact to attempting the functionality. As such, Vendi wanted to be helpful and could have offered some suggestions, but these suggestions might never have been possible. Promising this to the client could have been a problem, so Clint explained that he would pass on the question to the Lead BA (Barbara). After all, Barbara is the person who should be nailing down the requirements and would understand if the functionality request was a scope change.

Saying "Tester, Know thy Place" is a bit extreme. In general, most of the time I've heard this said it was out of ignorance of what testers can do and can contribute to a project. At the same time, testers do need to know and understand their role on the project. It's perfectly fine to be helpful; being helpful can often buy a lot of valuable goodwill that can get you time or resources you need when testing. I just always try to remember that sometimes I can help best by doing the testing and letting the BA, the PM and the other team members perform their roles.

Who Tested this?

Truly this is one of the most frustrating and chilling phrases in software testing. Who hasn't heard it at some point? Eventually it happens to all testers. The person asking the question believes that testing should have caught the problem. Unless they were the Tester and are saying "Who Tested This?" in a self-deprecating manner, they are quite possibly looking for someone to blame.

The Tester is pretty much always the last person to touch the software. The expectation that because you had it last, you are responsible for it is generally an unfair one. There are so many factors going into why the software quality was good or bad when it got to the Tester that it is unreasonable to put all the focus on testing.

Let's explore the other questions that could be asked:

• Who sold the product? (and did they validate their promises with the people who could deliver? )
• Who wrote the requirements? (for that matter, were there any requirements you could refer to?)
  
• Who did the unit testing?
  
• Who set the schedule? (did it allow for enough testing?)
• Who provided feedback on the test plan?
• Who decided what to fix and what to leave in the software?
  

Now don't get the the idea that I'm saying all the other disciplines have responsibility and the Tester doesn't. The Tester is responsible for analyzing the product and identifying tests that will establish that the software is doing what it is supposed to do and handles unexpected input or user behavior in a reasonable manner. The Tester is responsible for doing this in a manner consistent with the software they are working on and the environment they are working in. The Tester is also responsible to apply what they know about software risks and testing techniques/approaches that will help identify issues that make a difference on the project.

Ultimately, it all comes down to responsibility and probably someone avoiding responsibility for a problematic release. The reason I say that it ultimately comes down to responsibility is this: Everyone is responsible for the quality of the software. So who ever is asking that question, whether it is the Project Manager, Account Manager, Technical Support team member, Marketing person, Developer, Executive or Tester; each person had a role in creating the quality that was delivered to the customer. The decisions they make contributed to the final product.

Again, this doesn't mean that the Tester shouldn't be held responsible for their part in a release. Just that it should be recognized that it is unlikely that they did it alone.

Finally, testing should be a matter of personal pride as well as responsibility. At the end of it all, I want to be able to say "I did," and if I did a good job, to be recognized for it. If I missed something important; I will accept my role in that as well and hopefully learn from it.