I was recently tasked to,
"Test every scenario you can think of and try to break the component"
What might be sensible in 'everything' when the application is a website?
NOTE: This particular site is ASP.NET with MS-SQL, however, I would like to know what would be covered in general as well. Thank you all for the great responses!
One definition: such that every code branch is tested. [100% coverage] Of course this has meaning only for non-static web-sites.
I'd start with a smoke-test - a broad test that checks the most basic functions. Then list out the most important features in order of importance, and create tests for those in that order. If the site is any size at all and regularly updated, you'll want to automate these tests using something like selenium.
In addition to Bobby Jack's list, I'd suggest protecting your website from most-stupid-user and hacker-user scenarios -- this would mean, among other things, protecting your URLs and QueryString properly.
Some of it depends on the context. Here's a few of the less obvious:
What is the "flow" of the site? Is there an order a user should access things?
Are there forms involved?
Are cookies involved?
Don't forget the "bonehead" tests.
Open a page, click the submit button. Did the form properly handle absolutely nothing being submitted?
Put the cursor in a textbox field. Pound on the keys a few time (blasted cat on my keyboard, blasted coffee spill shorting things out). Did the input validation work with "non-standard" data?
Submit a form/request. Hit the back button. Is the form resubmitting itself? Should it be? Is it displaying the proper data when coming back?
You'd be surprised how many times I got burned in the past by the "bonehead" situations.
for CYA purposes - go with Bobby Jack's answer
There are so many test types that can be performed given a piece of software that the list is endless and covered by multiple different types, there is no single answer that is suffice.
Functional testing, integration testing, performance testing, penetration testing, regression tests, compatability testing for browsers, stress testing - list goes on.
And that is before you drill down into each one and start talking specifics like css / xss attacks, etc
for websites, most of the common breaks you would think about during development some of the bigs ones are: preventing mysql injection preventing unauthorized access (non member getting into a member section) if at any time you have form submission, consider what would happen if the user altered the get or even the post data
those are all i can think of at the moment, all of these you wouldn't really "try to break" the site, you just throw some catches into your code.
In addition to Bobby Jack's list, and NomeN, and pretty much everyone else ... I don't see this mentioned specifically; apologies if it is. You didn't mention what type of site this is, but depending on the problem domain, specifically malformed data can cause headaches. For example: in an e-commerce site, what if someone tries to order negative quantities? Lots of things can be broken by "backwards" (for lack of a better word) input.
Also do not forget validation tools. The World Wide Web Consortium, the standards body for the web, offers a plethora of tools as do other fine organizations. Here are a few good online tools to:
Finally, here is one person's take on a reasonable checklist and here is a site with the grandiose claim of an online everything checker.
Actually,it is better to start with very common cases. Get a good set of typical use cases, and make sure that those are all tested thoroughly. Then, start branching out to slightly less common cases.
Testing is always a combinatorial situation, so you can't possibly test every scenario. Consider 10 browsers x 10 types of users x 10 methods x 10 OS x 10 forms = 100,000 test scenarios.
There are probably quadrillions of scenarios for any reasonably sized application.
Thus, you need to start with the most common scenarios, and then work your way from there. You also need to think about orthogonality of tests. Brute force "test all scenarios" just doesn't work.
It would be impractical to "test for every scenario you can think of." Why is this so? Using just 14 of the suggestions here, mostly from Bobby Jack's excellent answer, you would wind up with 2,654,208 possible tests. Realistically, you wouldn't or couldn't test for every one of those. So what should you do?
This is a great example of where pairwise (or other, more advanced combination testing methods) would be extremely useful. Just 38 tests would cover not only every parameter value at least once but it would include at least one test case that covered each pair of the parameter values interacting with one another. (e.g., Browser = "Opera" and CSS = "on" will be tested for, and Simulate Dropped Connectivity? = "Y", and Cookies Enabled = "N" will be tested for, etc.) A couple screen shots from Hexawise, a new (currently free) test design tool, can make this point better than I can in words:
This first image shows each of the 14 parameters with up to 6 values per parameter
Image 1 - http://pea.to/cU
This second image shows: (A) the inputs create 2,654,208 possible test cases / scenarios, and (B) just 38 test cases will test for every single possible pair of parameter values in at least one test case. (e.g., Browser = "Opera" and CSS = "on" will be tested for, and Simulate Dropped Connectivity? = "Y", and Cookies Enabled = "N" will be tested for, etc.)
Image 2 - http://pea.to/8B
Additional information on this method of maximizing coverage in as few test cases as possible can be found at www.combinatorialtesting.com, particularly at http://www.combinatorialtesting.com/clear-introductions-1
Justin Hunter - Founder and CEO of Hexawise - More coverage. Fewer tests. www.hexawise.com