The best testers that I know really enjoy breaking stuff. They have this special mission to break anything they get their hands on. They take great pride in finding the stuff that the developer probably didn't think of. They smile when it behaves weird, they laugh when it crashes. Their ego rises when they tell the developer that they were smarter.
And therefore, the one who built is, is not the person who makes it his lives mission to break it. Breaking it means more work, more searching for bugs, and then testing again. And nobody likes doing that. Except for awesome testers. They love looking at the face of a desperate developer getting frustrated by a nasty bug.
> Their ego rises when they tell the developer that they were smarter.
I've been in QA for a few years, after an initial career in development.
I do find great pride and joy when I break things, and I do laugh sometimes when I see silly behavior. Testing can be thankless, and even anti-appreciated, so the validation of finding something is welcome.
But I never "tell the developer that I'm smarter," and I've never thought that way. They are merely two different roles, with different focuses and different allocations of time. The tester role exists in part because we are not perfect.
The relationship between the two roles would be much better without "I'm better than you" or "you can't do what I do, so you test" attitudes. Both sides, and the organization, profit when we work together with respect and appreciation.
Maybe it was just me, but I read GP as slightly tongue in cheek - I hope most testers don't actually have such an antagonistic relationship with their devs!
I agree with you completely that they're underappreciated and minimized - I've seen corporations cut their testing staff in favor of automated tests, only to find that overall number of bugs between releases rises. (note: this is not a knock on automated tests)
I've also noticed an elitist mentality, usually among junior developers (but sometimes in senior devs or management as well), that a developer can do any job or role better than anyone else with a bit of training and coding. IMO, both of these are very immature views, and extremely dismissive of the value that domain expertise and a critical, analytical set of eyes can bring.
From the Dev end of the spectrum to the QA end: thanks for everything you folks do. Shitty software destroys people's confidence in our work and solutions, and rework is expensive and bug-prone: you save us from a lot of that.
>The relationship between the two roles would be much better without "I'm better than you" or "you can't do what I do, so you test" attitudes. Both sides, and the organization, profit when we work together with respect and appreciation.
The relative pay scale for a developer and tester with equivalent education and coding experience already speaks volumes about how deep that respect goes. Also, note who gets laid off first when the budget gets tight.
But I never "tell the developer that I'm smarter,"
Agreed. I am also a tester and I would never do this. I try to encourage a more cooperative relationship with developers rather than a psuedo-antagonistic relationship.
I often think of the story about IBMs black team. It's a cute story, but in reality, you don't want your company running that way.
Great to hear that you have the good tester mentality. My text was indeed meant to be a bit tongue in the cheek. But none the less it is completely correct.
The ego thing depends on the relationship you have with your colleagues. Sometimes I have very professional relationships with them, but other times they really become friends. And in that case, the "I'm smarter than you" really get's said, but more in a fun way.
I was a tester for a few years, and then moved into development. With tight deadlines on projects, I appreciate having a tester to send my work to for validation. Unfortunately, I am not doing TDD or any other automated testing, so having a second set of eyes is not something to take for granted. And usually, they don't laugh in my face when something is broken.
Great perspective and I wholly agree, especially as a consistently oddball way of looking at the world. I've been fortunate to have a ridiculously large capacity for, uh, knowledge? Facts? Trivia? Stories? I'm an explorer and I like to break things because it's like crossing fences to find new worlds. What's back here?!
It's like my life is a never ending quest to fill a bucket that can never be full - but it's an enjoyable one!
The skill of breaking things down is also what I believe made me very successful as an "Proposal Coordinator" because an RFP is a big, intimidating, multi-section Hydra of tasks. Looks scary!
Then, piece by piece, the threads can be tugged at, finding which parts need what, who, when, why, and working backwards from a Deadline, it's a quite gratifying process.
Correlative: I frequently assert that Creativity can not be taught, because it is inherently Disobedient. It can be Nurtured, or Channeled, but it's not well-suited for rigorous, lock-step cultures.
I'm sure this describes some developers and QA people, but good professionals are not usually this petty.
I try pretty hard to break my own code, and I'm also glad when I find something wrong.
But here is why it can be very good to have someone else test my code: I am blind to the same things that the guy who wrote the code, since both are me. I also, despite my best efforts, have a developer perspective on the system rather than a user perspective.
It may be the ideal, but the reality is that they will always be finding bugs. The really good ones will automate the simple cases, incorporate combinatorial and fuzz testing, and then go on a mission to break things.
Sadly, most of the really good ones are developers-in-potentia, and move out of the QA role after a year or two. Those who really are meant to remain in QA are gold - if you find them, don't ever let them go.
Academically I would agree, but I disagree out of business principles. Testers finding bugs is the ideal situation of a good production process. Ideally not a ton of them, but if a programmer has really thought through every potential edge case then they're likely over-engineering the product, and the business will suffer from being too slow.
Not ideal if it takes you 4 weeks what I can write buggy in 2 days, and my tester does 2 days and me an extra 2 days to fix it up. (my tester is also cheaper than me).
Maybe your software is perfect, but maybe my customer is happy to pay me 4 times less for the software, even though it still contains the few bugs my tester overlooked.
however the real world sucks, most field bugs are caused from configurations you would never think of and a ever changing world
i.e. apple just recently decided to break 5 years of responsive design practices by ignoring the maximum-scale meta tag. their decision is not without merit, but suddenly many web applications started behaving weirdly and encountering usage pattern they were never tested on before.
those edge cases never existed before, but I bet only the shops with dedicated testers caught them within the first week.
I agree. My argument isn't against exploratory testing but rather against the idea that developers shouldn't also be cultivating that way of seeing systems.
Fair and I think you are correct. As a counter balance though, there's an expression via Murphy's Laws that I think is worth keeping in the back pocket:
"It is impossible to make anything foolproof because fools are so ingenious."
... Except the things they break aren't real breakages. "Hey the favicon is showing as a 404 in the console. WE CAN'T LAUNCH THIS. How can these engineers be so STUPID!?"
So as you say good testers are really good at breaking things, so what makes a developer really good? Maybe there is a related skill seeing testing and developing are related (testers test/break what a developer builds). So then maybe a developer needs to be good at fixing what the tester breaks. Which would mean he lets go of his ego or pride in his own code and is able to accept that he/she writes flawed code and be really good at fixing or re-building it. I think it's been ruled out that developers are never going to always write the code correctly the first time (surely that can be a good goal to have, but not something to believe is going to actually happen) so maybe what sets apart a really good developer from a regular one is that he knows that his code is going to have flaws and is happy to hear about them so he can go fix them and improve and re-build his broken work.
Edit: another thought: maybe the developer should see his code as a problem rather than an answer so that he can constantly question it. Rather than being satisfied that something you wrote is now done or solved, instead you see it as something that has likely created new problems for you to be able to solve (Mark Manson said something insightful about this, how solutions don't really solve everything completely as it might solve 1 problem it always presents new problems/challenges)
Developer is too general a term for deducing an ideal mindset.
A tester should be empowered by defeating the system. That's also great for some kinds of development (like in security). For some systems, it's better to be empowered by seeing the things you build grow as you act, for others, it's better to be empowered by seeing they grow by themselves after you act. There are places best fit by people empowered by ensuring no problem arises (also the dominant mindshare in ops), by comprehending things none could before, and by making hard things easy. There are probably places for other people that I'm overlooking too.
I still think the 2 are more related than they appear to be. I saw a comment on programming reddit (in regards to this same article) about how developers use constructive thinking whereas testers use desctructive thinking and it is a separate mindset, but I don't know that I agree with that as destruction kind of leads to construction, maybe developers could also benefit more with destructive thinking as well.
Take for example Socrates, he went around asking questions that would contradict people's arguments by destructively questioning a particular definition that was presented, but his purpose in doing so was to construct a better definition of whatever thing he thought was ill-defined. Each time a contradition happened a more well-defined definition was able to be produced
Knuth: "I get into the meanest, nastiest frame of mind that I can manage, and I write the cruelest test code I can think of; then I turn around and embed that in even nastier constructions that are almost obscene."
That's a distinction without a difference, good software testing is still an ethos of imagining boundary conditions and corner cases to "break" the code. A bad tester will create a test with a few basic inputs, see that it looks fine and be content with that.
Having been both QA and dev in my career (and vastly preferring the former), I beg to differ.
- TDD / unit testing: "Does it do the thing right?" i.e. does the code behave as the developer intended? This type of testing tends to be more internal than external.
- QA testing: "Does it do the right thing?" i.e. does the code fully satisfy customer requirements (including integration testing) and other functional and parafunctional requirements?
Certainly there is overlap between the two, e.g. the developers are working from their own understanding of the customers requirements, but they are not IMO the same thing.
TDD is a way to design software and make it easy to refactor. It is mostly "white box". That it leaves behind a solid test suite may not even be the most important thing about it.
Yeah, there's someone that I know who just savored doing that with any game or piece of software they encountered. They just really took a "for shits and giggles" attitude towards breaking everything. It's an attitude that I've just never had, but it's really great that people like him exist.
I recently watched a talk by an Adobe lead developer, and he stated that they had twice as many testers on the payroll as they had developers. Makes sense.
And therefore, the one who built is, is not the person who makes it his lives mission to break it. Breaking it means more work, more searching for bugs, and then testing again. And nobody likes doing that. Except for awesome testers. They love looking at the face of a desperate developer getting frustrated by a nasty bug.