Hi All,

Currently, am working as a Requirements Analyst for a project and part of my responsibilities is to review test cases created by SQC engineers to ensure that the requirements are correctly interpreted and the test cases reflect the actual behavior of the system. But since this is my first experience with the concept of test cases, am so confused how to decide which are good test cases and which are not! I am so confused what is the meaning of a test case? What should be in the test case and what is not necessary? And what is the use of test cases since at the end we will do actual testing!!!

In brief, this project is composed of ~ 90% service (web services and backend service) and ~ 10% of GUI, and of course most of the test cases focus of the GUI neglecting the core service L . Moreover, in our company, we do only blackbox testing, so no automated tools or testing scripts!

Recently I heard about the concepts of Catalog-based testing, boundary-based testing and other techniques for testing. I don’t know if this may help to optimize the efforts used in generating test cases.

Really am so confused!!! I'll be so grateful if you can help me and I do appreciate any examples or related resources.

Thanx in advance.

Also thank you all for this great effort, which I find so so so useful as a newcomer system analyst.

Hi:

You probably need to be focused on systems-level test cases (otherwise known as black box test cases).  In doing black box testing, the tester treats the system as a series of  interconnected black boxes.    It is called black box testing because the tester does not know about what goes on inside of the box (i.e., he/she does not look at the code).  Test case:   Specified inputs to and expected outputs from the black box.

Just like a data flow diagram:  Inputs and outputs from functions (black boxes).   And just like in a data flow diagram (i.e., requirements specification) your goal is to get an understanding of essential functions and then use that as a framwork from which to expand into the implementation specific functionality.

If you do it this way then:  Functional requirement:  The system shall do X.      Systems-level test case:   Verify that the system does X.

 Tony

 Dimz

I am no testing expert but I'll share my opinion anyway 

In my experience, there are two types of testing which you are describing (unless I've misunderstood) which is system testing and user or business acceptance testing.

The former tends to be dumb in that they take the system specifications (use cases, perhaps) and ensure that the system behaves exactly as described. They should test as a minumum all of the positive scenarios to prove the system behaves in the way described.Depending on time, they should also test negative scenarios which is to prove all of the permutations that are NOT mentioned in the system spec also behave as described.

For example, when considering customers, there may be many variations which have no impact on the part of the system under test e.g. gender, age, address, length of time as a customer. In theory, you could test different ages, both genders etc but, in practice, the tester should use his/her judgement and test a limited subset.

The user acceptance testing will be more interested in the underlying business processes and what will happen in the real world. In this case, they should test end to end scenarios which should cover the processes you are discussing.

So, in answer to your question, if they are in charge of system testing, they should be able to test exactly what you have specified and prove that this works as defined. If this is not defined clearly enough then you have a challenge which can only be overcome by communication and test script reviews (which is what you appear to be doing).

If they are in charge of user acceptance testing then they should have experience of the business and either team members have direct knowledge/experience of the business or have access to business people.

I have recently been in your position regarding system testing of a complex system with many business rules and a complicated underlying framework. The only solution we found was frequent communication and making yourself available to review test scripts. provide clarification and, ultmately, undertaking some focussed testing to improve confidence levels.

Sorry for the rambling reply - I hope this was helpful

Alex