Lead QE role and given autonomy but where to start

Questions
, , ,
#1

Ive recently moved to another QE Lead role and the managers are telling me that I can direct and have autonomy as much as possible but tbh, I dont know where to start (not that ive never been in this role before but guidance would be good). A bit of background of where the company is already in:

  • Hired QE’s before me without much automation experience (thats fine with me as Im happy to mentor and coach but obviously requires hand-holding more)
  • No quality strategy so far (I’m happy to create one such as increasing automation test coverage, involving QE’s on earlier phases, etc)
  • Devs have built a test framework but its something that an inexperienced QE would have difficulty picking up (I still want devs to get involved and not alienate them as i want them to continue having a testing/quality mindset)

I’m more of a hands-on guy and want to give autonomy to my team too but them having not much experience, It would be hard to delegate stuff and really spend time with them pairing and them learning best practices, etc.

Also, the framework is too dev-centric and i want to simplify it (its a bit overkill for a test automation) but i dont want to create friction with devs who have built it.

Im having difficulty finding the balance between operations/bau stuff and guiding the new QE’s and the strategic/innovation stuff. Id like to present something concrete to the mgmt team too (maybe identifying biggest pain points, quick wins, etc)

Help?

3 Likes
#2

Congratulations on your new job! Unfortunately I don’t think anyone can give you a detailed and fool-proof recipe for success here; my guess is (like most of us) you’ll just have to do the best you reasonably can. I.e. don’t stress if things aren’t perfect and don’t think that you could create the perfect plan if only you spend enough time thinking now.

It seems that you have multiple stakeholders, and multiple time scales of work for the various stakeholders. The stakeholders seem to be you as an individual contributor, your team, your direct boss, and the wider management team (plus devs as suppliers). Pairing with team mates will help them with their work today, but improving automation or devising strategy will help people weeks or months from now.

The only suggestion I can think of is write lots of lists (in a spreadsheet, Trello board etc. if that would help). Group things by stakeholder and time scale. Then do the top thing from each group. Whether you work on multiple things in one day or devote a day per week per group (or something else) depends on what works best for you.

Unfortunately it seems like you can’t do just short term stuff or just long term stuff, but will have to keep multiple balls in the air / multiple plates spinning at once. This, in my experience, is an inevitable feature of leadership.

Re. the dev-centric automation framework - could you add a more tester-friendly wrapper to it? I.e. you don’t throw away stuff that the devs have done, but add a facade that simplifies things down to just the requirements of testers. Or write a bit of this and then ask the devs if they could finish off the rest of the facade.

3 Likes
#3

Why do say its too dev-centric and overkill? Any examples?

1 Like
#4

I wanted to have holistic / general approach but the maturity level of quality in each teams are different. As such, you’re 100% right to just list the top things from each group because they differ heaps and what works for one group doesn’t mean its going to work for another.

Thanks for the detailed suggestions. “keep multiple balls in the air / multiple plates spinning at once” - this is something I would need to learn as I move up the ladder. I was always struggling with the context switching and used to focus on one thing at a time.

1 Like
#5

I don’t know how to put all the details here but I’ve been working with Cypress for years now and the way the framework is done is it’s more a Typescript framework with Cypress as just one of the plugins (not even using native cy commands). There are a few principles used in test automation such as KISS and YAGNI, balance between DRY and DAMP to make the tests more deterministic, independent, faster, etc.
I’m not saying it’s bad coz coding standards were understandably used but its looking more like the source code now than a Cypress framework. I don’t have a problem with it but the QA’s they hired before me are feeling overwhelmed and they are struggling to contribute. I’m happy to guide and coach but I think it won’t be enough.
I understand that developers should be actively contributing to the framework too and it should as close as possible to how they develop stuff but the company is at a scaling stage now that the Engineering managers would want the devs to focus on features and unit tests while still passively contributing to the e2e tests if needed. So I’m just trying to find the balance now where both QA and Developers can collaborate but there is a big gap in knowledge.

1 Like
#6

So, here is where there is some philosophy on different directions to take. What direction you take is going to depend on your context and you likely need to do some experimentation to understand what works and what doesn’t for your company.

Option 1: QE’s as coaches, leaders

Take the opportunity to embrace the quality coaching side of quality engineering.

Don’t take control of the test automation suite, that is developer work! And don’t over focus on teaching your QEs automation with the idea they are Testers who will do the testing work.

Instead, teach them to coach and support the developers. Get them to run pair and ensemble Exploratory Testing with the team. Support the developers to understand the quality issues and fix them.

Option 2: QEs as tool smiths

Support your QEs to become tool smiths. These could be tools to support observations, automated testing or manage test data. Or they could be thinking tools like mind maps or product behaviour models

Understand what gaps and blockers exist with current Testability and support your team’s to bridge those gaps so it’s easy for anyone in the them to test and assess quality.

Option 3: It’s all about the data

Ruthlessly seek, create and analysis data about your users. Stop over focusing on pre-production testing and start looking at how to understand how users are experiencing your products in production.

Introduce robust practices to collect signals from users to detect anomalies and bugs in production. And coach your Development teams at fixing these quickly. Therefore giving you more confidence to experiment.

This option works better when not operating in a Health or other regulated context.

Many more options exist. To understand if any of these will work for you, your going to need to research your own context and do some experimentation!

Good luck, I’m looking forward to hearing how you get on.

3 Likes
#7

Thanks for this interesting information!

2 Likes
#8

If you’ve made it this far, this should be the easiest step. The client wants to buy your product or service; now you just have to get it in writing https://folderly.com/. If there’s any hesitancy to closing this sale, find out what concerns the customer still has, and figure out a solution – perhaps an additional meeting or a product demo.

1 Like
#9

Thanks Ben for taking time to answer. I specifically like “Its all about the data”. I’m definitely putting all these into practice and keep experimenting what works and whatnot.

2 Likes