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