Chapter 1, “A Business Case for Enterprise Network Testing,” stressed the importance of assessing the business reasons for testing as your first step in crafting an effective test approach. In the same way that a network designer would be foolish to specify equipment or make technical recommendations without prior knowledge of customer requirements, a test engineer would be misguided to attempt writing a test plan without first understanding the triggers, scope, motives, and expectations for the test initiative. By rushing ahead and skipping this critical step, you risk missing the mark in your testing, focusing on the wrong types of tests, or capturing erroneous results. This will waste precious time and resources as you continuously redefine your test plan; add, remove, or modify equipment to your lab topology; rerun your test cases; and generate reports. Taking time to identify the objectives and outline an assessment is critical before you ever step foot into the lab. Only after the following questions are answered should you begin to write a detailed test plan or build a lab topology:
What are the test triggers?
Who is requesting the test and what are their motives?
How much testing is necessary and what constitutes success?
What is the impact of test failure and what are the known risks?
What are the resources (people, lab equipment, and test tools) required to execute the test?
As discussed in Chapter 2, “Testing Throughout the Network Lifecycle,” a complimentary relationship betweennetwork testing and design functions exists in organizations that execute enterprise architecture effectively. We explained how structured testing complements and validates design deliverables, by providing examples of the different types of test requests that you can expect throughout the network’s lifecycle.This chapter will begin to fill in the practical details of what is necessary to build an effective approach toward different types of test requests. It begins with a suggested approach for assessing and scoping a test project, and offers guidance and best practices for the following considerations:
How to identify test case scenarios
How to develop a lab prototype
How to choose the proper test tools necessary to execute the different types of tests
How to write a detailed test plan
As with most technical undertakings, there is no absolute right way to approach systems testing. We do not promote ours as the only way to conduct successful testing. However, this is a proven method that will improve your chances of getting it right the first time.
Andy Sholomon, CCIE No. 15179, works as a Network Consulting Engineer (NCE) in Cisco’s Central Engineering Performance and Validation Testing team. He routinely plans and performs network testing for some of Cisco’s largest Enterprise customers. In his six years at Cisco, Andy has been involved in both planning and deploying some of the largest enterprise data centers in the United States. He has also worked with some of Cisco’s large service provider customers. Before joining Cisco, Andy worked as a Network Engineer in the global financial industry, spending 5 years at UBS in multiple roles, including security engineering, and worked as a Systems Engineer at Spear, Leeds & Kellogg (now a part of Goldman Sachs Group). Andy has been a speaker at the Cisco Live Networkers Conference. Besides the CCIE, Andy holds multiple industry certifications, including the CISSP and MCSE. Andy lives with his wife, daughter and Great Dane in Chapel Hill, North Carolina.