So perhaps the most obvious question is "What exactly is a Full Stack Test Engineer?" and maybe a great follow-up question is "Is it even possible for a single tester to be a Full Stack Tester?" The idea behind a more familiar corollary, the Full Stack Developer, is the idea that a developer can create a solution or system at all layers and all aspects of functionality. That means front end, back end, services, middleware, etc. Full Stack Testers do not necessarily have the same level of code understanding or acumen (if they did, it is likely they would actually be developers).
Thus the idea is a full-stack tester is capable of testing at all layers and at all levels. Cool, OK. What still does that mean and do such people really exist? I'd argue that any single tester that has everything is probably not really a full stack tester, meaning they are expert level at all of the possible areas. However, it's highly likely you may already have a full-stack testing team, that is if you have a handful of testers. If you have any single tester that covers everything, the next question is "to what depth?" Testers, in general, have to be generalists. Man, that's awful phrasing but work with me here. We often know a lot of areas to a shallow level. The deeper we go on any given area, the less likely we will be to be able to provide that level of expertise for other areas. Can I be great at Accessibility? Sure, Does that lead to Usability? Absolutely? Can I leverage those skills into Responsive Design? Well, yeah. So does that make me an expert at performance? Okay, now we're starting to break down the paradigm. Being everything to everyone at an expert level as one person is a very rare unicorn and I might argue by the time you actually get that level of expertise, you may already be obsolete.
Let's be clear here, Christina is not saying every person needs to have this perfectly filled out square. It's impractical and it would take too much time for everyone to fit that level. However, what we can do is leverage the fact that most people are already T-shaped (meaning they have shallow expertise in a broad number of areas but they can go deep on a couple of a few areas). Certainly, cross-training is going to be helpful and ideally, anyone can be effective in any role if desired. Have everyone an expert in everything? No, that's ridiculous. Have all of the areas covered by the team in place or build the team to be that? Now that is attainable.
So here's the clear takeaway. Let everyone have a strategy to get some level of coverage in all areas. Make sure that no member of your team is completely blind in an area. In my case, while I cover Accessibility fairly deeply, I can help get everyone in my team to a level where they can be effective if not understanding literally all of the aspects. My talk today on the "Dos and Dont's of Accessibility" would by itself be an effective enough training to get everyone on a testing team far enough along to be effective with an Accessibility mindset. From there, the details of tools and processes can be added. Someone else on my team may have other skills that I might be able to learn from. Cycle these responsibilities and everyone has effective knowledge of all areas and each tester has some depth to draw on for specific areas. Granted, the smaller the team (or Lone Testers) yeah, this is going to be a lot harder but it's a journey, not necessarily a set destination. Besides, by the time you get "there", then "there" will be somewhere else and you'll just have to keep walking anyway ;).