How can we decide which testing method can be used?

Question

i have project in .net , i want to test it.

But i dont know anything about testing and its method.

how can i go ahead with testing.

which method i

Answer 1

There is no "right" or "wrong" in testing. Testing is an art and what you should choose and how well it works out for you depends a lot from project to project and your experience.

But as a professional Tester Expert my suggestion is that you have a healthy mix of automated and manual testing.

AUTOMATED TESTING

• Unit Testing
  Use NUnit to test your classes, functions and interaction between them.
  http://www.nunit.org/index.php

• Automated Functional Testing
  If it's possible you should automate a lot of the functional testing. Some frame works have functional testing built into them. Otherwise you have to use a tool for it. If you are developing web sites/applications you might want to look at Selenium.
  http://www.peterkrantz.com/2005/selenium-for-aspnet/

• Continuous Integration
  Use CI to make sure all your automated tests run every time someone in your team makes a commit to the project.
  http://martinfowler.com/articles/continuousIntegration.html

MANUAL TESTING
As much as I love automated testing it is, IMHO, not a substitute for manual testing. The main reason being that an automated can only do what it is told and only verify what it has been informed to view as pass/fail. A human can use it's intelligence to find faults and raise questions that appear while testing something else.

• Exploratory Testing
  ET is a very low cost and effective way to find defects in a project. It take advantage of the intelligence of a human being and a teaches the testers/developers more about the project than any other testing technique i know of. Doing an ET session aimed at every feature deployed in the test environment is not only an effective way to find problems fast, but also a good way to learn and fun!
  http://www.satisfice.com/articles/et-article.pdf

Answer 2

If you are using .Net, I'd recommend checking out NUnit. It's a great testing framework to use.

As far as learning about the "testing method", there are many different ways to test an application. When using a tool like NUnit, for example, you are writing automated tests which run without user interaction. In these types of tests, you typically write tests for each of the public methods in your application, and you ensure that given known inputs, these methods produce the expected outputs. Over time as the application changes (via enhancements, bug fixes, etc.) you have a core set of tests that you can re-run to ensure nothing breaks as a result of the changes. You can also do failure testing to ensure that given an invalid set of inputs to a method, it throws the proper exceptions, etc.

Besides automated testing with a tool like NUnit, it's also important to ensure that your end users test the product. "End users" here could be a Quality Assurance group in your company, or it could be the actual customer. The point is that you need to ensure that someone actually uses your application to make sure it works as expected, because no matter how good the automated tests are, there will still be many things you won't think of that your users will discover. One way to approach this type of testing is to write test scenarios, and have your users execute them to make sure the scenario results in the correct behavior.

I think the best testing approach combines both of the above, namely automated testing and user testing (with documented test scenarios).

Answer 3

Since it is not clear about the scale of the project you have, all you need to do is make sure:

1. Your tests are trustworthy - you should know they are telling u the truth.
2. Repeatable
3. Consistent - If you repeat test with same test data it should provide same output.
4. Proves you are covering all the problem areas.

To get this you can use:

1. Standard way : NUnit, MbUnit (myFav) or xUnit (havent got around to working with it) or MSTest
2. Quick and Dirty : Console app (not cool, not so flexible)