My first testing role was as part of a QA team, because the organisation’s emphasis was on data quality and integrity; and indeed, my first tasks on the team were to work with external consultants on data collection methodologies and to work with specialists on data definitions, before we even thought about having an application to do the data handling, let alone writing any code. It was possibly two years before there was any question of having an application that needed testing, and even then I would sometimes have to switch tasks to do some data validation for a report, press release or a high-level keynote speech, checking that the numbers in those things were a) accurately transcribed, b) the latest and best data that we had, and c) quoted consistently within the document (‘text to tables’, or do we use the same numbers in the body of the text as in the tables in the report).
So for me, software testing has always been a separate discipline within an overall QA strategy. QA goes much further than just testing; it’s about advocating for quality across the whole range of work and making everyone responsible for quality in their own area. Testing is a whole separate strand within that. Of course, organisations, their work and their objectives vary, but this approach taught me useful lessons for later.