Software testing has never been as difficult as software development !!!
I would prefer not to get into discussing the outlined statement above. Let us focus on something that adds more value to the time we spent on this portal. Managing testing with optimum utilization of the test management system is the primary goal to touch-base on the article outlined below.
When we talk of designing the test cases in a system, there are some basic parameters that is offered by various tools which enhances the overall ease of managing the work. Let us discuss on some aspects that will add more to what we in general keep doing. We will not discuss the basic ones like title , steps description, automation status etc as we all know and are adept in managing them.
In addition to what we have we should have below outlined parameters also in a manner that can be better than is mentioned below. Let us visit them one by one. Why we need these additional parameters and in what type of situation , we can en cash on the opportunity that will be offered by these additional parameters.
1. Iteration : This parameter provides us the opportunity to segregate the test cases based on their implementation in the product as a feature. We have our software developed in multiple cycles and this is one aspect which helps us to track the test case creation and first time inception in the system. And gradually with the progress of the iteration we end up with test cases belonging to various iteration. Any test case can belong to just one iteration and that property will help us to identify the feature - implementation - iteration as well.
Iteration 1
Iteration 2
Iteration 3
2. Functional Area : This property enables us to identify the feature to which a test case belong to. We may have multiple features implemented within a software. let us take an example from e-commerce domain, The primary features in this case would be the various business segments such as Apparels, Housing decors, Electrical appliances etc. This an ideal property within a test case to have the tree structure. Just because implementation of such big features may not be in full in a particular iteration. So how to track such timelines ? Here is the solution that the tree structure will provide . Apparel can be broke into multiple like women , men, children, and so on and so forth . This depth can go to any level. Here one thing we must have at the back of our mind , a single feature should not flow into multiple iteration, as that results in multiple complications in terms of reporting and traceability. Simple rule of thumb will be - "A single iteration can have multiple Functional areas but its vice - versa is not possible" .
Payment
Authentication/Authorization
Reports
Usability
3. Test Case Category :
BAT [build acceptance test]
Sprint Related
Regression :
High Impact Breadth - wise
Medium Impact Breadth - wise
Low Impact Breadth - wise
4. Priority :
P1 - Critical Path Business Scenarios
Important to reject/accept a build.
P2 - Average Path Business Scenarios
Important to decide on pre - scheduling of any interim drop
P3 - Low Path Business Scenarios
Non - functional aspects of the system under test
Will continue it once I have had some sleep. Too tired to type. Though thinking continues to make it more interesting !!
I would prefer not to get into discussing the outlined statement above. Let us focus on something that adds more value to the time we spent on this portal. Managing testing with optimum utilization of the test management system is the primary goal to touch-base on the article outlined below.
When we talk of designing the test cases in a system, there are some basic parameters that is offered by various tools which enhances the overall ease of managing the work. Let us discuss on some aspects that will add more to what we in general keep doing. We will not discuss the basic ones like title , steps description, automation status etc as we all know and are adept in managing them.
In addition to what we have we should have below outlined parameters also in a manner that can be better than is mentioned below. Let us visit them one by one. Why we need these additional parameters and in what type of situation , we can en cash on the opportunity that will be offered by these additional parameters.
1. Iteration : This parameter provides us the opportunity to segregate the test cases based on their implementation in the product as a feature. We have our software developed in multiple cycles and this is one aspect which helps us to track the test case creation and first time inception in the system. And gradually with the progress of the iteration we end up with test cases belonging to various iteration. Any test case can belong to just one iteration and that property will help us to identify the feature - implementation - iteration as well.
Iteration 1
Iteration 2
Iteration 3
2. Functional Area : This property enables us to identify the feature to which a test case belong to. We may have multiple features implemented within a software. let us take an example from e-commerce domain, The primary features in this case would be the various business segments such as Apparels, Housing decors, Electrical appliances etc. This an ideal property within a test case to have the tree structure. Just because implementation of such big features may not be in full in a particular iteration. So how to track such timelines ? Here is the solution that the tree structure will provide . Apparel can be broke into multiple like women , men, children, and so on and so forth . This depth can go to any level. Here one thing we must have at the back of our mind , a single feature should not flow into multiple iteration, as that results in multiple complications in terms of reporting and traceability. Simple rule of thumb will be - "A single iteration can have multiple Functional areas but its vice - versa is not possible" .
Payment
Authentication/Authorization
Reports
Usability
3. Test Case Category :
BAT [build acceptance test]
Sprint Related
Regression :
High Impact Breadth - wise
Medium Impact Breadth - wise
Low Impact Breadth - wise
4. Priority :
P1 - Critical Path Business Scenarios
Important to reject/accept a build.
P2 - Average Path Business Scenarios
Important to decide on pre - scheduling of any interim drop
P3 - Low Path Business Scenarios
Non - functional aspects of the system under test
Will continue it once I have had some sleep. Too tired to type. Though thinking continues to make it more interesting !!
إرسال تعليق