Written By Brian Mills:

Are you getting ready to start a software implementation? Maybe you are upgrading a current system? One of the first things that you do is you begin to assemble your project team. Eventually, you will begin to gather requirements. Think back to the last time you went through this. Who was involved in the requirements phase? The chances are that it was primarily a business analyst and the business stakeholders. Sometimes there may be a representative of the development team involved, but how many times are your testers involved? From an end user testing perspective, the group developing the requirements could be the testers, but maybe they aren’t. For that matter, who are your testers? Hopefully, you thought of quite a few people.

Years ago, the term Quality Assurance Tester was used often. The QA has slowly been dropped from that term and, generally, that group is referred to as the testers. I would, however, argue that testers are throughout the team. I once worked with a QA Manager that proclaimed, and rightly so, that the QA department couldn’t instill quality. That had to come from everyone involved prior to the product getting to the QA department. His team was the last line of defense. Remember, QA stands for Quality Assurance, not Quality Added. The QA team will ensure that the product meets the specifications, but keep in mind there’s no such thing as defect-free software. The entire project team should be doing everything they can to ensure that the defects in the system are minimized.

That brings me back to my earlier question. Who do you have involved as you gather requirements? Get all your testers involved early. To do this, you’ll need to ask yourself “Who are my testers?” As you thought about that, did you also include the software developers? Those are going to be your very first testers. They should be responsible for unit testing the code that they are writing. If they are adding to existing code, they should be testing the integration of that code. Any modifications to existing code will need to include testing to ensure that the modifications have been done correctly. This testing is your first line of defense against defects, and if defects are found, it’s also the least expensive time to fix them. This is probably a good time to bring up the 1:10:100 rule. If you’ve never heard of this rule, it’s the rule that a defect found during user acceptance testing will cost ten times as much to fix as it would have if it had been found in development testing. If that same defect were found post-release, it would cost 100 times to fix.

1:10:100 – Show me the money!

Let’s put that in dollar terms. Say your developer catches a defect, and it costs that person $100 of time to fix. Now imagine that you haven’t included early testing in your project, or that the defect was missed in the developer’s unit testing. When it’s found during UAT, a developer will need to fix it and test the fix. Retesting would also happen all the way through in the process until it gets back to UAT. Let’s take that same defect and say that a developer’s test didn’t find it. I’ll use the scenario of a “requirements defect.” This would be something that was essential to an end-user being able to conduct their work but was missed during requirements gathering. Because it wasn’t in the requirements, it wasn’t testing in unit testing, integration testing or system testing. Instead, it was found during User Acceptance Testing when the user couldn’t complete an essential task. That defect that may have cost $100, because it wasn’t found until UAT, now would cost you $1000. The new requirement would have to be written, developers would have to fix the issue, and testing would need to occur again in unit, integration, system and UAT. If that defect makes it to the production release, it could cost you roughly $10,000 in development, testing and redeployment. That doesn’t include the adverse effect on the software owner’s reputation from the software user’s unsatisfactory experience. Additionally, if this is software that you have provided to a client, there may be service level agreements involved. Those agreements could introduce an additional monetary penalty for a defect. This is just an elementary example, but hopefully, you get the point. If the cost of testing is brought up, ask that person to think about the cost of not testing. You can certainly reduce the cost of testing by not testing—but is that a risk that they are willing to take?

All the testers all the time!

So, I’ll ask again: Who are your testers and when do you engage them? Get anyone who will be testing involved early in the requirements process. At a minimum, have a representative there from each phase of testing. Doing so will allow the requirements themselves to be tested. Experienced testers will look at requirements and ask how each requirement will be tested. If that question can’t be answered, then the requirement will need to be modified. Everyone will have the ability to help define the requirements and in turn, agree upon the intent of each requirement. The testers involved in all the software testing phases will have the ability to prepare their test cases properly. User acceptance testers will be able to participate in the gathering of requirements to help ensure that the essential parts of their job are included, and hopefully not running into the missed requirement as mentioned earlier.

Involving testers early in the project can, among other things, reduce the total cost of ownership of the software, improve quality, save time and help ensure the best possible user experience. For the later phases of testing, you also want to make sure that you have the right people involved. It requires preparation. For every hour of test execution, a good tester might spend two hours preparing the test cases. If they are involved early, they will have the needed time to plan and prepare.

If you’re already getting all your testers involved early in your project, congratulations! If you haven’t involved your testers early in your project, please consider it. The benefits greatly outweigh the risks. Recall the previous example. That was one defect. One defect that makes it to the production release could cost thousands to fix. When is the last time you had one defect in your software? Multiply that one defect by ten or even twenty. It can be quite costly. Focus your testing efforts on the early testing phases. You can save yourself time, money and damaging effects on your reputation by doing so. Take the extra time at the beginning of the project and think about the 1:10:100 rule. You owe it to your stakeholders to deliver the best possible solution. You’ll never be able to give them a piece of software that is entirely free of defects, but you owe it to them to provide software with as few defects as possible.

Brian Mills – Consultant

Brian Mills is a seasoned IT professional with extensive experience supporting complex information systems for public and private sector organizations within waterfall and agile software development lifecycle (SDLC) methodologies.  He maintains a diverse business and IT skill set with strong communication and interpersonal skills that enable him to work well with developers, business users, and stakeholders at all levels of an organization.  Throughout his career, Brian has held multiple leadership positions and continues to use his business knowledge and experience to bring success and best practice work to all projects.

CONTACT US TODAY