At a recent internal forum, I hosted a panel discussion comprised of \u201csenior\u201d level testers at Microsoft. The panel was evenly split between managers and non-managers and we took random questions from the audience on career paths in test. The testers in the panel had experience ranging from 11 to 24 years in test. Some of the questions strayed slightly from the topic (e.g. \u201cWhat does the future of test look like to you?\u201d), but for the most part went well. The session was one hour, but could have held it\u2019s own for at least another 30 minutes.<\/p>\n
That\u2019s pretty much it, so I suppose I can end this post here\u2026<\/p>\n
But one question came up that I want to dig into a bit, and I know that some of you who occasionally read this blog have some opinions on the subject, so fire them away please.<\/p>\n
The question in mind may as well have been seeded by me, because it\u2019s a subject I\u2019ve brought up before. The question was: \u201cHas Microsoft swung the pendulum too far in hiring only programmers as testers?\u201d<\/em><\/strong> I can\u2019t remember if my answer was \u201cNo, but Yes\u201d, or \u201cYes, but No\u201d, or \u201cIt depends\u201d, but I\u2019ll give a (much) longer version here for your benefit.<\/p>\n BTW \u2013 I would bet that if I asked most non-microsoftees the response they would give for this question, they\u2019d say, \u201cof course \u2013 my {cousin | dad | sister | friend } who is the best tester in the {company | city | country | world } can\u2019t get a job there, and they\u2019re {fantastic | awesome | superman }. They just can\u2019t write code.\u201d<\/p>\n And, in many cases, they may be right \u2013 but maybe not \u2013 or it depends. Some context is in order. I\u2019m not the company expert on this, but my opinion and view of history is as good as any.<\/p>\n Our software is big and complex. We deliver platforms, operating systems, server products and put them into huge deployments. We need testers who can program to help solve the big testing problems that our systems present. Say, for example, you\u2019re a tester on the Exchange team, and you need to verify that messages of varying lengths travel from one endpoint to another successfully. No problem \u2013 send mail to a test account and make sure it gets there\u2026 well\u2026that solves one <\/em>happy path. The reality is that the tester needs to send multiple mails through the system with a variety of headers and sizes to ensure that anytime the message is broken up that it still ends up at point B correctly. And, going through outlook is probably not the most efficient way to test this, so it\u2019s probably better to construct the messages programmatically then send them through the system. Oh yeah \u2013 there are an almost infinite number of ways the server topology can be constructed, and those settings make a difference too (in other words, we need to deploy any arbitrary topology automatically on demand for these tests). As you can see, there are some obvious benefits to having someone who can program as a tester.<\/p>\n Microsoft has always<\/span> had testers that can write code. Always. For much of our history, we\u2019ve also employed testers who don\u2019t<\/em> write code (but who are still good testers). We\u2019ve found over the years that our best testers and best test leaders had a programming or CS background. I\u2019m guessing we also found that defining the career path (MS is really, really big on career paths) for testers was a bit easer to map out when we took programming background and application into account. We still use a lot of non-programmer testers in contract and vendor roles, and I\u2019m guessing we\u2019ll continue to do so. There are many great testers who have learned how to program, but over time we found (or I should say, my personal experience was) that when we fished in the pool of programmers for good testers, we found a much higher percentage of good people than when we fished in the pool of good testers looking for people who could write programs. So, for full-time \u201cblue-badge\u201d employees, we fish for testers where programmers live; we get what we want, and everyone is happy.<\/p>\n Hardly.<\/p>\n Note that in the above I referred to testers<\/em> who can program<\/em>. Where I fear we make the mistake in hiring is when we (or anyone else who hires \u201cSDETs\u201d) hire programmers to do testing. The difference is subtle, but important. A tester<\/em> who can program is a tester first \u2013 but they are a tester who can rely on computer knowledge or programming skills to do their work better. A programmer<\/em> who tests writes tools and automation first \u2013 hoping that it will help them be a better tester (hint \u2013 it doesn\u2019t work very often). For the most part, Microsoft has testers who can program \u2013 and they are freakin\u2019 awesome. The problems they solve and the way they go about it makes me proud, excited, happy, (and a bit jealous) all at once. It\u2019s what SDETs should do.<\/p>\n The industry perception of the SDET appears to be a role of writing automation and tools all day. When I hear this, I think of all the great testers I work with and tell people \u201cNo, No \u2013 just because our testers can<\/em> program doesn\u2019t mean that\u2019s all they do all day \u2013 they are testers first\u201d. Then, whether it\u2019s in 5 minutes or 5 days (but sometime soon after), I\u2019ll see a blog or a tweet or some other sort of message from someone saying \u201cI\u2019m an SDET \u2013 I write automation and tools all day\u201d, and I realize that there\u2019s still some work to do. It doesn\u2019t mean that most of our SDETs write tools and automation all day, but there are certainly pockets. My thoughts are that if you want to write tools and code all day, get out of my business \u2013 go be a developer. You\u2019re not helping me (and you\u2019re probably slowing me down), so leave me alone. I want to test, and I want to work along side people who feel the same way.<\/p>\n In the panel discussion I asked every hiring manager in the room to ensure that in the next interview they conducted that they looked for testers who used \u201ctechnical\u201d skills to solve their problems. Instead of making them write code on the whiteboard, give them hypothetical testing tasks and examine how and when they used the power of the computer to help them. For example, if I ask an interview candidate how he would know if a line drawn on the screen was straight and he started writing up an algorithm to scan the pixels on the screen and determine if the offsets were consistent with a \u201cstraight\u201d line, I wouldn\u2019t hire him (\u201cLook at it\u201d, or \u201cuse a straight edge while looking at it\u201d are both acceptable answers). However, if I describe the message transport scenario I used a few paragraphs above and their answer is to ask everyone in the company to send a bunch of mail, I probably won\u2019t hire you either. (I\u2019m working on an internal presentation on hiring testers \u2013 I\u2019ll come up with better examples :})<\/p>\n Every business is different, and your need for testers or \u201cSDETs\u201d will depend on your business. My call to action is this: If you wan to hire an SDET \u2013 hire a tester<\/span> who can program \u2013 not the other way around<\/strong>\u201d. <\/em>You and your product will be much better off.<\/p>\n","protected":false},"excerpt":{"rendered":" At a recent internal forum, I hosted a panel discussion comprised of \u201csenior\u201d level testers at Microsoft. The panel was evenly split between managers and non-managers and we took random questions from the audience on career paths in test. The testers in the panel had experience ranging from 11 to 24 years in test. Some…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[1],"tags":[],"class_list":["post-153","post","type-post","status-publish","format-standard","hentry","category-allposts"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/153","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/comments?post=153"}],"version-history":[{"count":0,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/153\/revisions"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}