WRITING SOFTWARE TEST CASES

Test cases have traditionally been used to test any system – software or otherwise. The test case may transform into a checklist, a comprehensive step by step guideline on information displayed by the system, or a simple black box scenario. In any case, a test case is a pure representation of what the system should and shouldn’t do.

A functional specification document on the other hand is documented the way the user would want the system to be or how he perceives the system to be. A typical functional system is dominated by user understandable language, screen shots and behavior. Business rules may also be documented as part of the document.

One can argue that it may be easier to test from a functional/requirements specification document than creating a separate test case document – since the basis of a test case document is the functional specification document.

However there are several known pitfalls with this approach. Some of them are -

  1. Test scenario build up is difficult

  2. Incomplete documentation of flows

  3. Unit level approach rather than system level approach.

  4. Business rules may not be apparent, though they are documented.

Typically a functional specification is the basis of developing test cases with user flows, business rules and special conditions thrown in.

Test cases without requirements specifications:

On the fly development, pressurized deadlines, changing user requirements, legacy systems, large systems, varied requirements and many more are known influences for many a project manager to discard or not update the functional specification document. While a project manager/requirements manager may be aware of the system requirements, this can cause havoc for an independent test team.

Dealing with a system that needs to be tested without functional specifications requires good planning, smart understanding and good documentation - lack of which caused the problem in the first place.

Before I begin describing some ways in which you can tackle the problem – here are a few questions you could be asking yourself

1. What type of testing will be done on the system– unit / functional / performance / regression?

2. Is it a maintenance project or is it a new product?

3. From where have the developers achieved their understanding of the system?

4. Is there any kind of documentation other than functional specification?

5. Is there a business analyst or domain knowledge expert available?

6. Is an end user available?

7. Is there a priority on any part of the functionality of the system?

8. Are there known high-risk areas?

9. What is the level of expertise of the development team and the testing team?

10. Are there any domain experts within your test team?

11. Are there any known skill sets in your team?

12. Are you considering manual/automated testing?

RELATED POST

UNIT TESTING PART ONE

UNIT TESTING PART TWO

UNIT TESTING PART THREE

GUI TESTING

WINDOWS COMPLIANCE GUI TESTING PART ONE

WINDOWS COMPLIANCE GUI TESTING PART TWO

WINDOWS COMPLIANCE GUI TESTING PART THREE

WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING

WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING

WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

No comments:

Post a Comment