Wednesday, August 8, 2012

Not testing? Not a tester?

I met up with a few colleagues last night, and after we had the official business mostly taken care of, we chatted briefly about what's going on at work. We don't work in the same companies, so the stuff we do tend to vary a lot.

I told I'm working, in addition to learning the product and finding problems on the side (=testing), with specifications, namely specification by example -style specifications. It just happens that for a product with a lifecycle, it's not a particularly good idea to NOT have a specification, and I refuse to write test cases that are separate since I've kind of bought in to the idea of living specifications. As this is work done for features that already exist, I do the spec based on what I learn when testing and do workshops with the product managers to go through if they're balanced examples instead of tests that cover all.

One of the colleagues pointed out, that what I'm doing isn't testing - I go into someone elses territory. In the next sentence he pointed out that actually what I'm doing is like creating test cases for someone else to execute, since most of the under-the-hood automation I create with the coding work done by my team's developers.

About a year ago another one of my colleages who I also met yesterday told me I'm no longer a 'normal tester'. Apparently that means, that I've earned my place and get invited to board meetings to help understand the information testing provides. And they actually listen.

I still think I'm a tester - at heart. I've put loads of hours in understanding what I could do, what I could have others do, and how to get just a little better at explaining what I'm doing and why. It's funny how upset I get when I hear that what I do is not 'normal' or that I'm not a tester. It just shows how important the craft is to me personally.

1 comment:

  1. I wonder who would say something like that..

    Well if I would try to envision myself as the person who said that, I could think that he might have been thinking about that stuff as simply as:
    - testing during design, is design
    - testing during implementation, is implementation
    - testing after something is implemented, is testing.
    And that a Tester can do any of these, but that whilst doing the two first s/he is not testing per'se, although s/he likely is creating a lot of value doing it.

    And he also very likely has not put as many hours into understanding that stuff as you have.

    Just a thought..

    ReplyDelete