testers and devs

[year in the sun]

. . . nooooooo, i don't want a religious war. i just said something about being a tester on my intro post and got asked to explain what i meant, and i figured the answer (and any conversation that might ensue) would fit better here. i hope there are other testers around who can comment as well.

here's what i said:

what i actually am is a software tester. by choice. i noticed someone else saying it's a loathed profession, but personally i'm endlessly thankful someone invented it just in time to save me from doomed attempts to be competent at anything else. i think of it as sort of a padded cell in which it's not only safe to be the way that i am, but even (in theory) the 'right' way to be

and here's what monika asked:

What do you feel is the "way of software testers"? The way you are that is just right for being a software tester?

well . . . h'm. i don't know how to explain it in a single thing. it's more like a cluster of things. i never would have made a very good programmer, i understand now. or i dunno, maybe a perfectly competent one, but never as happy a one as i am a tester. i did go to programmer 'school' since back then as far as anyone i knew knew, programming was the only 'thing' you could do. it wasn't a very good school, in fact it was a rat-awful one. but i learned enough of several languages to write a 'project' in each of them. this was mid-90's, btw. we did little projects in c, pascal, dbase iii, cobol, something called clipper, assembly code and um . . . i think c for windows. event-based was just coming out. if oracle and sql existed then the place i went to sure didn't know about it.

funny thing is, i was good at it. i wrote very good programs, for what they were. i sure got obsessive enough. drivelling sweats of obsessiveness, remove-my-kidneys-with-a-hot-spoon-and-i-won't-blink kind of thing. but i always liked the debugging best. even then i spent 20% of my time writing the code, 40% testing it and then ripping the whole thing apart to get rid of flaws. or designing all kinds of additional stuff to trap all the different user scenarios and handle them well. and the other 40% crouched over my debugger like it was a gerbil, lovingly feeding it special data and then setting breakpoints that would make it reveal what it was up to in there. i would have been a hellish developer

(not that i wrote sloppy code; i wrote it as well as anyone else. it's just that once i wrote it, i always tested the snot out of it. and i always had a whole lot more fun doing that than with the code itself)

i dunno. i just somehow learn more about something, understand it better and more completely, by drawing hypotheses based on its behaviour than from just looking at the inside of it. it's kind of hard to explain. it seems to me like a 'real' dev just looks at the code if they're trying to track something down (remember this code i wrote was pretty simple designs). i could have done that too with my stuff, but it bored me. even when the code's open to me, i'd rather make it show the behaviour, and then draw my construct of the underlying logic by inferring from that. it's the inference process itself that i like. it's more fun, to me, than just looking at it. there's an extra step in it, an extra loop.

i'm much better at understanding what i don't understand than i am at understanding what i do understand. i know that sounds weird, but it's sort of true. i think i construct my picture/understanding of things by defining whatever they're not. it's like the story of the sculptor who was asked how to carve a statue of an elephant. he said 'well . . . first you get a big block of marble, and then you cut away everything that doesn't look like an elephant'. that guy could make a tester i find devs very interesting, because in my experience a developer-type sculptor would probably say something like ' . . . and then you carve it into the shape of an elephant'. it's a totally opposite perception process from mine. i don't even really understand what they mean by 'an elephant' from something so vague.

in general life, i was just referring to the fact that it's not like i learned how to be like this in the process of becoming a qa analyst. it's how i always was. you know how people are always going around nowadays exhorting each other to think 'outside the box'? well, that's not really my struggle, personally. i've kind of gone through most of my life going 'huh? there's a box?' because i don't seem to see it at all.

i don't know if that helps, but it's awful darned late.

[headprogrammingczar]

Devs: "Nice elephant"
Testers: "Haha your rock is broken!"

This would actually make a really good religious war.

[year in the sun]

Devs: "Nice elephant"
Testers: "Haha your rock is broken!"

This would actually make a really good religious war.

uh . . . you mean elephants?

[Monika]

Devs: "Nice elephant"
Testers: "Haha your rock is broken!"

This would actually make a really good religious war.

What rock?

[headprogrammingczar]

I was referring to the story he mentions about the elephant carving.

[Monika]

I was referring to the story he mentions about the elephant carving.

Oh, that rock, sorry.

In the way I always heard that saying/joke/anecdote it was with a block of marble, I didn't associate that with rocks. (And it was always a lion, but that doesn't matter.)

