Pragmatism in testing is a hard one to put across. Itâs our job to push for quality, but if what we push for doesnât align to âgood enoughâ we can be seen as being out of touch with the team.
Iâve been told in the past that I have âa high bar for qualityâ which 1) I think is good in a tester 2) means I havenât understand what you want. So hereâs my tips for pragmatism:
Ask the team what âgood enoughâ looks like and share that. Make sure youâre all on the same page.
Share the view that your testing starts a conversation and isnât a bar. Weâre not saying you HAVE to do things, weâre sharing info so you can make decisions.
Remind the team that youâre there for them, that questioning and asking about quality is to help them.
Put your ego to the side. Yes you could find loads of horrible edge cases, but does the team need that?
Socialise that we donât want to test everything because we donât have time for that. Help the team identity useful opportunities for test.
I like how you think @cakehurstryan Iâve seen many testers with this unhealthy obsession where they think they need to test âeverythingâ sometimes even doing voluntary overtime - and of course not getting any medals for it.
Hi,
My experience with testing is as a tester, troubleshooter and test leader in the earlier and middle 90âs telephony and mobile systems, then a couple of decades in managerial roles, and now returning to SW testing, doing whatâs funny last years until retirement. I have been working âagileâ say last 10 ys and have done proper SW testing last 3 ys. Information rich Web applications for experts and the public in a governmental unit.
Having been a SW programmer(although its not my passion) and a manager for SW programmers I have been able to establish good communication with the teams. I try to communicate a feeling of us being a team (I am one of few testers, so I am involved in different teams) that together produces a product with acceptable quality on the desired time. A deep feeling of common sense. This involves really - as a tester - to get into the brain of the customer, getting involved early in the requirement process , being the guy that knows all systems and do have a broad contact with the customers ,as a common sense factor. Of course not deeply involved in the solution architecture and all bits and pieces of customer requirements. But having a good hunch of what kind of Update(its 90% updates of existing systems instead of all the new systems technique they teach in SW development education, right?) that is going to be made and what that really means in terms of testing (and development).
Then to really put you foot down to get requirements clearly stated, when programmers and project leaders just want to get going. Being an advocate for staying in the requirements stage long enough.
Then, when the testing starts, its just a joyride of finding faults and sorting out functionality in cooperation with the team members and the customer. The challenge here, I feel, is the own urge to get your hands on the new functionality as soon as available. This will foster a mentality in the teams that âAâ(me) do find all the stuff so we donât have to do our unit tests as thorough. It IS more funny to get involved early, having all kinds of opinions on functionality, GUI usage and so on, but one has to hold ones horses, right?
Being governmental, the budgets for in-house stuff is limited, so automation is often talked about, but myself and some of the programmers knowing a bit about the cost of E2E automation, not least to keep it updated in a world of changing Frontends, there has not really been done much. But we struggle to get funds for more automation. .net platforms, frontend platforms and whatever gets updated frequently and those regression tests aint the most funny of tasksâŠ
Ask the team what âgood enoughâ looks like and share that. Make sure youâre all on the same page.