Though The Testing Planet is available digitally, I urge you to subscribe to the print version. 1) it is way more fun and convenient (at least for us folks who prefer an actual newspaper with our morning tea), 2) it supports the magazine, and we need to support it and keep it going! The Software Testing Club rocks, it’s a great way to meet and exchange ideas with testers all over the planet. Give a little back to your testing community by supporting The Testing Planet.

Methods and Tools

I wrote a tool review of FitNesse for the Summer issue of Methods and Tools magazine. Please let me know if you have any questions about it.

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…

TJ and I might both have our head in the clouds, but I’m a big believer in civility. I’m not recommending that we all walk around on eggshells and worry about offending people. But I do think we need to all work hard to make sure that everyone on our software team feels safe to express opinions, and conversely, is willing to accept the team consensus or majority rule, and work to make whatever approach is taken successful.

This is something I want to take to heart for myself. Here’s an example. I’m trying to explain an issue to the programmer who is on production support this sprint. I’ve analyzed the problem and think I know how it should be fixed. He seems not to understand, gets impatient with me, throws up his hands and tells me I am mistaken. I could feel mad and hurt by this, or I can remember that being the production support monkey is frustrating and stressful. I’ve given him the information I wanted to convey, and I can leave him to process it. He’s smart and motivated to take care of our customers, so I know he will find a good solution. He shouldn’t be rude to me, but if I can avoid escalating the tension, we will have a good outcome.

Indeed, later the programmer comes over and apologizes, says now he understands what I was trying to say, and appreciates the research I did into the issue. We talk about the fix and how to test it.

I’m lucky to work on a team that, though there is lots of joshing and joking, is composed of people with a deep commitment to providing a quality product, and open minds willing to consider anyone’s ideas. I’ve been on teams that didn’t provide this atmosphere of respect and civility, and I must confess, I hightailed it away from those toxic environments.

The “agile” movement was built on principles and values. “Every difference of opinion is not a difference in principle”. Give your team time and space to agree on principles and values. Going forward from there, each team member will feel free to float their ideas and opinions, and have healthy discussions. That’s what makes a project successful.

News!

Janet Gregory and I have an article, and are interviewed in, this month’s Software Test and Performance Magazine, devoted to “Women of Influence in Software Testing”. Please check it out, it’s a great issue with lots of meaty articles.

I have a sidebar in Dawn Cannan’s terrific “Be the Worst” article in the inaugural issue of Agile Record.

Matt Davey wrote a wonderful thumbnail summary of our book in his review of it, we are grateful.

This book is a model of concise, clear writing. It’s packed with information in the form of narrative, bullet points, graphics, photos, stories of real teams and projects, exercises, tips and examples. The authors have been walking their talk for a long time, so you can feel confident about following their advice. Their flair for language makes the book fun to read. It could be a quick read, except you’ll find yourself stopping to reflect on your own experiences, and thinking about how you could apply the technique you just read about on your own team. Each chapter includes hurdles you may face, and a checklist summarizing action items for you, the reader.

I particularly enjoyed the little vignettes with dialog from a typical team illustrating topics such as “Not Quite Done Yet” and “Getting Ready to Demo”. The authors have insight into all aspects of coding, testing, and managing software teams. You’ll find advice you might not expect in a software-related book, such as “Be kind to yourself”. The focus on people and teams will make you a better person and team member.

This inspired a rant which I posted (OK, Joey McAllister posted it for me) on my StickyMinds blog entitled Independent Testers? or Independent Thinkers?. I would love to have comments on your experiences with testers and programmers working together.

Coincidentally, the latest Methods and Tools magazine has an article I wrote on Coding and Testing: Programmers and Testers Working Together. In this article I work through an example of how testers and programmers collaborate to develop new features, similar to the examples Janet and I use in our book. Please check it out along with the other interesting articles in Methods and Tools.

I’m working with programmers and testers together more than ever on my new team. Right now we are all on a voice chat, with a shared desktop, writing FitNesse/SWAT tests and code together. (OK, I am really just watching, but I’m learning, and asking questions.)

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?

Quality Matters is aimed at Eastern Europe, but I’ve found the first two issues quite good, helpful information no matter where in the world you work! I particularly enjoy Alessandro Collino’s articles, this month it’s a comparison of Robot Framework and Fit.

Quality Matters is published by Quality House, which is organizing SEETEST, June 16-17, Sofia Bulgaria. I’ll be there, and I look forward to meeting software professionals from southeastern Europe there!

In other news – there are starting to be a lot of “agile testing” training courses offered. Watch this space, because Janet and I are working on our own three day training course in agile testing.