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 -
Test scenario build up is difficult
Incomplete documentation of flows
Unit level approach rather than system level approach.
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