Friday, August 10, 2012
A conversation between an Enterprise Architect and Quality Assurance Team
Don't ever make the mistake in asking a basic question like what is a test case...
Don't you hate when you talk to a team and get different answers to the same question? Some believe that a test case is a set of inputs with expected results. This aligns the notion that a test case is a tangible artifact that can be used by project managers to check the box that something has been delivered. Others believe that a test case is an instance of a test idea and that the concern for artifacts is a second class concern. I find the distinctions intriguing because my own set of thinking tends to align more with the later over the former.
The first model is useful when you have offshore resources and you have the need to count and track things. This aligns well with outsourcing firms that throw lots of bodies at QA and essentially leverage them like they are script monkeys. Scope of testing is well-known and can be accurately estimated to completion. Yet, if you think about it, executing test cases doesn't imply that the application has been thoroughly tested.
The later is more aligned with a philosophy I hold which is the need to shift from "activities" toward "outcomes". The former has a built-in implication that you are going to ignore the risk of testing something else or finding information outside of the scope of the test case. Depending on how this is manifested, this could result in finding more bugs and having a QA resource being chastised for doing so. So much for the notion of quality assurance.
| | View blog reactionsDon't you hate when you talk to a team and get different answers to the same question? Some believe that a test case is a set of inputs with expected results. This aligns the notion that a test case is a tangible artifact that can be used by project managers to check the box that something has been delivered. Others believe that a test case is an instance of a test idea and that the concern for artifacts is a second class concern. I find the distinctions intriguing because my own set of thinking tends to align more with the later over the former.
The first model is useful when you have offshore resources and you have the need to count and track things. This aligns well with outsourcing firms that throw lots of bodies at QA and essentially leverage them like they are script monkeys. Scope of testing is well-known and can be accurately estimated to completion. Yet, if you think about it, executing test cases doesn't imply that the application has been thoroughly tested.
The later is more aligned with a philosophy I hold which is the need to shift from "activities" toward "outcomes". The former has a built-in implication that you are going to ignore the risk of testing something else or finding information outside of the scope of the test case. Depending on how this is manifested, this could result in finding more bugs and having a QA resource being chastised for doing so. So much for the notion of quality assurance.
