Failure to Test… But Big Success…

I set up the Black Magic trap to begin testing this past weekend…

However, there was really no way to test the trap that day.  The bait was still around until the end of the approximately 8 hour excursion, but the trap had no bites.  The wind never triggered a “fake flag”, but my other traps do not either.  So, the “never get another wind flag again” claim could have been a suggested “pass”, because there was a bit of a breeze, but I guess I am becoming a “super user”, and that had no effect on my personal testing…

My line was different on that trap than on others, and so was my hook, so I have to go on to a better test…

I think I will try to test what happens when I find a honey hole, and if that hole contains one of my typical traps, I will need to change it to this one.  This test will require that I put the same fishing line and the same hook as I did on the other traps I set up… as well as the same bait.  I will have to start to set up this test prior to my next trip out….  I will have to put on the same line and the same hook… and ultimately, use the same bait.

This part of testing is something I am not sure many in the “stakeholder” group understand.  Sometimes the set up and planning of one test can take some considerable time, but when the defect/bug/test is written, it seems so simple.  "Set up" time can be longer than the actual "test time" in many situations... In fact, maintenance of virtual machines and test equipment is seldom considered in the projects I have been on... they just seem to be magically "there"... They are not.  With the amount of scenarios that can be tested for any individual feature in an application/system/product under test, it is near impossible to be ready to re-test immediately when requested... and nearly impossible to explain this to anyone outside of testing... 

Sometimes a test set up is so slim that I hate to even accrue time for it.  But, sometimes the set up takes more time than running the actual test itself.  “When” and “if” play a large role in these tests… and they both require time that exceeds the actual test.   This is where the old “how long do you need to test this” comes into play and makes you wonder if you can ever explain what you do as a tester... 

 I have set this particular project to be my winter test project.  I am really hoping to either pass or fail this trap… at the same time I know I have many scenarios to test it with.  Luck/bait/location/line/hook/etc. will all play a role in testing this “tool”.   One season is all I have to test.  I have the project… and the time frame.   And it is a bit of a crunch because I cannot ice fish every day...  on every available body of water… with every available species of fish, with every available bait type...  So the tests have to be “good enough” to pass inspection of the stakeholder(s), who in this case… is me.

As in every project I have been on, I have come out with some great stuff/knowledge… even if I did not accomplish what I set out to do within the test cycle/period...

 In the case of this project, while I failed to really pull of a good test on this particular trap… my 8-year-old daughter caught the biggest land-locked salmon of our group that day… and that is one heck of a Big Success in my book…