Practical Software Testing Resources?

rhartness asks: "I've been a software engineer by profession for a few years and a programming enthusiast for much longer. As my experience has increased, so has the size of the projects that I have had to work on. My software testing method involves trying to do everything I can think of that the end user might try to do. Hopefully, this will break the application if there is a bug within my code. The current project that I am working on involves numerous tiers within a smart client environment. Trial and error testing is no longer sufficient — there is simply too much that could happen. Searching the Internet for software testing resources provides an abundant amount of information but it's often quite philosophical and verbose. What are some practical resources that Slashdot readers use for testing your software projects?"

First, understand testing

[faster]

Read "The Art of Software Testing" by Glenford Myers. Even if you only get a few chapters in, you'll get a lot of ideas that will improve your testing. "Testing Computer Software" by Cem Kaner is another good one.

Automate, automate, automate.

[Z0mb1eman]

Step 1: write a systematic test plan. There are all kinds of acronyms and books out there on the subject - I doubt you need it. At the very least you can start with CRUD (Create, Read, Update, Delete) and go from there. Cover the success path, cover the failure paths.

Step 2: automate. This isn't optional if you're planning to maintain a project beyond the 1.0 release. For specifics, it depends on your project. Is it mostly a Java app (http://www.junit.org/)? Is a lot of the logic in the database (http://www.dbunit.org/)? Is it a web app, regardless of language (http://webtest.canoo.com, http://wtr.rubyforge.org/ [rubyforge.org])?

Step 3: run your automated tests and laugh at how much easier it makes your life than manual testing.

Re:Automate, automate, automate.

[Anonymous Coward]

Step 1: write a systematic test plan. There are all kinds of acronyms and books out there on the subject - I doubt you need it. At the very least you can start with CRUD (Create, Read, Update, Delete) and go from there. Cover the success path, cover the failure paths.

Step 1.5: show the test plan to someone else who's reasonably familiar with the project being tested. Let them ask questions about the test plan. Add any new test cases they think of (or that their questions cause you to think of) that you feel are important to test to the test plan. Repeat if you have time (and if you don't have time, show the test plan to someone else then start on step 2 while they're reviewing it.) The developer must, if possible, be one of the people who reviews the test plan. [Your test cases may trigger the developer to realize they hadn't thought about how to handle a certain case, which may lead to a modification to the feature specification and/or your test plan.]

Step 2: automate. This isn't optional if you're planning to maintain a project beyond the 1.0 release. For specifics, it depends on your project. Is it mostly a Java app (http://www.junit.org/)? Is a lot of the logic in the database (http://www.dbunit.org/)? Is it a web app, regardless of language (http://webtest.canoo.com, http://wtr.rubyforge.org/ [rubyforge.org])?

Step 2.5: have someone else code review your tests, just like you'd have someone code review the project code. When they find bugs in your test, fix them. When they find bugs in the project code ("What, you're testing to make sure 2+2=5? That's what the code returns? That needs to be fixed."), pass them back to the developer. When they offer suggestions for other tests to be added, update your test plan and create those new tests.

Step 3: run your automated tests and laugh at how much easier it makes your life than manual testing.

Step 4: If possible, generate some measurement of code coverage and look for lines of code that are not being tested. Add test cases for those lines to your test plan, and add automated tests to the test bed. If you can't think of a way to exercise that line of code, ask the developer. If neither of you can think of a way to exercise that code, ask if it's dead code and needs to be removed. While code coverage is not the be-all and end-all of measuring how effective testing is, if you're not exercising a line of code you'll never find a bug that may be hiding there.

Depending on what you're actually doing, there may be other steps that you can/should run or other suggestions the Slashdot community can make. For instance, I test numerical software, and one of my steps is to think about how the weird edge cases of IEEE arithmetic (Inf, NaN, denormal numbers, etc.) interact with each other and the code.

Ahem... try this

[plopez]

Go to wikipedia, look up software testing. Click aon some of the referenced links, then chase those links and you will find a wealth of information.

Just google +"software testing" you will find tons of links.

you might try these guys: http://www.softwareqatest.com/ [softwareqatest.com]
They have some nice links as well.

Or would you rather start with a newsgroup? Go to google news groups and seach on software testing again. Lots of knowledgable and helpful folks hang out on those boards.

BTW, a colorful phrase for "trying to test everything a user might do" is "soap opera testing". Google it, the story behind the name is sort of fun.