well . . . h'm. i don't know how to explain it in a single thing. it's more like a cluster of things. i never would have made a very good programmer, i understand now. or i dunno, maybe a perfectly competent one, but never as happy a one as i am a tester. i did go to programmer 'school' [...] but i always liked the debugging best. even then i spent 20% of my time writing the code, 40% testing it and then ripping the whole thing apart to get rid of flaws. or designing all kinds of additional stuff to trap all the different user scenarios and handle them well. and the other 40% crouched over my debugger like it was a gerbil, lovingly feeding it special data and then setting breakpoints that would make it reveal what it was up to in there. i would have been a hellish developer.

You could also be a developer in software maintenance, couldn't you?

[year in the sun]

You could also be a developer in software maintenance, couldn't you?

yeah, but . . . that would be development. before someone told me that qa existed as an actual in-its-own-right job and i still thought development was all i could do, if i could have created my own dream job it would have been to sit somewhere debugging all day. i liked coding because it provided problems to solve, but i didn't want the actual bother of writing the code. my version of bliss would have been if somebody else would do that part for me. pretty lucky how things work out, isn't it?

people always talk about i.t. types needing to be problem solvers. and sure, we all are. but i'm not all that interested in the 'solving' part. for me the really interesting problem isn't the problem. it's the problem of figuring out what the problem is. once i've got it, i don't very much want the bother of doing the fixing part.

i don't know - are you guys different about that?

[Monika]

I am a software developer in maintenance, I debug most of the day. I also have to fix the bugs. Sometimes it can get pretty annoying. Then I would prefer if someone else debugged it to the point of finding out what the actual problem is . We should work together in such situations <g>. But sometimes it's also the other way around, I have found the cause of the bug, but fixing it is cumbersome, then I am fully with you, it would be nice if someone else could do it.

QA/testers here don't do any debugging.

[year in the sun]

I would prefer if someone else debugged it to the point of finding out what the actual problem is . We should work together in such situations <g>.

yeah, that would be pretty much a neat situation. i'm wondering if you're on what we usually call a hot-fix team, i.e. working on stuff that escaped the pre-release process and is getting reported up from someone in the poor-bloody-infantry trenches of tech support. because usually here anything that's discovered during the build-test cycle is investigated and fixed by whoever wrote that code, and the fix is retested by the tester who found the problem. and, y'know. if we're doing our part of it right it really shouldn't be insanely hard for the developer to isolate what's going on.

we did have one dev guy here who was a sort of floating gun for a while. he'd 'investigate' the stuff that had never come clear enough to be dealt with the usual way. catching our overflow basically, from either dev or from test. now that's a tough job. in retrospect i don't think either of us deserved the way he and i treated each other

But sometimes it's also the other way around, I have found the cause of the bug, but fixing it is cumbersome, then I am fully with you, it would be nice if someone else could do it.

i think what you're doing sounds very difficult because you're wearing both hats and switching it up so much. when i was debugging my own code, what i found hardest was the changing focus. tracking something down needs a different kind of focus from fixing it once you know what it is. one thing is so specific and single-track and targeted, you eliminate everything except the one single thing you're looking at. and then to fix it you have to pull your head back out and not look at the one single thing. you have to look at the bigger thing.

i think if i was running your world , i'd arrange it more like the situation that we had here. our tracking-dog dev only had to complete the tracking down. once he knew what was causing it, his role ended with writing it down. so then the defect could be passed back to the developer who's doing that code, and that's the guy who'd do the fixing.

QA/testers here don't do any debugging.

no, we don't either - but then i'm an application tester, so my scope is different from, say, a performance tester's. i used to want to, but i don't think it would do many people much good if i had access to a debugger now. i'm not code-y enough anymore; i think i'd just waste people's time and trash my credibility. however i do always dig around until i find out where the logs and the database are, and i use those quite a lot. i get a bit of 'what do you need to know that for?' from people, but i don't think i'd even work for a place that was really hardcore black-box and just refused to let testers see anything but what the user would see. that's just stupid.

[Monika]

i'm wondering if you're on what we usually call a hot-fix team, i.e. working on stuff that escaped the pre-release process and is getting reported up from someone in the poor-bloody-infantry trenches of tech support. because usually here anything that's discovered during the build-test cycle is investigated and fixed by whoever wrote that code, and the fix is retested by the tester who found the problem. and, y'know. if we're doing our part of it right it really shouldn't be insanely hard for the developer to isolate what's going on.

