Sapient Testing: The "Professionalism" Meme

flowchainsensei 35 minutes later:

• • For me, the key flaw in James’ argument is when the “testers” role – as “she who divines the the system that the customer imagined” – conflicts with someone who already HAS that responsibility, such as maybe a Product Owner, Dev, or Chief Engineer (a la Toyota PDS).

  • Of course, in the real world of dysfunctional projects and organisations, its probably better to have SOMEONE own this issue (the tester) than the more common “no one”.

  • - Bob

Matthew Heusser about 1 hour later:

• • @flowchairsensei – I don’t see a conflict, but of course I wasn’t thre.

  • The customer says “I want A, B, and C”

  • The developer writes A-, B+, and C.

  • The tester say “You know, it’s only A-. And It’s B+ – is that okay? And the logical combination of A, B, and C gives us event D as an output – are you sure you want that?”

  • I see a lot of value in that combination.

  • I’m Matthew Heusser. And I am a professional tester.

jasonporritt about 1 hour later:

• • That definition of “professionalism” applies to everyone involved in a software project—it’s evidence of caring about the outcome and respecting the customer. There is opportunity to clarify and improve requirements at every step in the process.

  • @flowchainsensei—While one person may have responsibility for system definition, I think the better the entire team understands the vision the better the outcome will be.

Jared about 1 hour later:

• • “Agilists have been very focussed on creating suites of automated tests, and exposing the insanity (and inanity) of huge manual testing suites.”

  • It’s insanity to do this by automating those huge manual testing suites :-/

Dave Nicolette about 2 hours later:

• • I agree with James and Bob about professionalism in testing and the importance of sapience. I think it underscores the value of evolving conventional roles and people’s assumptions about who “owns” what.

Markus Gärtner about 2 hours later:

• • About a year ago I already stated that I truly believe that testers like James Bach, Michael Bolton, Elisabeth Hendrickson, Matt Heusser, .... have contributed in large amount to the craft of software testing, and actually I see software testing as a craft more evolved as the software development craft. Of course, the software development craft has evolved over the last decade to a great deal, and I am really looking forward to the next steps in this overly refinement – for both, programming and testing.

  • Remember the first law of professionalism: A professional takes responsibility for each of her/his actions.

Mohinder about 3 hours later:

• • James believes that a good tester should have conversation with the product. He says and I quote, there is a specification from product owner, actual product delivered by the developer and imagined product dreamt by the product owner. It is the job of the tester to find the truth, the only truth so help him God. A professional tester would and should use self managed testing play book, and James believe in it, to come to the right conclusions. In some ways tester may be playing god but it would be in the best interest of the project. Decision to accept the one truth is not his but it is a good weapon to come to a consensus. I agree with James’s many ways but not all. He is a self-constructed individual and would not shift his ground where he spent thousands and thousands of hours digging for answers.

Joshua Lewis about 4 hours later:

• • I still see some waste in this. If the tester’s role is to recognise ‘the truth’ or ‘the vision’, surely this should precede the development effort? Or else the development effort is waste. If a tester picks a deviation from the vision, its already too late.

  • One of the points of both BDD and early & continuous delivery is to refine visions as quickly as possible (in part by crreating tangibles), so that deviations from the vision happen less.

  • Also, where do business analysts fit into this?

  • It is the professional responsibility of everyone involved in developing software to understand the value they’re providing – i.e. how they’re fulfilling the vision (and also how to best provide that value). Doing anything less is unethical in my opinion, because effectively you’re stealing money.

  • I’m unconvinced that its the tester’s role to understand and validate the vision of the system.

Jim Hazen about 4 hours later:

• • This is the key thing we need to keep in mind here: “interpreting the {} with intelligence.” where the {} could be requirements, design, Use Case, Stories, code and whatever else a tester needs to learn from/about in order to do the job of testing.

  • Admittedly I’m not a fan of the word “Sapience”. Most everyone outside and inside the testing realm are looking at this and going “What?”. I believe in simplicity. What James Bach et al. are talking about is exactly what Robert Martin has put so succinctly. Performing a task ‘with intelligence’.

  • Common sense, use your brain… use cognitive process to direct you. Experiment and explore. Use prior experience to guide you while you ‘explore’ (experiment). Pose a hypothesis and try to prove or disprove it.

  • Now does this lead to or relate to professionalism. Possibly… what I think it leads to is encouraging both testers and developers to “think” about the system/software and see a bigger picture ideal of what the system should do. It allows them to see the forest for the trees.

