How to Write Test Cases for an ERP project ?? - Software-Testing

srikant wrote:

> 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.

At this point I don't know which is more important, speeding up development
or making you look good. Many people, in your role, have slowed down
development and looked quite good. You need to focus on what results are
satisfying your managers. Frequently show them intermediate results, to make
sure you are closing on both goals.

> The problems faced are :
>
> Should i write test cases for functionality and GUI based separately or
> as a single one???

Your bosses should know that all tests should be automated, and that they
must help you and the developers provide hooks for automation.

Most tests should be functional, below the GUI. This requires back-doors
into the code. If you don't have them, and are not allowed to ask for them,
then focus on looking good!

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

Put such data into a spreadsheet. These come with simple systems, like an
ADO database hookup, to read out the data and use it in tests.

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

Where are the bugs? What features are the developers working on right now?

> Please help me...ASAP.

Others here will doubtless supply interesting variations on my points.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

>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 spreadsheet 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.