It is very safe to say that I have completely blown my objective of writing a weekly blog post in 2014. I could analyze the plethora of reasons, but that is really not important. What is important is that I have been inspired to challenge the testing community?
In my opinion testing has been reframed from the POV of what testing does it require to generate a great product to what great testing can be accomplished in a given timeframe and make the product great.
The reframing could be worded better, but hopefully you get my point.
So here is the two hour challenge:
You are being hired to test a website. You will be provided only a URL. And you only have 2 hours to test.
How would you structure those two hours and what would you deliver?
Please post your testing approach as a comment. Don't be shy because I am sure there are no wrong answers!
I will try my best to share my answer next week.
In my opinion testing has been reframed from the POV of what testing does it require to generate a great product to what great testing can be accomplished in a given timeframe and make the product great.
The reframing could be worded better, but hopefully you get my point.
So here is the two hour challenge:
You are being hired to test a website. You will be provided only a URL. And you only have 2 hours to test.
How would you structure those two hours and what would you deliver?
Please post your testing approach as a comment. Don't be shy because I am sure there are no wrong answers!
I will try my best to share my answer next week.
6 comments:
Assuming the url has some kind of interface to interact with, I would analyze the page, find the most visible feature I would click on first, or use, or whatever, then as the question - 'Is this your most important feature?' If it's yes, test that, if it's no, I've found my first bug.
Thanks for taking the challenge. I will post my answer soon. If I understand you answer correctly you might not get paid. :) By asking the importance of a feature you are writing a defect potentially against requirements. Am I understanding that correctly?
That's all bug are - writing defects against requirements or missing requirements or even yet-to-be-thought-of requirements. Bugs are tools of improvement. I don't see them as negative things. When a tester reports a bug, you are informing whom ever is in charge of the project your professional opinion of the thing you are testing. If they don't see it as a defect or something to fix or alter, then that is their prerogative. I would like to see every bug fixed, but sometimes, that's not possible. It's a tester's responsibility to not only test the functionality, but also the performance, usability, security, stability and even the visual content for a product owner. Even if some of those are at a very basic level. If I only just make sure it functions, I'm only doing part of the job.
Thanks for the clarification! I think where I have a difference of opinion is that there is an assumption that requirements exist. Today I have a tendency to test as if requirements do not exist. Put another way I have become jaded and do not trust requirements. I definitely appreciate you perspective.
Finally commented on this :)
2 hours of testing:
Hit main URL directly with top 3 browsers/OS
determine site structure/site map; hit all pages directly, checking that each loads, style/layout is consistent througout site. (spread this testing across top browsers)
use a link checker to ensure all links on site are valid (http://www.wired.com/2014/08/facebook_bug/)
run markup validation service: http://validator.w3.org
verify all data/content with external information (ie, phone numbers, addresses, emails)
We do a similar thing with our Black Ops Testing webinars.
Essentially we pick something to test, spend some time on it and feedback on our approaches, thinking , etc.
Post a Comment