Understand the system As you work to figure out how you're going to test, you need to understand what

you're testing. I'm a visual learner, so for me that means pictures -- and lots of them. If diagrams don't exist, I'll get someone to start drawing them on whit eboards and I take pictures. If I need to, I'll start drawing some of them mysel f. I find pictures to be the easiest way to identify misunderstandings and missi ng information. There are three things I feel like I need to know before I'm comfortable with th e application I'm testing: 1. What are the various applications, data sources, services and protocols in the system? 2. What do the network and hardware infrastructure look like? 3. What do the use cases and business workflows look like? Some common places to find this information include network diagrams, deployment diagrams, activity diagrams, dataflow diagrams, use case diagrams and business workflows. As I start collecting these views of the system, I'll annotate each o ne with the little details that I uncover. I'll also create a corresponding list of open questions. Some initial questions to answer around the various applications, data sources, services and protocols in the system include the following: * What applications and services comprise the system? Which are internal and which are external? * Where is data stored and read from? In what formats? * What software processes are involved? How often do they run? * What are the differences between the production environment and the enviro nment you're testing? * What are the process names, queue names, Web service names and method call s that are used for the different pieces to communicate? What are the various pr otocols used? * Are there licensing issues or data limitations that you need to be aware o f? Some initial questions to answer around the network and hardware infrastructure: * What are the servers and appliances/devices, and how are they all connecte d? What are the various names, specifications and configurations for each? * Is there any load balancing? Where is it and what kind? * If the test environment is different than the production environment, do w e know the differences between the two? Do we have this information for both? Some initial questions to answer around what the system does and who uses it: * Who uses this system and why? * What types of transactions take place? * Are there any calendar-based transactions (end of day, monthly, yearly, et c.)? As you take in all this information, it's easy to get overwhelmed. As a performa nce tester, you don't need to be an expert in each of these areas, but you do ne ed to understand the basics. Developing some foundation knowledge will be helpfu l, but mostly you just need to be willing to research new items and concepts as they come up. As you work through the information start a list of assumptions (e.g., "currentl y XML is not cached; in the future it may be"), collect notes on the differences

different s erver programs co-located on the same machine) and capture some of the key metri cs you think will be helpful when it comes to tuning or debugging (e.g.. database calls.). memory/ CPU usage.. live sessions versus active sessions.between your test environment and the production environment (e.g. etc. .

Sign up to vote on this title
UsefulNot useful