Regression Testing
Regression testing is a specific type of testing with which a BA must be familiar. The concept is simple: after any software change, retest functions of the software that have not changed to be sure that the results are still correct. As simple as the concept is, it is one of the biggest areas of failure in the testing discipline. Why? Because who wants to test something that has already been tested? It is not glamorous or exciting, it often does not expose any defects or quality enhancements, and it can be very tedious and boring. Having acknowledged these issues, regression testing must be done. Software is very complex, and a small change can easily “break” something else that was previously working fine. Regression testing is performed throughout all of the other testing phases when changes are made after the initial testing has been completed.
|
Case in Point
A good analogy for regression testing is the electrical system in your house. Let’s say that you hire an electrician to install a new outlet in the wall where you want to hang a flat screen TV. When he is done, you plug a small lamp into the new outlet to test it before you pay the electrician. The lamp works. Later in the day, you turn on the switch for the ceiling fan in the room and nothing happens. Did the electrician cut a wire to the ceiling fan? Did he simply reroute the ceiling fan wire to the new outlet? You probably didn’t explicitly say that you still expected the ceiling fan to work after the TV was installed! It was an existing requirement that you didn’t feel the need to restate.
After you hang the TV on the wall and your family settles in to watch a movie, your daughter decides to make microwave popcorn. There is a loud pop and all of the power on one side of your house goes out! The electrician may have put the TV on the same circuit as the kitchen, which is not powerful enough to handle everything on it. Did you specify that you wanted to be able to use the microwave while watching TV?
|
|
Business stakeholders experience these same frustrations when a new requirement is fulfilled but the old functionality suddenly behaves differently. They didn’t specifically say “all of the existing screens should still work the same way after the new one is installed.” But this is an implied requirement that is verified through regression testing.
User Acceptance Testing
Most BAs are involved in user acceptance testing (UAT). UAT is the final phase of testing. Users test real-life scenarios to verify that the software will meet their needs. UAT is an important step in validating that the end solution meets the business needs. This conformance testing is named as such because the intention is that the users of the software will run the tests and accept the product. As software continues to become more complex and less procedural, testing becomes more complex. Testing software is challenging for even the most experienced SQA professionals. If it is difficult for them, think about how overwhelming it may seem to users. This complexity is why many organizations ask BAs to get involved. Typically, when software is sold outside of the development organization, UAT is referred to as beta testing and allows users to try out a new version of the software before its general release.
Why should users do UAT? Ideally, users are executing tests and building their confidence that the product does what they hoped it would do. Unfortunately, assigning a BA to this task often gives users the idea that they don’t have to participate. They feel that they have told the BA all of their requirements, so the BA should be able to accept the software. Don’t allow this to happen. Losing stakeholder engagement at this critical junction in a project may create dissatisfaction with the solution implemented. This is a dangerous situation and one that every BA should work to avoid. There are a couple of common reasons why this occurs, so beware!
Users, like everyone else, are very busy. If they think that the BA can do the work for them, they will be happy to let him or her do it.
Testing is hard work, and most users have never been trained in how or why they are doing it. No one likes doing something that they don’t really know how to do well.
Users often do not realize the likelihood of errors in developed software. This is not a negative statement about developers. It is a fact that developing software is difficult and discovering defects is a normal part of the process. Users may not be aware of the risk if a defect is not found.
Finally, users do not realize the significant impending change that the software will have on their work environment and they need to get prepared. When users actually work with the software during UAT, they realize how their corresponding procedures are going to have to change.
Although there are a few obstacles to overcome when trying to get users more involved with UAT, the benefits are enormous.
Users who actually participate in UAT are usually more satisfied with the end product than those who do not. They are not shocked by the change after deployment, but rather are gently prodded toward the change during UAT. Users who are committed to the entire software development process are more likely to get the product they need (Kupersmith, 2007).