Re: How to Write Test Cases for an ERP project ??

I am working as a software tester in a private firm.I am assigned the duty of writing test cases for an ERP project.Its my assessment time so please help me to find a better solution.

Better than what?

Should i write test cases for functionality and GUI based separately or as a single one???

Simplifying the test case is better than making the test more complex;
testing one factor at a time is better than testing many factors at a
time... unless you're testing the relationships between the factors, or
unless your time is constrained, or... In short, there is no hard and
fast answer to this question. The answer depends on your context. The
easiest way to deal with the problem is to consult with your boss. You
may look smarter if you reason out the advantages and disadvantages of
each approach first; what do you gain, and what to you lose? Then
bring those alternatives to developers, other testers, and so on, and
ask for feedback. Summarize, and bring it to your boss.

One bad strategy would be to take context-free advice (like this, and
like the other messages on this thread) from a newsgroup and to treat
it as infallible.

Since the manufacture prices and vendors are changing, how will we include Test data in test cases???

Whatever data you use is test data. I think you're asking "how can we
make our test data variable?" One way to do it is to avoid specifying
the data too specifically, and simply let testers insert variable but
plausible data; another way is to have the test get fresh or changing
data from a database or spread*** or text file that you can modify.

What are the things that we should look into before writing test cases???

Here are the things I think you should look into before writing test
cases.

0) Testing. From your message, I suspect that there is rather a lot
you still need to learn about testing. You apparently understand that
you need to look good to the boss at assessment time; that's a good
start. The next step is to recognize that it's important to be of
service to the project the rest of the time.
1) Whether it's worth it to write test cases before you test. Often it
is. Often it isn't. Some of your tests should be automated (in which
case specifying the test case will help as you script it). Some tests
should not be automated, but should be described in some form before
you test (in which case specifying the test case may help). Some tests
should be neither automated nor described in advance, since operating
the product will give you feedback that you may want to investigate
right away (in this case you can't predict what the feedback will be,
so writing a test case in advance would be would be impossible).
2) Risk.
3) Oracles--the principles or mechanisms by which you will recognize
problems.
4) Coverage--the set of mental models that you want to use to test the
software, and the extent to which you would like to test according to
each one.
5) Quality criteria: to what extent (at least) the following criteria
matter to the project owner: capability (or functionality),
reliability, usability, scalability, security, performance,
installability, compatibility, supportability, maintainability,
testability, portatbility, and localizability.

You can read more about this stuff here:
http://www.developsense.com/articles

and here: http://www.satisfice.com

---Michael B.

.