Geoff about 5 hours later:

• • As a UAT tester, I admit that this view resonates with the way I work. The users have spent a lot of time with the requirements analysts / technical architects / developers / etc trying to specify what they want. These guys in turn try to implement it within the limitations of the chosen technologies etc.

  • I am involved with the project almost from the very start, so in the beginning of the project, I intepret the requirements into how I think the system will work – this helps to validate/test the decisions made by the designers – any differences in interpretation can be resolved before the system is built.

  • Once development has started, I start to run the tests, which validates/tests the decisions made by the developers – any differences in interpretation will be raised to the designers for resolution.

  • At each stage, I help to provide a second opinion, which helps to increase the chances of the client actually getting what they wanted (as opposed to what they asked for). I wouldn’t say that I am responsible for ensuring the client gets what they ‘imagined’ – that is the job of everyone on the project. My job is to identify areas where the intepretation of the imagination is not consistent across the project.

Janet Gregory about 7 hours later:

• • I agree with Uncle Bob but I am sad it took him this long to realize that “professional testers are utterly essential to agile development.” There are many of us who have been saying that for years.

  • The bit about ” Ultimately it is the tester’s job to divine the system that the customer imagined” bothers me quite a bit though. I do not think we, as testers are magic. All we can do is expose hidden assumptions, etc. to the light so everyone can see.

Jon Bach about 7 hours later:

• • Nice post, Bob…

  • I was in the audience for your Quintessence (“Craftsmanship Over Crap”) keynote at Agile2008. You said something to the effect that programmers should strive to put testers out of business. As a tester, I was one of the few who did not stand and applaud.

  • I wanted to shout “The day when programmers can consistently out-test me, I will happily resign!”

  • But I got over myself. You were advocating craftsmanship, after all, and I was a craftsman. I just had a hard time believing that you thought programmers could (and would WANT to) write code that was so elegant and lean and crafted that it took into account ALL of the failure patterns in a tester’s imagination and experience.

  • But it was an Agile audience, after all, and I figured the prevailing belief of the crowd was that testers were irrelevant anyway, now that programmers had everything unit tested, automated, green-barred, and keyword-driven.

  • Two years from that keynote, and I find that with this post, either you DO get it, or I was too defensive to understand your message back when. Maybe both.

  • The only nit I had above was that testing isn’t becoming a craft, it always has been.

  • I think your point was, the belief that testing is a craft is burgeoning. I hope you’re right. As far as I can tell, I was the only speaker chosen for Agile2010 to talk about a specific approach to testing that emphasizes craftsmanship.

  • But maybe when I deliver that talk, I’ll find that there’s more people in the audience that would agree with me than disgree—as long as they’re not defensive. :)

  • Jon

Dave Nicolette about 7 hours later:

• • +1 to Joshua Lewis

  • “I still see some waste in this. If the tester’s role is to recognise ‘the truth’ or ‘the vision’, surely this should precede the development effort? [...] Also, where do business analysts fit into this?”

  • IMO the traditional role segregation between analysts and testers (to look for functional defects) has become obsolete. Instead, I see a role that combines analysis and testing-in-the-development stream, and a different role for after-the-fact testing of whole applications (mainly focusing on non-functionals).

  • I continue to receive the impression that many of these arguments are fuelled by a desire to maintain familiar role definitions. People have assured me this is not so, yet they then proceed to resist the evolution of their roles. Is it really so difficult to think outside the boundaries of traditional role names?

Lisa Crispin about 8 hours later:

• • +1 on Janet’s comment. Though I must add, Uncle Bob, that when I first met you back in 2000, you were encouraging to me as a tester on a new XP team, and gave me Ward Cunningham’s phone number, and Ward was a huge help to me too! Maybe it was wishful thinking but I’ve always gotten the impression you respected testers such as myself and Janet.

  • I went to a great talk by Jeff Patton on Monday night at Agile Denver. I like his message the best – that we software teams are in the same boat with our business people, and we’d better learn the business, help them find the right things to focus on, and make the business successful (at least, that is my interpretation of what Jeff says). This fits with the post here IMO.

Torbjörn Kalin 1 day later:

• • @flowchainsensei: It’s the development team’s (programmers, tester, etc) responsibility to understand the end user’s needs. Bringing the development team close to the end user is IMO probably the most important agile (and lean) message.

  • Saying that it’s the Product Owner’s role only (and not also the developers’) to understand the needs is like building a barrier between the development team and the end user. Sounds very unagile.

  • (I would even argue that having a Product Owner is waste, however most of the time essential waste.)

Michael Bolton/michael@developsense.com 1 day later:

• • I’m glad that, with this post, Uncle Bob is helping to spread the meme of testing professionalism that James and the rest of our community have been trying to develop and to spread for years. A couple of comments:

  • Uncle Bob said Ultimately it is the tester’s job to divine the system that the customer imagined; and then to illuminate those parts of the system that are not consistent with that imagination.

  • To this, @flowchainsensei responded, For me, the key flaw in James’ argument is when the “testers” role – as “she who divines the the system that the customer imagined” – conflicts with someone who already HAS that responsibility, such as maybe a Product Owner, Dev, or Chief Engineer (a la Toyota PDS).

  • I wasn’t at the presentation, but I doubt very strongly that James argued for this. Please rest assured, @flow, that our community of testers would see usurping the product owner’s role as a testing pathology. The Quality Assurance view might suggest that Testers Know Better Than Product Owners. We don’t. Our community would see that perspective as being an obstacle to product development, rather than the service we seek to provide.

  • We do try to determine the system that the customer imagined and the system that the development team is trying to build, but we’re by no means the only ones who do that. The programmers, the designers, the documenters, the managers, and the product owner all do it too. Our purpose as testers is to act as highly developed sense organs—eyes, ears, noses, fingertips—for the project team. When we see an inconsistency between visions, we illuminate that, but we don’t drive it; it’s up to the entire development team to develop a shared vision of the product. When we see an inconsistency between the product and the shared vision, we illuminate that. Our job is to inform, not to decide. We are not the brain of the project. Any attempt by testers to control the project is something that we would see as the antithesis of professionalism—although, alas, we have seen that sort of thing before.

  • @markus: I see software testing as a craft more evolved as the software development craft. Despite my respect for you, I disagree. I’m working towards the evolution of the craft, but I think that you might be suffering from a little selection bias. There is still much work to be done in extending the meme.

  • @Mohinder: In some ways tester may be playing god but it would be in the best interest of the project. I could not disagree more with this. We are neither omniscient nor omnipotent. We’re humans like everyone else on the project, and we’re powerful and fallible by the same degrees. Perhaps your disagreement with James is based on a misunderstanding of what he’s saying.

  • @Joshua: If the tester’s role is to recognise ‘the truth’ or ‘the vision’, surely this should precede the development effort?

  • Recognising the vision before the development effort would be a great idea, except no one knows how to do it. If we knew from the inception of the product exactly what it should look like and exactly how to do it, we wouldn’t call it “development”; we’d call it implementation. Cem Kaner put this exceedingly well several years ago, when he pointed out what a terrible idea it was to do all test planning up front, at the very time when we know less than we will ever know about the product and the project. The requirements, the product, the team, and the project all develop as we go. In the process, we learn more about all of these things, and our learning about each element feeds into learning and development with regard to the others. That is why our community insists that testing is far more than a process of confirmation, verification, and validation. A developing product requires testing to be a process of exploration, investigation, discovery, and learning.

  • @Dave: What are the skills and responsibility of project management? Of business analysis? Of testing? Of programming?

  • I believe that we should all develop skills in those domains. I have done through both practice and study, and I have taken on all of these roles at various times in my life. Yet my existing skill set, my temperament, and my passion are all directed towards testing. That is, I have a speciality. Should I reject the distinctions between these skills and these preferences? That is, should I abandon my speciality? And if that’s true, do you believe that (without your passion for it) I would be as capable a programmer as you are? Your resume suggests that you have never taken on a testing role. Would your passion sustain being in that role?

  • —-Michael B.

Jonathan Rasmusson 19 days later:

• • Great discussion all.

  • The only thing I would add is that being a great tester doesn’t mean you only have to test.

  • You can be a great tester and have a passion for analysis. You can be a great tester and have a knack for project management. You can be a great tester and enjoy coding.

  • I guess what I am trying to say is I prefer to view testing as a role and not necessarily a dedicated person or group of people. It’s way too important.

  • Find the best people you can. Look for people who have a passion for quality and take pride in what they do. And the professionalism will take care of itself.

  • Cheers – JR