I fix bugs found by customers and regression bugs found in regression tests (by testers). The people in the "new development" team get to fix their own bugs that were found in the acceptance tests (usually the same testers). The "customer bugs" are sometimes reported by consultants (of our own company or an associated company) who are working on the customer's site, sometimes by the customers themselves. They open error messages in a special tracking system and these messages allow me to log directly into the customer's system and debug there from remote. Which is necessary usually, because their customizing is different from the one in our Q system, so the bug doesn't show in our Q system and that's why the testers didn't find it.

i think if i was running your world , i'd arrange it more like the situation that we had here. our tracking-dog dev only had to complete the tracking down. once he knew what was causing it, his role ended with writing it down. so then the defect could be passed back to the developer who's doing that code, and that's the guy who'd do the fixing.

It's okay to fix the bugs, too. I am pretty lucky that I am in a small special team / combination of two teams, we share offices / a hallway: new development (who created the bugs uh software <g>) and maintenance. So I can learn from those who developed the stuff how it works, where bugs might come from and so on and can ask them directly. But that's just because we have a highly specialized software, for all the "standard" software it's different, there are huge maintenance-only teams. I think this creates all kinds of problems, but our top-management obviously thinks it's absolutely perfect.

i get a bit of 'what do you need to know that for?' from people, but i don't think i'd even work for a place that was really hardcore black-box and just refused to let testers see anything but what the user would see. that's just stupid.

Many of our developers and maintainers don't like the testers too much (maybe because they always find out where the software is broken and "create" the work of fixing it ) and want to spend as little time as possible answering their questions. But I have added them to my instant messenger (they are remote, in India) and explain them anything they want to know. I think they deserve to know and it makes their testing better, too.

[year in the sun]

Many of our developers and maintainers don't like the testers too much (maybe because they always find out where the software is broken and "create" the work of fixing it )

that's a frustrating attitude for anyone in qa here, because the technical recruitment process often involves a perfectly needless level of nitpickiness about our 'qualifications', which then turns out to be completely irrelevant, and often even actually discouraged. so over and over again i've been asked by someone with only a fuzzy idea of the job itself if i can [fill in the technicalspeak], only to find once i'm on the payroll that everyone's fending me off from, say, checking the database.

i think sometimes devs get defensive because of that 'a little knowledge is a dangerous thing' thing too. it's true that it's less fun to tell someone something if you fear they're going to misunderstand it or misapply the knowledge. especially if they then really believe they've found the answer and can tie up your time in arguments about it. but that doesn't happen nearly as often as they seem to fear.

i don't know if the misconception that every tester is merely a failed/wannabe developer is still as prevalent as it was, but i've detected some of that too in the past. devs guarding the secret of the magic smoke because they imagine i actually 'care' in the sense of wanting to be a smoke-blower myself. it can be difficult to clear up that misconception in a tactful way. a programmer friend of mine once suggested i answer it with 'dude . . . i've got waaaaay too much self-respect to do whatever it is that you do for a living'. it's true in the sense that i have no interest at all, but it didn't seem very productive to say it that way

i do tend to resent it though. nobody likes to have it implied that they don't know what they're doing when they know they do.

[Monika]

i think sometimes devs get defensive because of that 'a little knowledge is a dangerous thing' thing too. it's true that it's less fun to tell someone something if you fear they're going to misunderstand it or misapply the knowledge. especially if they then really believe they've found the answer and can tie up your time in arguments about it. but that doesn't happen nearly as often as they seem to fear.

That's extremely rare. E.g. I have shown testers how to look at certain logs and read the XML files stored there. So far there has been 1 case, incidentally today, where this didn't work out, i.e. if the tester hadn't known it she would have just reported it to not be working and now she accidentally looked at the wrong one and thought it was working. This spared me 99 other cases where I had to return the error message to ask at what time the test was executed to dig in the logs myself.

i don't know if the misconception that every tester is merely a failed/wannabe developer is still as prevalent as it was [...] i do tend to resent it though. nobody likes to have it implied that they don't know what they're doing when they know they do.

Here testers aren't thought of as wannabe developers, rather the opposite end, like these were random unemployed people picked of the street with no qualifications at all. I think it's pretty likely they have college degrees. I have considered asking some I know more closely, but that could be pretty insulting, too.