A few tidbits from dinner conversations:

• First, a couple of nights ago, Bret was talking about psychological barriers that hold us back. The example he gave was that maybe he wasn’t as successful as a developer because he didn’t want to redesign people’s code. This got me to pondering. I’m generally prone to avoid controversy. In fact, when I started out as a tester, doing automated testing, I used to say that it let me create things but no one criticized my code, plus there were a lot fewer people doing test automation well. The latter half was definitely true then, but now I’m wondering if it’s more this confrontation avoidance that keeps me from really feeling like a tester — if I’m truly a tester, I have to criticize other people’s code, something they’ve put effort into. Will have to think more about this.
• Then, tonight, a bunch of us went to The Main Street Mill restaurant in Front Royal. One of the topics that came up was the future of testing as a career path in its current form. Bret maintained (as I have heard Cem maintain in the past) that testing as it’s currently defined will become a dying profession. Instead, testers will have to get better programmer skills and/or business analysis skills. They’ll find themselves pairing with developers more and so either path will become more prevalent. All the testing skills will still be needed, but, as Jeremy pointed out, the lines between tester and developer need to blur. The testers who have good developer skills will work on creating the code, bringing their testing skills to bear for exploratory testing and developing good unit and acceptance tests. The testers who get more business analysis skills will take on more roles towards being customer surrogates.
• The idea of having tasks specific to testing came up as well. The idea is that you specifically have tasks like “test the xyz thing” in which the pair consciously changes their mindset and takes more of a testing approach than a development approach. This task would not necessarily be done by testers, particularly as the lines between the roles blur.
• Chris talked about testers becoming more of a wild card on the project, taking on different roles as needed. He commented on how testers are generally the only ones who get the more global knowledge of the application rather than focusing on a specific area.
• Brian had a comment on the role of testers. He said that the role of testing is to “articulate the perceived status of the software”. That is, if we were to release the software right now, what would customer’s perceptions of it be.
• Finally, we talked about what kinds of things testers need to know to fit in on agile projects more. We hit two topics before sidetracking in to less reportable ordinary conversation — patterns (and, specifically, it seemed to be the Gang of Four patterns) and that it’s ok to pair.

  Anyhow, that’s some of the points we talked about at dinner.