Ah, testing. It’s something you know you have to do, but not something you know a whole lot about, besides that it fixes things and prevents bad things from happening. We want to give you a little more information on testing so the next time you head into an IT meeting, you can understand some basic concepts such as when and where to do testing, some common methods, as well as levels and types of tests.
Before Testing
Before going live with your implementation, it is vital to test the system in a test environment that is as close as possible to the production environment in which it will be deployed. Doing so will raise any errors, issues, threats, security vulnerabilities, and any other problems without actually threatening the live system.
During or “Go Live” Testing
If proper testing was conducted during the pre-implementation phase, then testing during go live should be minimal. Although you may want to keep extra IT staff handy should something go wrong, and should expect a major increase in calls to the help desk and in the number of support tickets being opened.
Another method of Go Live testing could be to create a pilot study, where a live system is rolled out for a small amount of users alongside the current system. This can give a good picture of what stresses real users may place on the system.
After or “Post Release” Testing
Once users are on the system, systems administrators can see how users are using the system, how healthy the system is, what are the most commonly performed actions, and other analytics that may be helpful to improving the system. This is a good time fix bugs, make improvements, record baselines and benchmarks, and plan for future updates to the system.
New tests should never be run for the first time in production. New tests should always be performed in a test environment where potential impact to the system is minimal.
Testing Basics
In testing, there are testing methods, levels, and types. Each provide a different approach to verifying and/or validating that the system meets its requirements, works as expected, and satisfies the needs of the stakeholders. Testing is usually performed once all coding is complete, but may be conducted alongside coding, as is the case with Agile Development.
Methods
Methods are usually grouped into two types: static versus dynamic testing, and the box approach.
Static Vs. Dynamic Testing
- Static Testing – Static testing uses implicit tactics such as proofreading and checking source code structure and syntax. Static testing involves verification – or ensuring that all requirements are met. Verification answers the question “Are we building the right product?”
- Dynamic Testing – Dynamic testing runs code and uses tactics such as debugging. Dynamic testing involves validation – or making sure the system fulfills its intended purpose. Validation answers the question “Are we building the right product?”
The Box Approach
- White-box Testing – tests internal structures/workings of a system
- Black-box Testing – Examines how the system works without regard to its inner workings
- Grey-box Testing – Using knowledge of the internal workings to design tests aimed at the end user
Levels
- Unit Testing – Verifies functionality of a specific section of code
- Integration Testing – Verifies that components of the system work together as planned
- Component Interface Testing – Verifying data or “packet” transfer
- System Testing – Verifies the system meets all requirements
- Acceptance Testing – Testing whether the end-user accepts the delivered system
Types
There are various types of software testing. Some of which may be familiar to you already. Here is just a listing of a few of them. More types can be found here.
- Beta-testing
- Usability Testing
- Security Testing
- Performance Testing
- Compatibility Testing
- A/B Testing
- Regression Testing
- And more!
This should be enough information so that when you’re at your next implementation meeting, you can speak intelligently and not look confused when people are talking about black boxes versus white boxes.