QA as an Act of Mentorship
Strategic Thinking Over Quick Fixes
- Strategic Thinking Over Quick Fixes: Hiring junior developers for testing lacks strategic foresight and hampers long-term growth.
- Expert Evaluation: Inexperienced developers assessing complex systems should be replaced with a structured approach where seniors lead testing and therefore mentor juniors.
- Structured Development for Growth: Implementing a structured approach empowers juniors, improves code quality, and fosters a pool of skilled engineering managers for organizational growth.
Those who know me know that QA holds a special place in my heart. My initial discovery of automated testing changed a struggle to keep pace with customer expectations into a slow, steady march toward success. In all of my successful projects since, automated testing has formed a foundational position in the planning and implementation of projects. It put periodic anchors in place that myself and my teams used to ensure we never moved backwards.
This experience has been foundational to how I perceive its use, and how I interact with my colleagues.
So, during an online discussion about a software system in trouble and how best to recover it, it was suggested that hiring a junior developer to test the software would offer a quick, cheap win. Since they were cheap, hiring a junior developer would be better than nothing and offer some assurance.
I think this is a disastrous solution: quality should not be judged by the apprentice but by the master. The suggestion demonstrates a lack of strategic thinking, and is likely the type of thinking that likely got the organization into trouble in the first place. Instead, a more future-oriented strategy, focussed on organizational growth, is in order.
I have both seen and experienced cases where poorly written, shallow testing resulted in a false sense of security: it was a net negative, even though it was a large volume. A lot of activity (testing) was being done by unqualified individuals; because there was a lot of testing happening, everyone felt it was well tested.
These aren’t the same thing.
In the most memorable case, very smart and experienced engineers were writing complex and subtly integrated components that were expected to be validated by very junior developers. The seniors, dogged by management, aimed for “done” to meet implied quotas and then “threw it over the fence” and (subconsciously) hoped it would sneak past.
I’ve seen this very clearly multiple times.
In all cases I have seen, the organization suffered from an inversion of the apprentice/master relationship: apprentices evaluating masters. We correct the relationship by having seniors write tests while juniors write code. This corrects the relationship: teachers test students, experts judge the work of novices, and masters evaluate apprentices, not the other way around.
The correction I have applied in the past was to make
- automated testing the responsibility of developers (not a separate group)
- junior developers solve the problems (with the guidance of a senior)
- quality assurance is the responsibility of the senior developers (through automated testing)
By reducing the amount of code seniors were permitted to write (except through the junior’s hands) juniors started to gain in learning opportunities, improving the quality of their output. At the same time, senior developers are developing managerial skills, allowing the organization to expand by creating a pool of junior engineering managers.
It appears the original problem expressed was the result of a lack of strategic foresight: short-term wins at the expense of the sustainability of the product. It is a hard habit to get out of because instant dopamine hits feel good, get promotions, and make sales; however, it becomes necessary for the organization's survival to implement change.
Testing offers a solid foundation to pivot that strategy around, but that strategy must be focused on the future stability and growth of the organization.
