At the dawn of my testing career, before the widespread adoption of the internet and interconnected systems, the software project I first worked on was distributed as a boxed product (with a printed manual!), for installation on internal systems – connected to each other and perhaps some satellite offices, but not to the whole world which we now take for granted.
As the process of manufacturing a few thousand CD’s (and before that magnetic media) for distribution was incredibly expensive, the final version of the software that was released to manufacture had to have been thoroughly tested as any subsequent changes would have to be provided on separate media (patches on a floppy disc, posted out to individual customer sites).
Testing the software was entirely manual, on a version that was largely complete with a period of time allotted to find and fix any defects before release (the code-and-fix development model).
The test team (both of us!) were very much separate to the development team (a non-integrated test team) and only voiced our opinions on the software after it had been built, whilst we were testing the new version.
Testing took a great deal of time while defects were raised and fixed, and the software rebuilt and retested until all tests passed, at which point it could be released.
Thankfully, the process of software development and testing has moved on and in our interconnected world, how software is consumed allows some sectors of business to rapidly and continually update their services. Individual online devices (a desktop PC, phone, console or other smart device) can now be periodically updated with relative ease.
This does not mean overall quality is now less important – quite the reverse – competing businesses in the online world try to out innovate each other to increase market share, and there is an emphasis on security that now only exists because your platform or device can be attacked by a teenage hacker on a different continent. Before the internet age, new products with enhanced features may have been released yearly at a minimum, and security generally meant making sure your workstation was locked. Shared servers were password protected, but encryption was not part of commercial operating systems – network traffic was easily intercepted plain text (if you could plug something into the right part of the office network)
The modern age (now-ish)
Computers (in all forms) and the software that runs on them are now an integral part of society, and testing is now an embedded part of the development of software.
Rather than chucking some (half baked) code over the wall to a team of testers, those testers work within the development team and get involved in the quality aspects of the software before it has even been written.
As a business analyst once remarked, “Testers ask difficult questions that no-one else thinks of”. By ‘left-shifting’, and getting testers involved before code is written – typically while the user story is being reviewed and acceptance criteria defined – allows problems to be found before they become part of the code.
Once the acceptance criteria have been agreed, test cases can be defined and these may be automated by either testers or members of the development team.
Testers can also be involved during the development of software – working with developers to provide fast feedback as the code is written.
Once complete, testers (or as is becoming more common, someone else in the team) can execute the tests and record results and report any defects.
In upcoming posts, I intend to explore in depth the different types of testing, when those test types would be used, and the techniques that can be applied to design the tests cases, and ultimately – how those test cases can be automated with some of the more popular tools in the industry.