In this video, we walk through 5 ISC practice questions on environments and testing. These questions are from ISC content area 1 on the AICPA CPA exam blueprints: Information Systems and Data Management.
The best way to use this video is to pause each time we get to a new question in the video, and then make your own attempt at the question before watching us go through it.
Environments and Testing
When a company changes its software, whether it’s a new feature, a bug fix, or an update, it can’t make that change directly on the system the business runs on. If something goes wrong there, real customers are affected right away. Instead, the change moves through a series of separate environments and is tested at each one. Each round of testing is broader than the one before, so problems get caught early, while they’re still easy and inexpensive to fix.
For example, a payroll software company is adding a feature that automatically calculates overtime pay. That change will pass through three environments and four kinds of testing before any employee’s paycheck depends on it.
Development Environment
The development environment is where programmers write new code and run their first tests on it. It’s essentially a workspace. The code there is unfinished and changing constantly, so it’s normal for it to be incomplete or to fail when it runs. Programmers have full control over their development environment because they need to build, change, and rerun their work freely. Nothing done in development affects real users or real transactions.
Staging Environment
Once a change works in development, it moves to staging, sometimes called the pre-production environment. Staging is a near-copy of the live system, with the same software versions, similar settings, and realistic data and volume. Its purpose is to show how the change behaves under real-world conditions before anyone depends on it.
Staging is only useful to the extent that it actually matches the live system. Suppose staging runs an older version of the database software, or handles only a fraction of the live system’s transaction volume. A change could pass every test in staging and still fail as soon as it goes live.
Production Environment
Production is the live system, where real users work and real transactions are processed. For the payroll company, this is where actual employers run payroll and actual employees get paid. An error in production means outages, bad data, or people paid the wrong amount. For that reason, only changes that have been tested and approved should be moved into production.
Types of Testing
Testing follows the same small-to-large progression as the environments.
Unit testing checks one piece of the software by itself. The programmer runs the overtime calculation on sample inputs, such as 45 hours at $20 an hour, and confirms it returns the correct amount. This is usually the first round of testing, and it happens in development.
Integration testing checks that pieces work together. The overtime calculation needs to pull hours from the timekeeping module and pass its result to the tax withholding calculation. Each piece can work on its own and still fail when connected. For example, the timekeeping module might send hours in a format the overtime calculation doesn’t expect.
System testing checks the entire system as a whole against its specifications. The testing team runs a complete payroll cycle, from hours entered to paychecks and reports produced, and compares the results to what the software was designed to do. This typically happens in staging.
Acceptance testing confirms that the system meets the real needs of the people who will use it and is ready for release. It’s usually performed by end users or the business rather than by developers. It comes in two forms:
- Alpha testing is done internally, before anyone outside the company sees the software.
- Beta testing is done by a limited group of outside users, such as a few client companies, before full release.
Each stage should be finished before the next one starts. The scope widens as the change moves forward: one piece, then pieces working together, then the whole system, then whether it meets the business’s actual needs.
