5

For us, QA generalists are roughly professionals who can work in the variety of quality assurance disciplines, have experience in a broad range of products, industries, and tools, have an understanding of the product development cycle (including DevOps), and generally, have more breadth than depth.

What are some of the things we can do to help our existing QA specialists become QA generalists?

  • 1
    coding dojo with devs to help QAs get to know about dev work (DevOps); organise devs and QAs in cross-functional tribes; secondments. – Yu Zhang Dec 19 '17 at 22:36
  • 3
    In general, you may want instead a hybrid of a generalist and specialist: T-shaped skills with shallow basic coverage of many areas, but deep skills in one specialized area. – Peter M. Dec 19 '17 at 22:52
  • 2
    I like being a specialist. I'm very good at my specialty (automation) and do not wish to be a generalist. I think of it like a teacher who is, say, a specialist in science. While that teacher might be able to teach history, and would probably be qualified, it's not their area of specialty. A psychiatrist is a doctor first, but I don't want one as my primary care doctor. I only want them for my mental health. – Bill Hileman Dec 20 '17 at 14:17
  • 1
    @AlexeyR. that’s a nice idea! Now when we figure out how to grow QA generalists we will do outsourcing! ;) Okay, to be serious, I hope to achieve a more agile environment where we can switch positions, jump from project to project more easily and transparently. Thanks! – alecxe Dec 21 '17 at 16:50
  • 1
    I think it's part of people's temperament whether they like switching products, teams and technologies or they prefer staying with one team and a product, and learning it slowly but more thoroughly. Both types of people are necessary but it's hard to change one type into another even when motivating them well. I heard many times I should be more open, react quicker to emergency situations and with less stress. I am very effective in my comfort zone. I can get outside of it but not for very long. If you need specific type of QA, look for them during interview process. – dzieciou Apr 1 '18 at 15:40
2

If you want people to be able to handle a wide variety of situations, and tools, and so on, you need to give them exposure to a wide variety of situations, and tools, and so on. And, crucially, you also need to understand that they are not going to be very productive for some period of time after every move. You also need to understand that not everyone is going to be suited to be a generalist.

You also need to look at the way teams are structured. Is the plan to have a core group of people (including QA) working on each product, and then move other people around as needed? Or is the plan to let products lie fallow for a time, and then dump a bunch of people onto a product that hasn’t been maintained in a while?

If it’s the former, then you have a better chance of being able to have generalists, because they have an easy way to learn the product. If it’s the latter, you need to assume there’s going to be a very long period of learning required, and you need to be very, very sure that the product and development process was well documented. Having corporate guidelines/requirements about such documentation would be a good idea.

I may be in a somewhat unique situation, but I work on a product where components may not have been touched in twenty years. Having both institutional knowledge and very, very complete development documentation is a necessity in such cases, as otherwise, you have no way of understanding why certain decisions were made, and judging if the decisions are still relevant when the constraints involved have probably changed.

  • 1
    +1 for "You also need to understand that not everyone is going to be suited to be a generalist." Agreed: some people are just wired this way, even if they can learn some skills they may not like it. And people who do not like dynamic environments might be more effective in long-term tasks. – dzieciou Apr 1 '18 at 15:45
1

If you want people that have worked on a variety of different projects, then you need to rotate people to work on different projects. This can be painful in the short term as you are assigning people to the type of projects where they do not have experience.

It would be helpful to have good documentation on test cases, test strategies and tools so that people can ramp up quickly and not have to rely on trial and error.

1

Rotate, let them experiment with Ideas.

Rotate people between different technology teams and let them come up with new creative ideas together in the form of prototypes/PoCs to solve existing team problems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.