If you're planning on attending, it will be great to see you.

I get this question frequently: "How do we document when we are exploratory testing?" This piece describes some of the things I do on testing projects.

There is an emerging alternative to old school craftsmanship called 3D printing. The Economist has an interesting article here. When I read about these kinds of things, it makes me feel excited to be working in high tech.

Here is an example of pushing information from your web browser to your mobile device: Push map information from Chrome browser to Android phone. It can be a pain to navigate and type on a smartphone, particularly when you are traveling and stressed out about where to find your destination. A colleague showed me how he used this for a recent trip - he plotted out his paths with Google maps prior to leaving his home, so his directions were pre-loaded on his device when he got off the plane. The hard part was done on his laptop, where navigation and typing are easier, and his phone had everything he needed for his trip.

This is just one example. As mobile devices integrate more seamlessly with our environments, they become easier to use and more valuable. Instead of clunky syncing, lots of typing and gesturing, the phones can just operate almost like they are self-aware. This is a space to watch.

1. Pre-production
2. Finding your groove
3. Keeping the band together

I have experience playing in bands and recording in studios, so those concepts grabbed me immediately. Preproduction: If you don't figure out where you want to go prior to getting started, you can burn up your studio time and not have a good finished project. Finding your groove: it takes time and practice to get your work to be at its best. Keeping the band together: recording and writing music is stressful, and there are a lot of things that can cause friction, dooming your project. Furthermore, if you play together for a while, you can get bored, or in a creative rut, so you need to do things to keep things fresh and interesting. (For more on music production, check out Bobby Oswinski's work and think of how his descriptions and advice might relate to software projects.)

This led me to think about software projects, and I re-framed those concepts like this:

1. planning and getting started
2. getting productive
3. staying productive

As an industry, we've done a lot of work on #1 Planning and getting started, so much so that we often ended up over-planning, and working on too much speculative, up-front design and didn't leave much time for the actual product creation. When I started out, I could find books on software development topics that were filled with planning ideas. Often, actual implementation ideas were a bit light.

The backlash against too much up-front planning came in the form of processes like Rapid Application Development, the Spiral model, Evo, and eventually the Agile methods. These have helped us address #2, Getting Productive: we have a lot of processes and tools that helps us get productive. We have practical advice on how to execute the technical aspects of our work, and manage them.

That leads me to #3, Staying Productive. How do you keep a team productive in the face of so many threats?

• following a process that worked in the past, even though it isn't working very well now
• getting bored with the technology and tools
• personality and team conflicts
• changes in the market and demand for your product
• disruptive technology threatening your existing stack
• teams becoming too cohesive and comfortable, so they stop innovating and productivity drops
• others

We have a lot to draw on for planning and getting productive, but the concept of staying productive is often lost on us. How a team can sustain value creation over the long haul can be fascinating, and we overlook it at our peril.

• Mobile Challenges for Project Management, Part 1: Project Factors
• Mobile Challenges for Project Management, Part 2: Human Factors

If your team is transitioning to develop mobile applications, I can help. Email me for more details if you are interested.

Others in this space:

• Karen Johnson teaches web testing for mobile devices
• Julian Harty teaches automation for mobile projects

I hope you find it useful.

Update, Dec. 10/2010: Mobile Dev Mag republished the piece this week: Testing Mobile Applications with “I SLICED UP FUN”. Check it and other articles out there.

A couple of years ago, I was the technical editor for a Linda Hayes article called "Held Hostage by Coders". I was working with a team performing a technical audit when the article was published. Linda's piece was timely and appropriate for the team to read, but there wasn't anything for managers to look at to improve their work. In fact, a technical lead admitted that the technical team were exhibiting the behavior described in Linda's article, but said: "What about the managers? They aren't behaving that well either. Do you have something for us?" I developed three management anti-patterns based on my own experiences and observation in the software industry and presented them to the team. They loved the concepts, and management and technical people felt there was a balance. I've brought up these anti-patterns in other organizations, and it seems to strike a chord. If you look at one set of behaviors (management or technical) be sure to look at the other side as well. I hope you find it useful.

The easiest way to get feedback is from other stakeholders. What does your manager think about your testing? How about the programmers, business analysts and customers (users) of your software?

The hard part with that answer is you may not be able to talk to all of those stakeholders. Or, they may not know what good testing looks like so they won't have answers that satisfy you. In some cases, the stakeholders around you may have such low expectations that their feedback might not help you at all. They may expect you to provide testing work that you might consider shoddy and negligent. In that case, you have to show them what great testing looks like. When that happens it's like graduating from a cheap box of wine to the good stuff. Once they've tasted the good stuff, it's hard for them to go back to expecting poor testing.

Even if you have good direction from other stakeholders, I recommend asking yourself some questions to help determine if you are creating value or not. This is hard to do, and will result in work for you over the long-term, much like personal growth endeavours. Don't expect quick fixes, but if you work in these areas over time, you will see changes in your testing. Here are some things to think about:

• Is my testing work defensible? (Cem Kaner talks a lot about this.) Think of a court case. What would a jury think if you testified and described what you did as a tester and why. How did you determine priority? Why did you test some things and not test others? (100% complete testing is impossible, so you have to make decisions to optimize your work. Are those decisions well thought out, or more subconscious? What sorts of things might you be missing that you haven't thought of?)
• James Bach talks about how important it is to have thought out and varied approaches to testing. What kind of approach do I have to testing? Do I consciously choose to have a varied approach using as many models of coverage as I can to discover important information about the product? Do I make the best use of tools, testing techniques and management approaches that I can? Or do I just do what the programmers or someone else tells me to do?
• In the absence of getting real feedback from real people on my project, what would happen if a well-known consultant came to visit me? Could I answer their questions about why I chose to test this way? What kinds of holes might they spot in my thinking? Would they see weak spots? More importantly, would I be proud to have Cem Kaner or someone else I look up to see what I actually do? Have I used ideas from testing thought leaders in my work and found out what works well for me and what might not work so well? Could I communicate my work to an expert outsider clearly and thoughtfully? If so, what might they think?
• Do I adapt my test plans and strategies from project to project based on the risks and rewards our project environment has at a particular point in time, or do I just copy and paste what I did last time, and repeat the same thing over and over?
• Do I track down and find repeatable cases for important intermittent bugs, or do I just file them and forget about them?
• Do I feel energetic, creative and proud of my work as a tester, or do I just feel like I am doing the same boring things over and over and filling in paper work and forms to please a manager?
• Can I look at a released product and identify ways in which my testing has improved the product experience for our end users?
• Do others on my team feel better with me around? Do they miss me and my creative input when I am away, or do they welcome the break from my negativity? Do they request that I work with them on other projects?
• Is my testing service in demand? Am I the person team members come to when they need help solving a particular problem that I am really good at helping solve?
• Am I aware of other approaches to testing that challenge my favorites? Do I understand approaches that I may not favor or I may even dislike, or do I just dismiss anything unfamiliar and threatening out of hand? Do I have an open-mind and look to challenge my ideas in testing to help improve?
• Am I learning about different ways I could improve my work? Am I aware of recent changes in testing techniques and tools? Do I know where to find information to learn from?
• Do I consistently try to do better than I did last time?

These are the kinds of questions I ask myself regularly. I don't always have the best answers to my own questions, but as time goes on, I feel much more confident about both my own answers to those questions, and more importantly, the value I know my testing work provides.