Juist door de introductie van agile werken, moesten teams zelf zo veel mogelijk kunnen. Er wordt ook wel eens gesproken over dat elk teamlid alles moet kunnen, maar dat klopt naar mijn idee echt niet. Zolang elk team maar alles kan wat het moet doen om de stories af te krijgen. Daarbij is het wel zeer gewenst om SPOF’s (Singel Point Of Failures) te voorkomen. Dus bijv. het releasen naar productie moet niet alleen een developer of een OPSer kunnen, maar ook bijv. een tester. Mede hierdoor ontstond de T-shaped professional, en dus ook de T-shaped tester. Iemand die heel goed is in het (test)vak, maar ook echt wel kaas heeft gegeten van andere vakgebieden die het team moet kunnen. Hij/zij hoeft er geen ster in te zijn, maar moet het team zeker verder kunnen helpen. Dit helpt ook enorm bij de wederzijdse acceptatie binnen het team. Als je met teamgenoten op niveau kunt overleggen, dan werkt dat veel fijner samen. En samen kom je er dan wel uit. Het kan best frustrerend zijn als je een probleem hebt, en niemand uit je team heeft kennis van jouw situatie waardoor je met niemand (binnen je team) op niveau kunt sparren. Dan voelt het zo dat je te afhankelijk bent van andere teams.
Mijn ervaring is dat je als T-shaped tester vaak niet meer kunt uitblinken in een team. Je kunt wel meekomen met de rest van het team, maar je echte toegevoegde waarde is redelijk specifiek en daarmee lichtelijk beperkt.
Ik heb in 2020 op het Testnet najaarsevent een presentatie gegeven die hier mede over gaat: https://www.youtube.com/watch?v=DqacLpQcA4s
Een paar jaar geleden kwamen de termen (n-shaped en) m-shaped tester in de media, en ik denk dat een boel teams baat hebben bij dit type professionals.
Een n-shaped tester is erg goed in 2 vakgebieden, en kan ook goed meekomen met een aantal andere vakgebieden.
Een m-shaped tester doet daar nog een schepje bovenop, en is in nog een extra vakgebied echt goed, en kan in nog meer vakgebieden goed meekomen.