Alternative Ways of software Testing

If there is absolutely no time for you to document your system, do consider these other approaches of testing

User/Acceptance Testing

User Testing is used to identify issues with user acceptability of the system. The most trivial to the most complicated defects can be reported here. It is also possibly the best way to determine how well people interact with the system. Resources used are minimal and potentially requires no prior functional or system knowledge. In fact the more unknown a user is to the system, the more preferred he is for user testing. A regressive form of user testing can help uncover some defects in the high-risk areas.

Random Testing

Random Testing has no rules. The tester is free to do what he pleases and as he seems fit. The system will benefit however, if the tester is functionally aware of the domain and has a basic understanding of business requirements. It will prevent reporting of unnecessary defects. A variation of random testing – called as Monte Carlo simulation, which is described as generation of values for uncertain variables over and over to simulate a model can also be used. This can be used for systems, which have large variation in input data of the numbers or data kind.

Strategy for designing the Test Cases and Test Scenario’s:

The following steps typically speak of a strategy for designing the Test Case(s) and Test Scenario(s) from the Use Case document.

Step 1: Identify the module / class / function for which the Use Case belongs.

Step 2: Identify the functionality of the Use Case with respect to the overall functionality of the system.

Step 4: Identify the Functional Points in the Use Case and make a Functional Point Document.

Step 3: Identify the Actors involved in the Use Case.

Step 4: Identify if the Use Case “Extends” or “Uses” any other Use Case.

Step 5: Identify the pre-conditions.

Step 6: Understand the Typical Flow of the Use Case.

Step 7: Understand the Alternate Flow of the Use Case.

Step 8: Identify the Business Rule’s.

Step 9: Check for any post-conditions and special requirements.

Step 10: Document Test Cases for the Typical Flow (include any actions made in the alternate flow if applicable).

Step 11: Document the Test Cases for Business Rules.

Step 12: Document Test Cases for Alternate Flow.

Step 13: Finally, identify the main functionality of the Use Case and document a complete positive end-to-end scenario.

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