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.

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 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.

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.