Saturday, July 12, 2014

Two Hour Challenge

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.


M.E. said...

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.

Carl said...

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?

M.E. said...

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.

Carl said...

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.

Nerdy-girl said...

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 (
run markup validation service:

verify all data/content with external information (ie, phone numbers, addresses, emails)

Tony Bruce said...

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.