Software Testing

BAs support testing professionals to validate that the product meets business needs

One reason why you need to understand the technical environment is that you will probably be involved in testing solutions. Many BAs and many other project team members dislike testing because they don’t understand it fully and because it has always been low on the IT priority list of areas to improve. A successful business analysis professional appreciates the importance of quality assurance practices and is able to step in and help when necessary.

Testing software programs and components has been done since software was first invented. Testing strategies and tactics are actually much older than software. Other disciplines perform testing: electrical systems are tested, architectural designs are tested, and the engineering discipline involves significant testing. As in many other respects, these disciplines, which are much more established than software development, can give great insights into testing approaches. Testing professionals use test plans, test cases, test procedures, and automated testing tools to plan and execute efficient, effective tests. A great introductory resource on software testing is The Complete Guide to Software Testing by Bill Hertzel (1993).

Many software testing practices can also be used on manual procedures and processes. Testing should not be limited to software. When a project solution includes new employee procedures, test them just as you would software. Design test cases for usual and unusual situations.

Case in Point

I learned to enjoy testing when I starting conducting seminars on quality assurance. In the past, most of my testing had been on my own programs. No one enjoys finding problems with their own work, but when I started studying the core concepts of software testing, I realized that it is a sophisticated profession which brings great value to every project. There are very structured approaches to designing test cases so that they cover as many requirements as possible. When I began developing workshops for my seminars, I enjoyed designing the test plans, and students really enjoyed exercising the tests because when they found defects, they felt successful. This is when I realized why testers should be objective people who have not been involved with the software development work. Finding defects is like going on a scavenger hunt—the more you find, the better. Quality assurance professionals become very adept at designing clever test cases to try to fool the software and trick it into making mistakes. This is a valuable skill for an organization because it ensures better quality products.

Understanding the testing process helps the BA in requirements elicitation and analysis. The BA must make sure that each requirement is excellent by making sure that it is “testable” or “verifiable.” The classic example of a requirement which is not testable is: “The system should be easy to use.” There is not a clear test that could be designed to validate this requirement. When an analyst thinks about how each requirement will be tested, he or she writes more detailed, precise requirements. The experienced analyst also considers performance requirements when helping to design a solution. Specific performance requirements must be elicited by the analyst even though they will often be difficult for subject matter experts and users to articulate. “It needs to be fast” is not a useful requirement. The BA uses questions and examples to help users determine their performance tolerance: “If the query request was returned within 30 seconds, would you be satisfied? Let’s sit here quietly for 30 seconds to see what that much time feels like.” “Would 45 seconds be too long?” “Would you accept a system that returned short, simple queries in an average of 15 seconds, while complex queries might take up to 60 seconds?”

BAs are involved in test planning and in designing realistic, useful test cases. BAs also are key team members as defects are found and corrected. Since BAs understand the requirements and the solution design, they often see defects and know from where they originated. BAs often report defects and research them to determine the cause and the correction.

Most software development testing approaches used today are based around the standards set by the Institute of Electrical and Electronics Engineers (www.ieee.org). This professional organization dates back to 1884 and has a lot of experience and knowledge from which to draw. What software developers discovered early is that testing software applications is similar to testing electronics products. Each individual component is tested separately (unit testing), then connections between pieces are tested (integration testing), and then an entire product is tested together (system testing). Finally, the product is tested by the end users (user acceptance testing) to allow them to be confident that the product does what they need. One of the reasons why use case descriptions (see Chapter 6) have become such a popular analysis technique is that a use case leads directly to a test case. Software quality assurance (SQA) professionals can quickly understand the requirements and understand how best to the test the software against the requirements.

SQA professionals and the approaches they recommend always involve quality activities at the beginning of and throughout a project. An SQA professional should be involved with project scoping, reviewing requirements, reviewing designs, and testing to be sure that the product works and that it meets user needs. All too often, due to resource constraints, an SQA person is added to a team after it is behind schedule to quickly test the product and get it ready for production. Coming onto the team in a late stage does not give the SQA professional much chance to influence the quality of the outcome. It simply puts that person in the position of testing and identifying defects.

Many BAs are expected to perform all of the business analysis tasks along with all of the SQA tasks. If testing will be part of your responsibility, get formal training in standard SQA practices and work to incorporate these standards into your organization. When you are assigned to a large project, talk with your project manager about bringing on an SQA professional. Explain that an objective quality professional will be more valuable and allow you to focus on the business analysis work.