Am I a context driven tester?
This morning I was listening to testing bias podcast on schools of testing and I started wondering what kind of a tester I am and what kind of testing I am doing in my current projects. The five languages/tribes/schools that @andytinkham talks about are here
- Factory/Standard Consistency vs. chaos
- Analytic Correctness vs. randomness
- Context-Driven Context awareness vs. mindlessness
- Quality/Control Process vs. cowboy-ism
- Agile Whole-team quality responsibility vs. quality as afterthought
Though context driven testing seems appealing on the surface, I have heard of this term this month and I am still not sure if I subscribe to this school of thought yet. Also the debate around this seesm pretty political. So, lets try to do this by process of elimination.
First, I am not a Analytic/Formal tester, I work in software industry not in acadamia. At best the only formal thing I have written for my testing plans is a flow chart or a mind map but never any equations or statistics.
Second, I am not a factory/standards oriented tester. I do not like writing a lot of test cases and hate executing those for every release. I do not have any software testing certificates, nor plan on getting one. Even if these tests are automated, I question the value of thousands of tests that are incapable of finding customer problems.
Third, quality assurance — i.e testers protect users from lazy developers by enforcing process in SDLC. I have drunk this flavor of Koo-Aid for a while, in job interviews I have said “I love being the user advocate and driving quality”. But there are many reasons why this won’t work for me
- I am typically outnumbered by devs 7:1 or more. If anyone isn’t following a process, that’s me the tester.
- I am slowly realizing that not every problem/bug needs to be filed, let alone fixed.
- Customer perspective is not for one person on the team but for everyone
Fourth, Agile testing — my favorite. Where I always wanted to be and strive to be. It places heavy emphasis on test automation and unit testing. But, for the last 4 years there has been not even one project where there adequete unit tests. Forget 100% coverage, most of these projects are less than 50% and for mobile projects they are typically in 10’s. Rails projects are a little better but there are so many chunks of code that is not possible to unit test and mocking is inadequate. Also, its not just devs fault for not writing unit tests, my E2E/UI tests are pretty light as well. Even though I was able to figure out way to be in sync with development and write UI tests along with sprint cycles, they quickly become outdated and failing randomly. Tests maintanece becomes a full time job and I can’t keep up with new projects. So I move on chasing the next shiny thing.
So, am in a completely different school or a tester with no discipline? Far from it, I have been consistenly keeping up with projects coming from various directions and different dev groups: Native iOS, Native Android, Mobile, Web. I have been logging bugs(100’s of them), improved existing automation, created test automation frameworks, keeping up with latest tools and practices, adapting to mobile first etc, most of all making a consincious effort to improve my skill and the value that I add to my teams.
This is where the priciple of context driven testing
context-driven testing is about doing the best we can with what we get.
seems very relatable to what I do day to day. Though I would like to be in agile testing environment, I am pragmatic and want to support products that make money for the company, so context is very I end up with.
