Test Team Setups

Hello again, another blog from JG Tests! This post focuses on the test team setups that you may typically come across in the world of IT, and I’ll also chime in with my own experiences working in these different test team setups (where applicable).

Solo/independent tester

To begin with, there are clear benefits for someone who wishes to work alone. Complete autonomy over the QA process…QA strategy is your own to define, being the only person that is concerned with testing activities…being left alone whilst you work. Sounds great doesn’t it? For some testers this scenario may be ideal – particularly if starting a role at a company that either outsources testing (to contractors/agencies) or doesn’t have any testing process implemented whatsoever (yes, even in 2018 testing is seen as optional!). However, whilst having carte blanche over the domain of testing, there are a lot of related responsibilities to handle. A poignant quote from a recent Software Testing Blog comes to mind here: ‘With freedom comes responsibility’. You’ll have to justify every initiative planned or executed in the name of testing, and also have to ensure that effective communication is essentially your middle name when conversing with multiple members of an organisation. And not to mention, being organised enough to carry out testing on a day-to-day basis so that you’re still turning your cog in the wheel, so to speak. This was a role that was suggested to me by a recruiter a couple years ago, and whilst the idea of independent working did initially seem favourable, it wouldn’t have reflected my experience very well at the time so I chose to decline on that occasion. Maybe one for the future?

Permanent QA department of excellence

This permanent test team setup would consist of a team of testers that work directly under a test team/QA manager; their workload would typically be managed by the QA manager for all ongoing projects, and tasks/projected will be delegated to the testers between the team. Information on project progress and testing activities will be sought out by the QA manager on a periodic basis so that he can communicate this to the wider organisation.

From my personal experience, this was a good way to start my testing career as a junior tester; working with a QA manager who showed me the fundamentals of testing and how to document my testing activities; a senior tester giving me specific knowledge in relation to the tools being used in the QA team and how to use them effectively, and a more experienced junior that introduced me to the wonderful world of mobile testing. It was a great environment to learn and I definitely felt and saw the progress when I became the voice of experience in my own right throughout the organisation.

However this dedicated QA team approach (unless you are working as a contractor) is better suited to software companies that work to the waterfall development model. Our method of waterfall mostly delved into the ‘sashimi’ adaptation of the software development model, which meant that each stage overlaps each other and are more flexible to changes/refinements (albeit not as efficient as agile, which I’ll expand on below) but this may not work for everyone. However it appears that I’m working in the last generation of testers that didn’t work exclusively in an agile environment so any budding testers may not get to experience this. In the agile world the idea of a test team is quite loose IMO – information/knowledge is shared but less frequently, and training is only given when absolutely necessary.

 

Agile tester

In an agile setup, a sole tester/set of testers may work as part of a SCRUM team consisting of different members of development (usually a mix of developers, designers, product owners, business analysts and other relevant stakeholders). These teams can usually consist of 4-10 members. The beneficial thing about working as a tester in this setting is that testing can now be ‘shifted left’ – no longer is there a strict defined stage for testing. It can take place on requirements/user stories, designs and of course whilst testing prototypes of the application at each given point; working in an agile format enables the software to be tested in smaller chunks in which near-immediate feedback can be given to members of the team informally or in set meetings during a sprint such as daily/periodic stand-ups.

This is the most common, and almost standardised way of working in IT today for testers, and the ISTQB also offer an Agile Tester certification path to the Advanced Level in light of this change – from personal recommendation you should at least seek to gain the Foundation certification within the first 2 years of commercial testing experience – it will help any budding testers to solidify their early knowledge and understand what they have been shown by more senior testers in the organisation.