If I want to test that my flight simulator acts like an aeroplane and nothing else then I agree with you, I need to know what an aeroplane does.
However, testing is far more than this "happy path" scenario. I also want to know that it doesn't turn into a teapot if I fly straight upwards and turn the after burner off. Proving these aspects does not require any knowledge of what an aeroplane is like at all, just an understand the service contract. i.e. an ability to look for critical data points.
Generating a good test suite requires someone (a PO) with domain knowledge and someone domain agnostic so that happy and unhappy cases are caught and no-one finds themselves flying a teapot.
I wonder we have to use "agnostic" instead of "ignorant" in programming discussions. Do you really want someone who denies the possibility of knowing whether there's a god in the domain, or just someone who doesn't know much about the domain?
I agree with Gareth. You need knowledge about the subject under test. If you don't have at least a good understanding of the subject, how do you want to come up with great destructive testing ideas. Besides the happy path, testing has to cover various not so good situations (e.g. What are the possible error situations that can occur when using WiFi?). In addition you need also someone good in just plain destructive testing. This is the kind of person who first jumps several times on the keybord, puts garbage in an email input field, and was supposedly born on dates like 2/30/2011, 13/1/1974 or 1.1.1850.
So in part I agree with Dave that you need to test more than just the happy paths. But you need knowledge to come up with the not so good path (like someone trying to create an account on google who is not 13 yet), other wise your app will turn into a teapot, even though I think they will rather turn into a wale or a petunia with a limited lifespan.
The knowledge needed for not so happy path is subject knowledge and general testing knowledge. The general testing knowledge can also be labeled as technology knowledge so that you can test for instances the weaknesses off the UI framework or possible issues in a client server based environment (e.g. two clients changing the same record at the same time).
I disagree.
ReplyDeleteIf I want to test that my flight simulator acts like an aeroplane and nothing else then I agree with you, I need to know what an aeroplane does.
However, testing is far more than this "happy path" scenario. I also want to know that it doesn't turn into a teapot if I fly straight upwards and turn the after burner off. Proving these aspects does not require any knowledge of what an aeroplane is like at all, just an understand the service contract. i.e. an ability to look for critical data points.
Generating a good test suite requires someone (a PO) with domain knowledge and someone domain agnostic so that happy and unhappy cases are caught and no-one finds themselves flying a teapot.
Cheers
Dave
I wonder we have to use "agnostic" instead of "ignorant" in programming discussions. Do you really want someone who denies the possibility of knowing whether there's a god in the domain, or just someone who doesn't know much about the domain?
ReplyDeleteIt is very important to follow correct approach for testing. Initially we have to select correct way for our project.
ReplyDeleteI agree with Gareth. You need knowledge about the subject under test. If you don't have at least a good understanding of the subject, how do you want to come up with great destructive testing ideas. Besides the happy path, testing has to cover various not so good situations (e.g. What are the possible error situations that can occur when using WiFi?). In addition you need also someone good in just plain destructive testing. This is the kind of person who first jumps several times on the keybord, puts garbage in an email input field, and was supposedly born on dates like 2/30/2011, 13/1/1974 or 1.1.1850.
ReplyDeleteSo in part I agree with Dave that you need to test more than just the happy paths. But you need knowledge to come up with the not so good path (like someone trying to create an account on google who is not 13 yet), other wise your app will turn into a teapot, even though I think they will rather turn into a wale or a petunia with a limited lifespan.
The knowledge needed for not so happy path is subject knowledge and general testing knowledge. The general testing knowledge can also be labeled as technology knowledge so that you can test for instances the weaknesses off the UI framework or possible issues in a client server based environment (e.g. two clients changing the same record at the same time).
Peter