Feedback on Apprenticeships for Software Testers

In February the Urban Institute, a nonpartisan D.C. think tank, reached out to the Association for Software Testing looking to gather industry experts to review their “Software QA Tester National Occupational Framework”. Their stated goal is to accelerate the expansion of high-quality apprenticeships across the US, by developing frameworks for on-the-job learning and related instruction for apprentices.

Apprenticeships (registered apprenticeships) in the US are an alternative to universities where:

1. You get on the job training
2. You do some related instruction
3. You get mentorship
4. A paid job
5. You work for at least a year (sometimes more or less depending on the job)

The Association for Software Testing, as a nonprofit community based organization, has written positions on topics important to testers such as it’s opposition to standards like ISO 29119. It also has contributed to US government attempts to understand and classify software testing such as with the Occupational Handbook for Software Developers, Quality Assurance Analysts and Testers.

This seemed in-line with those previous contributions so I agreed to help on behalf of the AST.  Note: This doesn’t mean the AST or I will endorse whatever comes out. Only that when given the chance we decided to do our best to give the effort some direction. You’ll see my primary feedback and concern was the lack of context for whom the advice is for.

Work Processes

For context the framework looks similar to the published Junior Cloud Engineer Framework.
It has three sections:

1. An occupational overview which is an introduction to the role, it’s titles, and any prerequisites involved.
2. A work process schedule outlining containing job functions, competencies, and a score to grade the apprentice (on a scale of 0-4, 4 being the best).
3. Related technical instruction which contains a list of possible coursework for the apprentice.

The bulk of my feedback is on the second section called the Work Process Schedule. The schedule contains nine job functions. Under those job functions are competencies or tasks. Part of the feedback was for me to choose which are core vs optional.

The 9 job functions:

1. Supports gathering, analyzing, validating and documenting test requirements and objectives based on business requirements and stakeholders goals.
2. Supports the development and validation of test plans
3. Communicates with, engages and supports coordination across internal teams, clients and/or stakeholders
4. Supports conducting functional testing
5. Supports conducting non-functional testing
6. Supports conducting pre-release activities
7. Supports product release and post-release testing in accordance with company policies, IEEE and ISO standards
8. Provides ongoing support, ticket management and customer service
9. Provides reporting, monitoring and observability services

Note: Given the Urban Institute is seeking feedback, I’d expect (hope) this list to changes.

Feedback

(My whole tweet thread here is actually pretty good, if you want to read it)

Between the overview (which was incomplete) and the job functions, my primary feedback was a lack of context on who the advice is for. There's a ton of variation within testing practices based on size of company, industry and organizational structure, to name a few. A team of testers will have different responsbilities compared to a single tester embedded on a dev team. Working on medical equipment or aerospace, will have far different levels of overhead and a bigger focus on safety criticality than an eCommerce application or a mobile app.
As written the job functions don’t account for this variance. Additionally the job descriptions start generic and get more specific. If you can use observability tools great, but it's not a core job function.

The only job function I didn’t have a problem with as stated was number 3. Communication is such a big deal for people working in building software.
On the initial pass I didn’t provide much lot of feedback on the section on technical instruction. I did recommend a foundational class in software testing with learning objectives for the impossibility of complete testing, test design and oracles. If I'm able to provide feedback on an updated version I’ll look more into the instruction and how each section listed should tie into software testing.

Future Drafts

Both the review and following up discussion with the team from the Urban Institute were fun and productive. They were receptive to the feedback, some of which aligned with the other feedback they received.

Constructing an apprenticeship or internship program within a company sounds daunting. For this reason I’m encouraged by what they are trying to build. In the meantime I’ll wait to see what future drafts hold.