MyPage is a personalized page based on your interests.The page is customized to help you to find content that matters you the most.


I'm not curious

4 Things about Testers that Developers Need to Know

Published on 30 August 16
12816
2
3

4 Things about Testers that Developers Need to Know - Image 1

First, I want you to know there's nothing personal. We're all on the same team here, even if you are at a company that silos QA and Development separately. Because we both want the code to work, and know that Management is pushing both of our teams to get it done quickly, and maybe throw in a few new features if they can get away with it. I feel no animosity to you at all; anything I find was already broken or didn't quite match what was wanted (regardless of whether or not the specs were aware of the concern). Yeah, it would be boring if we found no bugs during Testing, but we'd be OK. So let me start by telling you what I will look for, and what I'll do to help you along.

1. I will read the reqs, and test every detail of what they demand. This may include input of unexpected values or length. I'll feel a little bad if you miss something that's spelled out clearly, but I'll simply report it and move on. I'll make sure that the bug I write up is easy to follow and understand. I'll try to include a screen shot with the offense outlined in red, and a very clear explanation of what was expected vs. what we got, and maybe even a log file if appropriate. If I can use [automation testing], I will, because I realize the importance of fuller coverage and getting the bug reported to you quickly, to give you more lead time to fix it. I will endeavor to detail the constraints of when and how the bug occurs, so you can be aware of the scope, without needing to waste detective work on your end due to me doing an incomplete job.

2. I will look at things from the user's perspective, which may not be in the specifications. If a spelling mistake was requested, I may flag that as a problem. If something does not make sense (a red button to go, and a green one to stop), I may ask about it. If it just looks funny on the page, I may object. I will look beyond functionality to performance and security. Like before, I will be clear when writing up the bug, so I don't need to explain it due to negligence on my part.

3. I will look for edge cases, those weird scenarios that need to be properly trapped for. These might not be in the reqs, but they should be. This includes losing a communication connection.

4. You are allowed to QA how I present bugs to you; it isn't just me. If there's a better format, something I've left out, or something I've stated that is too vague, let me know. My goal is to present things to help you do your job. I am capable of improving my game.
4 Things about Testers that Developers Need to Know - Image 2


4 Things about Testers that Developers Need to Know - Image 1

First, I want you to know there's nothing personal. We're all on the same team here, even if you are at a company that silos QA and Development separately. Because we both want the code to work, and know that Management is pushing both of our teams to get it done quickly, and maybe throw in a few new features if they can get away with it. I feel no animosity to you at all; anything I find was already broken or didn't quite match what was wanted (regardless of whether or not the specs were aware of the concern). Yeah, it would be boring if we found no bugs during Testing, but we'd be OK. So let me start by telling you what I will look for, and what I'll do to help you along.

1. I will read the reqs, and test every detail of what they demand. This may include input of unexpected values or length. I'll feel a little bad if you miss something that's spelled out clearly, but I'll simply report it and move on. I'll make sure that the bug I write up is easy to follow and understand. I'll try to include a screen shot with the offense outlined in red, and a very clear explanation of what was expected vs. what we got, and maybe even a log file if appropriate. If I can use [automation testing], I will, because I realize the importance of fuller coverage and getting the bug reported to you quickly, to give you more lead time to fix it. I will endeavor to detail the constraints of when and how the bug occurs, so you can be aware of the scope, without needing to waste detective work on your end due to me doing an incomplete job.

2. I will look at things from the user's perspective, which may not be in the specifications. If a spelling mistake was requested, I may flag that as a problem. If something does not make sense (a red button to go, and a green one to stop), I may ask about it. If it just looks funny on the page, I may object. I will look beyond functionality to performance and security. Like before, I will be clear when writing up the bug, so I don't need to explain it due to negligence on my part.

3. I will look for edge cases, those weird scenarios that need to be properly trapped for. These might not be in the reqs, but they should be. This includes losing a communication connection.

4. You are allowed to QA how I present bugs to you; it isn't just me. If there's a better format, something I've left out, or something I've stated that is too vague, let me know. My goal is to present things to help you do your job. I am capable of improving my game.

4 Things about Testers that Developers Need to Know - Image 2


This blog is listed under Development & Implementations and Quality Assurance & Testing Community

Related Posts:
View Comments (2)
Post a Comment

Please notify me the replies via email.

Important:
  • We hope the conversations that take place on MyTechLogy.com will be constructive and thought-provoking.
  • To ensure the quality of the discussion, our moderators may review/edit the comments for clarity and relevance.
  • Comments that are promotional, mean-spirited, or off-topic may be deleted per the moderators' judgment.
  1. 31 August 16
    1

    very clear and easy to understand.

  2. 31 August 16
    1

    A very valid point on testing from user perspective. Very few testers have mastered the art of user experience testing in addition to the regular testing. Would you like to share more on how you plan for Test Automation when you are in an agile development process?

You may also be interested in
Awards & Accolades for MyTechLogy
Winner of
REDHERRING
Top 100 Asia
Finalist at SiTF Awards 2014 under the category Best Social & Community Product
Finalist at HR Vendor of the Year 2015 Awards under the category Best Learning Management System
Finalist at HR Vendor of the Year 2015 Awards under the category Best Talent Management Software
Hidden Image Url

Back to Top