As I am leading a small QA team on an Open Source company, I have the task of defining the QA Process. The formal QA cycles, and process won't work here.
We have two major teams, one is working on the open source product, and the other one working on customizations of the open source product. The Open Source team is more agile, while the customization team being less agile. We have projects for which presales and estimation done in 15 minutes, development and testing finish in one day. The largest project so far is two and a half developers working 3 months together, and two testers working both on manual testing as well as automation of basic test cases.
Writing test cases is not in the business model. We send the feature specification to customers and get it signed off before the project starts. The practice of signing the test case document is not there. I have spoken to the project managers, and none want the QA team to write test cases to their products. Since test cases are not signed off, they don't carry much business value for project managers. For a project that runs one month, they don't want the QA team writing test cases for one week.
Following are some of the reasons why test cases don't provide a good solution to the company.
1. Specs are not written in a way so that business scenarios are easily visible. Rather it describes a small chunk of functionality. This makes it harder to write test cases before the release is made.
2. Test cases are useful if the same set of test cases are executed in multiple cycles. This, usually, is not the case. A story/functionality, is usually tested thoroughly in only one cycle. And there will be defect verifications in one or two more cycles and that's it. This reduces the value for the test cases a lot, and people prefer ad hoc.
I find it harder to define a testing process where test cases are not practiced. Since testing then goes undocumented, it is harder to monitor and control it.
I know that Agile teams don't rely on formal test cases, and they have a different view on testing. I am currently going through "Agile Testing" by Lisa Crispin, hoping that it will shed some light to the problem.
Today, I found something interesting in the book, which I would like to share with the rest of the world.
We have two major teams, one is working on the open source product, and the other one working on customizations of the open source product. The Open Source team is more agile, while the customization team being less agile. We have projects for which presales and estimation done in 15 minutes, development and testing finish in one day. The largest project so far is two and a half developers working 3 months together, and two testers working both on manual testing as well as automation of basic test cases.
Writing test cases is not in the business model. We send the feature specification to customers and get it signed off before the project starts. The practice of signing the test case document is not there. I have spoken to the project managers, and none want the QA team to write test cases to their products. Since test cases are not signed off, they don't carry much business value for project managers. For a project that runs one month, they don't want the QA team writing test cases for one week.
Following are some of the reasons why test cases don't provide a good solution to the company.
1. Specs are not written in a way so that business scenarios are easily visible. Rather it describes a small chunk of functionality. This makes it harder to write test cases before the release is made.
2. Test cases are useful if the same set of test cases are executed in multiple cycles. This, usually, is not the case. A story/functionality, is usually tested thoroughly in only one cycle. And there will be defect verifications in one or two more cycles and that's it. This reduces the value for the test cases a lot, and people prefer ad hoc.
I find it harder to define a testing process where test cases are not practiced. Since testing then goes undocumented, it is harder to monitor and control it.
I know that Agile teams don't rely on formal test cases, and they have a different view on testing. I am currently going through "Agile Testing" by Lisa Crispin, hoping that it will shed some light to the problem.
Today, I found something interesting in the book, which I would like to share with the rest of the world.
Agile testing doesn’t just mean testing on an agile project. Some testing approaches, such as exploratory testing, are inherently agile, whether it’s done an agile project or not. Testing an application with a plan to learn about it as you go, and letting that information guide your testing, is in line with valuing working software and responding to change.
No comments:
Post a Comment