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.

Many of the teams do a great job of automating their tests, and a few teams have their own continuous integration (CI) that runs multiple times a day. Other teams have automated tests, but must wait for the company-wide build to run, which is usually only once per day and sometimes not that often. They don’t get feedback fast enough, and that slows them down – a lot.

I’ve been asking why some teams struggle to automate tests, and why some teams don’t have their own CI. I’ve also asked my own team why most of our functional tests are automated through the GUI, rather than behind the GUI. We use FitNesse, but mainly to drive GUI tests with SWAT.

The answer I get a lot is “It’s the framework”. We have three architecture teams, and there is a framework (maybe there is more than one, I don’t fully understand it yet) that apparently makes it hard to test at the page or object layer. In addition, some teams’ code has tentacles into legacy code written in Delphi whose tests are written in WinRunner. Also, the current framework appears to not be fully supported with automated unit tests, it was developed a few years back. Programmers new to the framework seem to have a hard time understanding how to work with it. The framework clearly causes a lot of frustration. A new framework is under development, but it won’t be available for some time.

In order to understand the existing framework and find out whether the new one will facilitate testing behind the GUI, I was fortunate to get to meet with the leader of the architecture side of the development group. He gave me an overview of the new framework’s current design (which may change), aimed at making our product easily configurable by customers, using web services. It looks like this design allows testing under the GUI level.

Additionally, I learned that it is possible to test under the GUI in the current framework, and I met someone on another team who has automated many FitNesse tests at the object level. I plan to get her to show me how these tests work, and see if what she did would work for our code.

I haven’t worked at a company this large since the early 90s, and I’ve never worked in a company, agile or otherwise, that had “architecture teams” and “frameworks”. I get it that our product needs to look and work consistently across the board, so it does make some sense to centralize the design of the UI and perhaps other parts of the system. However, if the architecture is done by one team, what does that mean for programmers on other teams? Is the fun part of their job taken away? Do they get a chance to think for themselves and improve the product?

It also seems to me that there needs to be a lot of communication amongst the entire development community of our company, that all programmers should have some input to the architecture process. I’ve found that communication between teams in general is a bit lacking. Each team is so focused on delivering its part of the product, they don’t always feel they have time to go talk to other teams. So, for example, perhaps nobody on my team has talked to the person who did a lot of FitNesse functional tests.

Does your company have an architecture team, and/or a framework that everyone works with? Please comment and share your experiences. As a tester, I’d like to know what I can do to help my team deliver the highest possible quality when we have to work with a framework designed by someone else.

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

I could have happily worked with my previous team until I retire, but you know me, I cannot resist new opportunities. So now I’m on a small Scrum team – that is one of 28 Scrum teams at my new company! Yes, this company actually manages to have 28 teams, including some which provide infrastructure such as frameworks and deployment, working together to release a high-quality commercial software product four times a year.

Yeah, back in the day, XP was for little, co-located teams. “You can’t do shrink-wrapped software with XP” was just one of the many axioms I heard.

Now I work in an agile organization with about 140 developers, some (like me) in remote locations, delivering software both for Windows client and for a hosted solution. (I don’t know everything about it yet so sorry to sound vague!) If you had told me this five or ten years ago, I wouldn’t have been sure it could work.

Since my new 5-person team is a self-organizing Scrum team, we picked our own ScrumMaster, which ended up being me. I love being an uncertified ScrumMaster, and plan to delegate a lot, because I’m also committed to remaining a hands-on tester. I attended my first Scrum of Scrums (some attendees called it the “SoS” which I loved) on Friday. Each of the 28 ScrumMasters (some in the room, some on the phone) was called on to say if they had any impediments. This happened to be a release day, so I thought there might be lots of impediments, but most teams didn’t have any. Those that did got help right away. The meeting was over in 10 or 15 minutes.

Granted, not every team is high-performing, and some practices I’m used to are missing altogether. But think about it, a software development organization that large, which only implemented Scrum four years ago, able to coordinate and release critical value frequently, at a sustainable pace. That’s agile in anyone’s book.

Follow this space for my adventures as I enter a whole new world!

One topic discussed was that given that we all agree that agile adoption isn’t process change, it’s culture change, why do we teach process rather than culture and values? I think the reason (and most participants said this) is that teaching process is a lot easier than trying to teach values. We’re used to learning in a straightforward “how to” way – follow these steps and you will succeed. But that doesn’t work, because everyone has a unique situation.

What values do you need to succeed as an agile tester, or with testing on an agile team? In our book, we identify 7 key success factors for agile testing. Are these values or process? I think they are values:

• Use the whole-team approach. The whole development team must commit to producing high-quality software that delivers maximum business value.
• Adopt an agile testing mind-set. We have a chapter in the book with “Ten Principles for Agile Testers”, and explain that an agile testing attitude is proactive, creative, open to new ideas, and willing to take on any task.
• Automate regression testing. Without automated regression tests, the team will fail in the long run, because there won’t be time to do adequate exploratory testing, much less to do all the manual regression tests as the product grows. This is really a practice, but its root is in the value of feedback.
• And feedback is our next success factor: Provide and Obtain Feedback. Feedback is a core agile value, and testers are in a prime position to help provide the feedback that keeps the team on course.
• Build a foundation of core practices. Again, these are practices such as continuous integration and working incrementally, but they are rooted in core agile values such as simplicity, communication and feedback.
• Collaborate with customers – another core agile value.
• Look at the big picture – another strength of testers. Even code produced test-first may cause unintended results in other parts of the system. Testers help the team evaluate how each story fits into the larger system.

I’m happy that our book focuses a lot on cultural issues, agile values and principles and how they relate to testing on agile teams. As I worked over the weekend on my presentations for TISQA, I found that I also tend to teach process rather than values. I updated my presentations to make sure I am explaining values, principles and the importance of letting those guide you, rather than try to provide a cookbook approach that probably won’t work for everyone.

Do you agree that the success factors are values, or am I deluding myself?