This two day workshop was run in what is commonly referred to as the "LAWST" style of discussion and debate. For those not familiar with LAWST, it stands for the "Los Altos Workshop on Software Testing" and the Facilitation method has become a practice used by a number of organizations to help foster debate and move the discussion forward. It was as a facilitator that I came to POST and so it is as a facilitator that much of the information, discussions and takeaways are going to be filtered. I suspect that others who attended will fill in the blanks over the coming days and share their perspectives as well.
What also made this workshop interesting was that it was attended by several people that I recognize as some of "the names" in the testing community. The workshop was organized by Lynn McKee and Nancy Kelln, who I affectionately refer to as the "Wonder Twins" of software testing (meaning it's rare to see one without the other, anywhere). Fiona Charles and Janet Gregory were also in attendance. In addition, a variety of software testers from various industries within and around Calgary were present. I was the "Lone Yankee" in the group, so this gave me not just a glimpse into the topic we were discussing, but also the state of software testing in a different country and context than I was used to.
The topic of "Testing as a Service" is an interesting one, and it's one that I've both used, refined and struggled with over the years. There was spirited debate around this topic and the various angles that the speakers took on this. The conversation ranged from defining exactly what was meant by service, whether or not testing be regarded as a service meant that we would always be seen and treated as an "other" entity, and an especially lively debate regarding introverts and extroverts and their roles in the testing process (that one deserves its own blog post, and rest assured, it will be getting one :) ).
My initial take on this is to focus on the aspects of what we mean by "service". In one way, it's very noble. We are indeed providing a resource to a development team and a customer base. The level of commitment and involvement we put into it is a big determinant in what and how we perform, and how well our projects perform in the field. There's also a hidden aspect of the word service that we discussed at great length. That is the fact that, when we describe what we do as a service, we are, effectively, making our involvement to be "other" to the development team. We frequently questioned whether or not "software testing as a service" should stand alone from "software development as a service" or "system operations as a service". The point was made a few times that in some industries in Calgary, the service offerings were very literal, where companies could often decline to even engage software testing for their service aspect.
It has been my own experience that this is often seen as a semantic distinction, but it's a real one. Some might put it down to a choice of words, but it really does run deeper than that. For most software testers, unless you come from a strong programming background, the goals of being 100% integrated with a development team is probably not going to happen. Even in the most Agile of work places, testing is a cost of doing business, and it's an important one. While we are often integrated into development teams, that integration is rarely seamless (from my observation, anyway). In my own work environment, though I have the ability to talk with the programmers and discuss issues or seek out new areas to test, ultimately, I am a somewhat external service, and any time I'm not actively testing is a cost to the team. Many practices work into the ways that we test and collaborate, and we often debated the usefulness of saying that we were there to "serve in collaboration with the programmers".
Another point that was often brought up and clarified was the fact that, in many Agile teams, the term software developer goes well beyond those people who program. Programmers and testers are both software developers in that we are all responsible for making sure that the software grows, is tested and is of as high a quality as possible when we release it to the public. I personally find I can relate to that idea, and in some ways, it helps move the conversation along and gives us all opportunities to participate more directly with the programming team. In my case, though, I am ultimately seen as the last defense between a bug being spotted internally versus out in production. That doesn't change, and ultimately, that's the role I play on the teams I participate with. My service is that of making sure that I apply my wiles and my crafty nature to question software and see how well it stands up to scrutiny. Ultimately, if I don't do that well, then my service is of lesser value. Simple as that.
Expect to see lots more recollections and ideas from POST coming in the next few days.
No comments:
Post a Comment