DUBYAB

 Profile Answers by DUBYAB 

• Nov 14th, 2008

 

What have you done to decompose functional requirements to bring to the testing teams? (This should be answered in a way to explain the process that was involved also).

I believe, 'decomposing' a functional requirement means making it testable.  You need to capture the inputs and the outputs that are derived prior to or from each function.  Here is an example:
Test Case - Post a Response to an Interview Question
1. The user selects the 'reply' button.
2. The system returns the 'Post Your Answer' dialog box.
3. The user enters there text in the 'Answer' section of the dialog box.
4. The user selects the check box "Add this question to my Subscribed Questions (?)" and or check box "Send me an email when a new answer is posted. (?)" (see test case XX for this functionality)
5. The user selects the 'Submit' button.
6. The system displays the 'Your response was submitted page'.
7. The user selects 'Return to list of interview questions', 'back button', or 'forum'. (see test case xx for this functionality.
8. Test case ends when the user is returned to the screen where their response is successfully posted to the interview question.

jaskanwar

 Profile Answers by jaskanwar 

• Jun 11th, 2009

 

Apart from the answers mentioned above, I guess a detailed FSD(Functional Spec document) or FRS/MRD etc should be detailed enough to breakdown each functional spec in its lowest form and should explain each scenario.

The FSD can be passed to the tester and he could refer to it to cover each and every possible scenario for testing.