tag:blogger.com,1999:blog-8951904624959546499.post5919282415895825438..comments2024-02-22T05:36:59.121-05:00Comments on Test This Blog - Eric Jacobson's Software Testing Blog: Ways To Boost The Value of Testers Who Don’t CodeEric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8951904624959546499.post-80423142096852997312016-03-22T14:17:50.544-04:002016-03-22T14:17:50.544-04:00This reminds me of a blog post of mine about being...This reminds me of a blog post of mine about being a valuable member of your team: <br /><br />https://testingfromthehip.wordpress.com/2016/01/08/am-i-really-a-valuable-member-of-my-team/<br /><br />There are many ways you can make yourself indispensable to your teams.John Andrewsnoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-46579548639284403052016-02-19T17:09:41.490-05:002016-02-19T17:09:41.490-05:00Here are some ideas I've used in past:
- Assi...Here are some ideas I've used in past:<br /><br />- Assist automation folks with creating/specifying test data<br /><br />- Helping to determine best candidate paths/scenarios for automationBrucehttps://www.blogger.com/profile/04069210910053605316noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-30742784723100530212016-02-16T11:24:06.370-05:002016-02-16T11:24:06.370-05:00This is a great list! Along the lines of Being Vi...This is a great list! Along the lines of Being Visible, I'd add work to "de-criminalize" bugs. Work with the team so that when you do find bugs, it's something to be grateful for and resolved quickly (if warranted) rather than be shamed. Bugs are not bad, particularly when testers find them! I have run up against this several times, to the point of not even being able to use the word bug. Annette Crawfordnoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-52192293250769909672016-02-15T09:49:12.705-05:002016-02-15T09:49:12.705-05:00Dear Always fearful,
Thanks for your thoughtful c...Dear Always fearful,<br /><br />Thanks for your thoughtful comment. I agree, some of my suggestions are not that good. This was kind of like a brainstorm I decided to publish. Nevertheless, here are some clarifications, motivated by your candor:<br /><br />I didn't say automated scenarios are superficial. I said most automation engineers are writing superficial automation. By that, I mean most automation engineers are writing full stack checks interfacing with their product's GUI. This type of automation looks great in demos to managers but rots over time and doesn't provide as much value as the stories people like to tell about it.<br /><br />"Volunteer to stay late" does not mean work harder; note, I said take the time back. I'm speaking about the flexibility non-automated tests can often bring to the team. Non-automated tests can be performed on the fly with less consideration for design than automated checks. They can be thrown away for less cost. Testers who don't write code can leverage this skill and it often lends itself well to critical production patches or other timely test demands. I'm suggesting testers who don't code try to leverage said flexibility.Eric Jacobsonhttps://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-69708709188081551272016-02-15T00:42:51.316-05:002016-02-15T00:42:51.316-05:00Something in this post just ticks me off, and it&#...Something in this post just ticks me off, and it's not the part that calls the automated scenarios "superficial" (because I can tell myself "this does not happen to *me*"). <br />What bothers me is that the post seems to throw the non-coding tester into competition with automated scenarios, instead of with automation engineers. Advice like "volunteer to stay late" or "help code automation" are not stressing the value of the the non-coding tester, instead they are implying "Work harder to compensate for your deficiency", and "ring a bell whenever you find a bug" is not what I would call a professional behavior (to say the least). While a tester that can't code has a clear disadvantage when compared to a tester that can (same as a tester that can't do usability testing has a clear disadvantage compared to one that can), this is not the case when compared to "automation engineer", who is not a tester. <br />When comparing a tester with a non-tester, there is so much more that can raise the value of the non-coding tester: Familiarity with the product or an eye trained to look for problems. There are skills that can be acquired and raise the value of the non coding tester such as domain knowledge, and mediating between groups (More on that aspect in a blog post I really like by Brendan Connoly http://www.brendanconnolly.net/testers-translators/ ). <br /><br />That being said, there are some advice I really liked such as "work for your stakeholders" (I know you wrote programmers, I just expanded it a bit), and those of "bring new ideas" or, to some extent, "show up at design meetings" (which is a bit extreme for my taste the way it is phrased, but I do value greatly being active at design meetings). Always fearfulhttps://www.blogger.com/profile/10841585549361070791noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-65152931732580884572016-02-12T11:12:46.147-05:002016-02-12T11:12:46.147-05:00Thanks for the great addition, Patrick! Totally a...Thanks for the great addition, Patrick! Totally agree.Eric Jacobsonhttps://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-29434691979345784542016-02-12T00:21:37.889-05:002016-02-12T00:21:37.889-05:00Wow! What a great list, Eric. I would add getting ...Wow! What a great list, Eric. I would add getting involved in the User Acceptance Testing process. A testers knowledge of a product under test can help in creating testing documentation used during UAT. Also, by managing a product through UAT a tester can confidentially report a product as ready for release. Anonymoushttps://www.blogger.com/profile/17622157469166284193noreply@blogger.com