Well, my first post was about defining End-to-End (ETE) testing.
Next question will be what is the base document for defining ETE test cases?Isn't it?
Name of the base document can be anything, BRD (Business Requirement Document) or SRS (Software Requirement Specification) or JRD (Joint Requirement Document), but the document should contain business requirements (BRs). BRs are requirements collected from multiple sources, in multiple ways. Sources can be end user who can explain he requirements and the underlying needs, can be sponsor or internal client, can be key stakeholders listed in stakeholder register. BRs can be collection of approved Change Requests (CRs) from multiple past projects or for example, BR can essay an actual required fix of a Severity1 defect found in past project. There is a possibility that this particular project was deployed and went live with some work-around of the defect, after managing "Go" vote from client.
Requirement gathering techniques are also multiple:
1. Interviews
2. Workshops
3. Focus groups
4. Brain storming
5. Survey
6. Observations
7. Prototypes etc.
Normally BRs are written in non-technical language. BR document may contain Customer Service Scenarios (CSS). BRs are broken down into more technical CSSs. The CSSs cover multiple applications, hence multiple interfaces of many sub-systems.
In short, ETE test cases should be written based on a requirement document that captures complete business requirements (i.e. functionality to be deployed across multiple sub-systems or applications) from start to finish. Since CSSs are more technically written, ETE testers may find it convenient to base their test cases on CSSs.
Please leave your comments/questions. I shall try to answer you all.
Next question will be what is the base document for defining ETE test cases?Isn't it?
Name of the base document can be anything, BRD (Business Requirement Document) or SRS (Software Requirement Specification) or JRD (Joint Requirement Document), but the document should contain business requirements (BRs). BRs are requirements collected from multiple sources, in multiple ways. Sources can be end user who can explain he requirements and the underlying needs, can be sponsor or internal client, can be key stakeholders listed in stakeholder register. BRs can be collection of approved Change Requests (CRs) from multiple past projects or for example, BR can essay an actual required fix of a Severity1 defect found in past project. There is a possibility that this particular project was deployed and went live with some work-around of the defect, after managing "Go" vote from client.
Requirement gathering techniques are also multiple:
1. Interviews
2. Workshops
3. Focus groups
4. Brain storming
5. Survey
6. Observations
7. Prototypes etc.
Normally BRs are written in non-technical language. BR document may contain Customer Service Scenarios (CSS). BRs are broken down into more technical CSSs. The CSSs cover multiple applications, hence multiple interfaces of many sub-systems.
In short, ETE test cases should be written based on a requirement document that captures complete business requirements (i.e. functionality to be deployed across multiple sub-systems or applications) from start to finish. Since CSSs are more technically written, ETE testers may find it convenient to base their test cases on CSSs.
Please leave your comments/questions. I shall try to answer you all.
No comments:
Post a Comment