How to optimize productivity from QA lead?
I am a project manager for team where I'm struggling to foster a productive work relationship with our QA lead. He leads a team of 3 other QA professionals and by far has the most experience. He's pleasant to work with and works harder than almost any other IT professional I've worked with in my 20 years in a software dev environment.
On the surface he seems to be the consummate QA professional, but his shortcomings have become a major obstacle to our team's success. His EXTREMELY deliberate, methodical approach consistently results in delayed completion of test execution and often slows down the rest of the project team inhibiting on schedule, on budget and on scope project delivery. He has great difficulty multi-tasking and really struggles with prioritizing, estimating and time-boxing his work. I have tried giving him specific, time-bound directions, which he often misses because of his overwhelming desire to find the proverbial needle in the haystack with every test he performs. I've also tried coaching him on the concept of minimum viable product and user acceptance criteria that our customers define, and that sometimes "good enough" is better than "perfection".
For the level of effort he puts in to testing, he produces very few defects. When he finds defects, many of them are de-prioritized because he has difficulty understanding delivering the RIGHT value for customers. He tends to mark every defect found as critical and as something that MUST be fixed in order to meet HIS acceptance criteria. He will create an inordinate number of test cases for even basic business/functional requirements or use cases, and will execute them repeatedly within each test cycle in the hopes he can find defects with each test execution.
Upon test completion of a given feature, module, etc., he then spends a significant amount of time documenting a test execution *summary* for me and for our stakeholders. In other experiences, comparable output I've worked with has been 1-2 pages consisting of a few bullet points or 1-2 paragraphs, test execution matrix, and list of defects found. The last 2 "summaries" he has produced for me have been 14 and 17 pages, respectively, and are mostly narratives that read more like a biography or memoir. Producing such artifacts have taken him 1-2 weeks to produce AFTER completion of his test executions, further delaying project deliverables.
I come from a QA background and strongly advocate good QA practices. However, the more I work with him (it's been 4 months), the more I'm discovering his interpretation of "best practices" and his obsession over minutiae become increasingly counterproductive to the team's ability to deliver successfully. He's a very late-career/near-retirement professional (I'm young enough to be his son) and seems hesitant to adapt; these shortcomings on his part are a major time sink for me to manage to ensure the entire team's success.
His functional manager has provided minimal guidance as I've brought these concerns to attention. Because I come from a QA background I understand his desires, but I feel every time I provide constructive yet direct feedback, he gets defensive about his self-perceived need to achieve perfection. I sense in some past workplace, he has been burnt and is overcompensating by over-testing and over-documenting to the point of producing diminishing returns.
From your writing.. I get the sense of the following.
* You feel that a QA team member assigned to you is either misaligned or lacking common sense. In that he's taking more time to find fringe defects instead of getting a more basic coverage of the whole delivery.
* You feel he has trouble managing time. Too much time spent documenting vs. time spent doing say exploratory testing or defect finding activities.
* He has a level of stubbornness., and his manager isn't being very supportive.
I'm going to leave the whole what it should be and what sort of behavioral modifications are needed. I feel you probably know already and it's already frustrating you, and a lot of these things are perhaps more of a job of having some informal lunches and building rapport and understanding between the 3 of you.
You as a project manager have a few things you can do under your power.
1) Involve him in the project planning and let him know the key drivers of the project. Explain why there are certain deadlines and what is important to the customer. Allow him to see the project from a higher level so he can see if he were you, he would be making some of the same choices in scheduling and priorities.
2) Set clear expectations. If you're doing a beta release, you can specifically instruct him that you're only looking for critical and major defects, etc... I get a sense this is what you are already doing. I would continue to do that but as part of the project briefing ahead of work being done if you're not already.
3) Before he starts testing, and even before development is started. Ask him for a Test Plan. A good test plan would include a list of risks, what's changing, and the activities he's proposing he's doing, and how much will he allocate to those activities. Review and give feedback. I know for myself I've written so many test plans that fall on deaf ears, that's it feels easier to just do the default.
One small addition to dlai's advice would be to include asking him to prioritise his planned tests within the test report. This way you can have it clear and agreed before which testing which ones "must" be completed during test execution, and which ones "could" be completed if time permits (yes, you could expand that to must, should, could, would - but that might be going too far).
As for taking too long to produce a test execution report, you could time box it to 1-2 days (or less). Then he'd need to learn how to produce the best report he can in the time available as opposed to producing an in depth report. Of course that can be fine tuned over time so he produces a report with sufficient detail without taking too long.