That everything has to be planned and nailed down up front (Dan Billing)
That you had to be ISEB certified before you could be a good tester - (LarryG)
That testing is about finding bugs (Hylke De Jong)
That I can find all the bugs. (Dana Bentley)
That testers and developers don’t work together (Iain Bright)
That 100% bug free is the goal. (Jenna Charlton)
Always aiming for the best (Helena Barmer)
Automation coverage 100% (Anand Ganesh Sivaraj)
That you had to automate EVERYTHING (Kaveeta Bhatia)
That assigned acceptants take acceptance testing seriously. (Herman Nijland)
That we needed a perfect understanding of how the system was supposed to work before we could do any useful testing. (To be honest that illusion didn’t survive contact with reality for very long.) (James Christie)
“Quality is only the testings responsibility.” Nope.
I’m very glad we have moved away form the culture that if anything isn’t a high quality is is the testers fault. Instead we ensure the entire team, developer, tester, product owner ensure the ‘quality is built in’. It’s always a work in progress but it has to be a team activity. From the conception of the idea, to the deployment, everyone is responsible.
Every possible permutation needs to be tested. A more experienced tester explained the principals of risk based testing and the impossibility of exhaustive ( in both number of tests and physical exertion) testing. Made me chill out.
Also my biggest fear was if something went live and a bug was found I would be blamed and sacked.
I believe my role is to find bugs. No one wants to hear my thoughts on stuff that isn’t related to a bug. You know, such things like feature and product ideas, concerns, compliments, the quality of my testing and how we might make it easier for all of us to test.
Last night’s session was on Exploratory Testing (ET). Folks were asking when should we do ET and what should we do next. That prompted me to remember a belief that I let go of: in testing there are absolute right answers. Sometimes ET may be one step in the bigger process, sometimes it alone may be sufficient testing … it’s all about making the assessment based on the situation.
There is no correlation between the volume of testing artifacts produced during ET, or any other testing, and the value of the testing, the example spoken about last night, and I used to think this way when working for a large corporation, was that artifacts are important as they prove we have performed testing.
Further to the above point, it was suggested that there could arguably be inverse correlation between the creation of voluminous quantities of test artifacts and the value of the testing. This could come about as the time spent generating artifacts has reduced the time available to perform actual testing.
Based on the above I recalled another belief that I have let go of: production of test cases == testing. As was mentioned last night and the above point, inverse correlation can apply to this. The example given was that a test manager may prefer to assess the value of testing by looking at, e.g. mind maps that were produced during brainstorming/ET rather than wading through low level test cases.
A few of my own as well:
Testing is a fixed skillset, i.e. once you have tools in your tester toolbox, you’re done. I’ve come to appreciate that a continuous learning ethic applies to testing perhaps as much as it does to software development
Automation is the holy grail. I’ve come to appreciate that it definitely adds a lot of value, but it doesn’t do this automagically when we just approach it at an operational level, i.e. good strategy and tactics really help
There is not a lot of difference between a good and a great tester
By doing ‘x’ you’re doing agile. I now think agile is much more something you judge based on how you feel
That one has been so damaging to me, and my life as a tester has been so much better now that I’ve let it go. There’s a team of other people, developers, QA members, PMs - they all do some amount of testing, and I need to focus on the areas of highest / critical risk, because testing everything is impossible.
Tl;Dr - Trust your coworkers, and recognize that you cannot test it all.
What I believed - that I need to learn automation to be a ‘proper’ tester.
What I now believe - automation of any kind is just a tool in the testers kit. I’ve met far more talented testers than me that barely know anything about automation.
I was made to write these permutations by my lead after I joined a new company with about 6 years of testing experience . I tried to explain him how unuseful and expensive that would be. Maybe I couldn’t explain well, he handed over the ISTQB book to me to refer.