how to test a software project? [closed]

Question

For any software project testing is important. I am new to testing so how can I test a developed software project? . What are the steps and levels of testing? I wanted to know how the software projects will be tested in companies?

Answer 1

wikipedia has a good article on Software Testing, and will be better than anything I write here. However, I'll try to describe the process at the higest level:

At the highest level you have perhaps three types of tests:

1. unit tests - tests for individual units (eg: functions, methods). If you give function A the inputs x, y and z, does it return the right value? These are cheap, easy and fast, and help you to understand that individual units of code work precisely as they are designed to work.
2. system tests - do the individual units work together? This is where you test the business logic of your application, and to test the contract between units ("if you provide the arguments x,y,z I'll return A" and "if you give me the wrong arguments I'll raise error B"). These help you to understand whether the individual units work together to accomplish a task.
3. performance tests. Performance in this context could mean raw speed, or it could mean capacity ("can the website handle 1 million hits per day?"), system load, latency, etc.

unit tests are most often done using a framework called junit (for java), nunit (j.net), or something similar. There's probably an *unit framework for whatever language you are using. Many software shops use their own custom tool to do this. Most often (but not exclusively), unit tests are written by the developer that wrote the unit.

system tests can take many forms, and there's not always a single solution that will work for a particular application. For example, if your site is a web site you can have service layer tests ("if I call the web API of my site, does it return the right value") and presentation layer ("if I click on the button in the UI, does the form get posted to the proper URL?) tests.

While unit tests are almost always automated, system level tests can be automated, manual, or a combination of automated and manual. User interface testing is often a manual process. While there are tools to drive the UI for a variety of types of applications, ultimately it's a very difficult problem to automatically answer questions like "does this look right?" and "Is this easy to use?". Those types of questions almost always have to be answered by a human trained to answer such questions.

Performance tests are almost exclusively automated, though any easy way to do performance testing is simply to time your automated system tests and watch the trends, and also watch system metrics such as CPU and memory utilization while your system tests are running. This isn't an ideal performance testing strategy, but it's good enough if you're just starting out.

So, to get started with testing, see if there is a unit testing framework already available for your language. You can then quickly come up with a body of tests for the individual units. You can then start looking for what are commonly called "testing frameworks" for the system tests. There are many, many frameworks to choose from. There is no "best", so don't get too caught up in finding the perfect tool. Pick any tool that works for your language and start using it.

Answer 2

Fundamentally there are these things going on:

1. Understand what the software is supposed to do.
2. Decide how to verify that it does.
3. Agree your test strategy with the stake-holders: there should be people who care about whether you are testing the right things, they need to have confidence that you are doing so.
4. Perform the verification
5. Report the results, accurately, in enough detail to allow problems to be fixed

The details depend upon the nature of the software. For example what would you do if the software didn't have a UI? Or if it has a UI, there are almost certain to be other things (eg. modules which load data from external systems) you need to test too, what proportion of time will you spend on those?

There's a strong likelihood that some parts of the testing you decide is appropriate will need to be repeated as new releases of the software are made. You can make a distinction between "testing" and the subset which is "re-checking" and there may be value in automating the re-checking aspects.

One thing to bear in mind: I'm very suspicious of an attempt to reduce testing to a simple set of "steps". You might look at contextual testing for an explanation.