Ok, ok, it's not literally called boutique tester. But listen to this:
You: someone who can make guesses about how a website or application is going to fail, prove that you're right, and then communicate it clearly and effectively to the folks who need to fix it. Ideally, you also have the ability to predict the things about our products that will confuse or dismay a new customer.
As an example of what we do, imagine we have four months to write, test, and ship two applications on a brand-new hardware platform (with no specimens of said hardware in the building) while still updating and maintaining our released products on both platforms. Could you keep up without going totally crazy in the process?
If so, we'd like to hear from you — we're looking to expand our QA department by adding another Software Test Pilot.
Here's the ad, along with the companies "Jobs" site. The position is in Seattle, Washington, and I suspect the position is everything it claims to be.
About the future of software testing
For the past couple of year I have been engaged in a sort of shadow-boxing match of ideologies with some folks. Predominantly in the United States it has been with the idea of the tester/developer - that "the tester of the future" /will/ be writing test automation code, not doing actually testing, and the customer-facing tester will "go away."
Now certainly, I grant that testers will become 'more' technical over the next decade or so, but then again, our entire society is becoming more technical.
I still think it will take a variety of skill sets to find defects on different types of projects. We might have more tester/dev-ers in certain places, but I think "going away" is a bit strong.
In fact, I believe there are some simple economic conditions that make a boutique tester a valid choice for a company like "the omni group."
More to come. Or maybe more on test estimation to come. Either way, I'm writin' again. :-)
Thursday, November 18, 2010
Subscribe to:
Post Comments (Atom)
13 comments:
A reference or pointer to some / any of the folks touting the tester of the future as an automator would add some credibility here. Can you help out?
The statement: "dev/testers will fit all future testing needs - business testers will go away" (to paraphrase:) wouldn't that be anti context-driven? Also keeping the testing/checking split in mind?
There will be a need for skilled business testers in the contexts where skilled business testers are the best fit. But sure more will be coding testcases because more contect areas will be code-able
/@jlottosen
@blog:
The actual impetuous for that quote came from a conversation I had with Ian Savage, where he claimed that he expected tomorrow's tester to be a tester/developer, pairing with the developers to write code.
Ian is an architect at McAffee, and I expect he'll appear on the STP Podcast TWiST (This Week In Software Testing) in the next few weeks.
If you want another example, you could look at Alan Page, a test architect at Microsoft, and some of his writings, including his presentation on code reviews for testers at PNSQC: http://angryweasel.com/blog/?p=236 - or consider that microsoft has a policy where the only full-time employees they hire are SDETS (software developer engineering in test).
You could just look at this blog and google for the term 'SDET.'
For another example, look at some of Elisabeth Hendrickson's public comments about hiring for software testers. She isn't saying the future is the tester/developer ... instead she's saying that the vast majority of test positions advertised today are for tester-programmers, based on data pulled from monster.com, craigslist, ec.
If you'd like more examples, I can come up with links, certainly.
@jesper:
Yes, if it wasn't clear, I'm not really keen on the all-testers-must-write-code thing. :-)
...so code reviews are automation?
And because MS hires testers who can program, they write automation all day?
I think you're making stuff up based on your opinions - which I suppose is ok - it's one way to learn, but ...oh never mind. I don't think you'll ever get it.
Referring to your opinions on this blog can't really be classified as references.
1. My talk (check your links - attention to detail is an important trait for testers) at pnsqc had nothing to do with automation.
2. For more info on the types of testers MS hires, see http://angryweasel.com/blog/?p=180, or http://blogs.msdn.com/b/alanpa/archive/2008/09/25/the-t-the-d-and-the-det.aspx
You (and I'm sure I've told you this before) are equating "can code" with "writes automation all day". That's simply incorrect - at MS at least. The rest of the industry may vary (I don't know, and don't pretend to know).
I don't think there is a one-size-fits-all testing skill set that we can point to and say "all testers will need to be exactly this and nothing more or less".
There is a wide range of software out there, built by a wide range of companies with a wide range of existing skills and the testers they choose to hire will need to have skills that fit within those contexts. Personally I think the more tools you have in your testing toolbox the better, and focus on the development end of the test spectrum at the expense of the hands-on skills is short-sighted.
In my experience more testers need to look beyond "does this work" to "how can I make this fail", and often that is not something that can be discovered in a desktop application without time spent poking at the interface from a user perspective.
@blog -
I can appreciate the difference between "testers who can code" and "writing test automation *all* the time."
So there is certainly plenty of shades of grey between the tester-automator and the pure exploratory tester.
But I do think it's fair to say that expecting testers to participate in code review is way over on the developer side of the spectrum. So, no, I don't appreciate the little dig about attention to detail.
Second, since you're alan page, do you really *need* references? I mean, haven't you picked up on it allready?
Here are a few more for you pleasure:
Consider Extreme Programming:Installed (major section on why you don't need a QA department).
Conssider "Testing Extreme Programming" (which has a chapter titled "Manual Tests", when he entire content of the chapter is he words "Don't have any manual tests.")
Consider Kent Beck's words at Quality week 2001. ("Enjoy your testing jobs ... while you have them.")
Or listen to my elegant coder interview http://elegantcode.com/cast/files/cast/ECC_20_MattHeusser.mp3 and see just how hard the interviewer tries to imply that automated tests are "good" and anything else is "bad."
As for my blog posts, I try to refer to primary sources and and react to them, using systems thinking. I do not appreciate having my life's work dismissed as "your opinion", but it's a free country.
If that's how you really feel, Alan, well ... I'm sad.
On the one hand, I'm sad because, to be fair, that wasn't my best work. I didn't feel a need to provide references because I thought the body of evidence was overwhelming. On the other, I'm sad that someone I respect so much would react in that way to what I thought was a legitimate point, including the splitting hairs over review vs. automation.
The good news is: I'll get over it.
"You (and I'm sure I've told you this before) are equating "can code" with "writes automation all day". That's simply incorrect - at MS at least."
TO BE CLEAR:
You've never implied to me that you are a member of the "writes automation all day" crowd, Alan, and I didn't mean to make that point or connection.
However, if I re-read my post and that one comment, turn my head and squint, I can see how someone could misconstrue what I wrote.
I'll try to be more clear in the future.
I am serious.
Another reference:
http://saucelabs.com/blog/index.php/2010/11/the-future-of-testing/
Matt - you're a nice guy and I like you. I'm not attacking you, and I apologize if it came across that way.
I was, however, attacking your work.
You said:
...that "the tester of the future" /will/ be writing test automation code, not doing actually testing, and the customer-facing tester will "go away."
and then went on to talk about testers becoming more techical.
My point (and the point I think - but may be wrong - that you are missing) is that I completely agree that testers will need to be more technical in the future (and now for that matter).
Where we disagree in interpretation is how that technical acumen will be applied.
I agree that using "tech skilz" to write automation or tools all day isn't the future of test (if it is, we're doomed). Based on the original quote above, I interpreted you saying that tech skills == automation. I didn't think I squinted to see that, but if I did, I'm sorry.
But we still need testers to have technical skills. Partially in order to understand a bit more about what these complex systems we test do, but we also need testers who can rely on coding skills to help them solve problems when necessary. We need testers who, when they find an issue, can pair with the developer to isolate or fix the issue. Without these skills, I don't think we can advance.
(and no, I don't think all testers need tech skills, but there's certainly a case for the necessity in the future.
Oh - and it seems that every site in the world that uses openID can find "Alan Page" from my profile...except blogger.com
Sorry for the potential repost - not sure if you blocked my original reply (which is ok), or if blogger got mad at me again.
Matt - you're a nice guy and I like you. I'm not attacking you, and I do apologize if it came across that way.
I was, however, attacking your your words in this post.
You said:
...that "the tester of the future" /will/ be writing test automation code, not doing actually testing, and the customer-facing tester will "go away."
and then went on to talk about testers becoming more techical.
My point (and the point I think - but may be wrong - that you are missing) is that I completely agree that testers will need to be more technical in the future (and now for that matter).
Where we disagree in interpretation is how that technical acumen will be applied.
I agree that using "tech skilz" to write automation or tools all day isn't the future of test (if it is, we're doomed). Based on the original quote above, I interpreted you saying that tech skills == automation. I didn't think I squinted to see that, but if I did, I'm sorry.
But we still need testers to have technical skills. Partially in order to understand a bit more about what these complex systems we test do, but we also need testers who can rely on coding skills to help them solve problems when necessary. We need testers who, when they find an issue, for example, can pair with the developer to isolate or fix the issue. Without these skills, I don't think we can advance.
(and no, I don't think all testers need tech skills, but there's certainly a case for the necessity in the future.
Oh - and it seems that every site in the world that uses openID can find "Alan Page" from my profile...except blogger.com - I'll sign my posts in the future.
-Alan Page
Hey alan, just to clarify:
When i wrote "the tester of the future" /will/ be writing test automation code ..."
I was representing the position of a particular school of thought about test automation, it is not one I share.
I do think that /in general/ the tester of the future will need to be "more" technical, but I think that 90% (or higher) of all the millennial /are/ more technical than the baby boomers.
I mean, the typical 16-year old knows more about their cell phone than I do.
So you're saying to advance the field, (more) testers will need to be (more) technical. That's what I'm saying too.
I think our difference is one of degree and focus. There's certainly room for nuance.
My original reply could lead someone to think you were in the "100% automation" group, and the wrong selection of your writings could lead someone to that conclusion; again, if I misrepresented you, I apologize.
Post a Comment