The theoretical approach will ensure that you have good comprehensive documents for the system at the end of the process.
What are Use Cases:
Use case is a description of the interaction between the user and the system. This can also be described as a way of using specific part of application’s functionality. A
complete collection of use cases describes all the ways that a user can manipulate a
software system.Use cases are a very powerful method of describing requirements.
They form basis for
- Software Design
- Test Cases
- User documentation
- GUI design
Use cases are written during the requirement phase of the software project. Use cases are written in a plain English language that user can easily understand. Business analysts that have been specially trained to develop use cases should write them. Rational Rose is a tool that can be effectively used to model and also write use cases. However most use cases are written in MSWord as everyone can easily access them.
Traditionally use cases have been used for requirement gathering. There has been a considerable shift to use them for testing, primarily because they model user role-play, movement, access rights and the interaction of one module to another – which is essentially what a test plan aims to do.
A use case defines the following –
1. Primary actor or actors
3. Scenarios used
4. Conditions under which a scenario occurs
5. Scenario result (goal delivery or failure)
6. Alternative scenarios or flows
The advantage of this approach is that you have two ready things in your hand
1. Documented system functionality
2. Evident module interaction
The development or creation of the use case will not be an easy task. Typical way to develop a use case is to pick up the system screen by screen or module wise and talk to the concerned developers or business analysts. Users can also be brought into the discussion at a later stage. Most users will give you valuable inputs to the type of data they input to the system. That in turn can give you an insight to the flows of the system.
Exemplary questions that you can ask users/developers are:
1. Inputs to a screen
2. User movements/warnings on a screen
3. Access rights to screen(s) or modules.
4. Access to screen(s) and exits from screen(s)
5. Database checks/updates.
6. Outputs from a screen
7. Alternative inputs or exits from the screen(s).
You can screen these questions or add some based on the testing you will be conducting for the system. For e.g. If you are carrying out GUI testing, you could do well if you add questions like length of the text box (this question could be answered well by a developer, rather than a user or a business analyst). If you are doing system testing, you could probably cut out the question on database check or updates. On the other hand, if you are doing system testing as part of a technology migration, you should enforce that database updates are verified.
UNIT TESTING PART ONE
UNIT TESTING PART TWO
UNIT TESTING PART THREE
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
TESTING CONDITIONS PART ONE
TESTING CONDITIONS PART TWO
TESTING CONDITIONS PART THREE
TESTING CONDITIONS PART FOUR
SPECIFIC FIELD 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