Organizing a Test Plan

In last week's post, we took a look at a hypothetical software feature which would sort out Superballs among four children according to a set of rules.  I came up with forty-five different test cases from simple to complicated that would test various combinations of the rules. 

But a blog post is not a very easy way to read or execute on a test plan!  So in this week's post, I'll discuss the techniques I use to organize a test plan, and also discuss ways that I find less effective.

What I Don't Do

1. I don't write up step by step instructions, such as

Navigate to the login page
Enter the username into the username field
etc. etc.

Unless you are writing a test plan for someone you have never met, who you will never talk to, and who has never seen the application, this is completely unnecessary.  While some level of instruction is important when your test plan is meant for other people, it's safe to assume that you can provide some documentation about the feature elsewhere. 

2. I don't add screenshots to the instructions.

While having screenshots in documentation is helpful, when they are in a test plan it just makes the plan larger and harder to read.

3. I don't use a complicated test tracking system.

In my experience, test tracking systems require more time to maintain than the time needed to actually run the tests.  If there are regression tests that need to be run periodically, they should be automated.  Anything that can't be automated can be put in a one-page test plan for anyone to use when the need arises. 

What I Do:

1. I use a spreadsheet to organize my tests.

Spreadsheets are so wonderful, because the table cells are already built in.  They are easy to use, easy to edit, and easy to share.  For test plans that I will be running myself, I use an Excel spreadsheet.  For plans that I will be sharing with my team, I use a table in a Confluence page that we can all edit. 

You can see the test spreadsheet I created for our hypothetical Superball sorter here.  I'll also be including some screenshots in this post. 

2. I keep the instructions simple. 

In the screenshot below, you can see the first two sections of my test:

In the second test case, I've called the test "Amy- Large balls only".  This is enough for me to know that what I'm doing here is setting a rule for Amy that she should accept Large balls only.  I don't need to write "Create a rule for Amy that says that she should accept Large balls only, and then run the ball distribution to pass out the balls".  All of that is assumed from the description of the feature that I included in last week's post. 

Similarly, I've created a grouping of four columns called "State at End of Test Pass".  There is a column for each child, and in each cell I've included what the expected result should be for that particular test case.  For example, in the third test case, I've set Amy, Carol, and Doug to "any balls", and Bob to "Small balls only".  This means that Amy, Carol, and Doug can have any kind of balls at all at the end of the test pass, and Bob should have only Small balls.  I don't need to write "Examine all of Bob's balls and verify that they are all Small".  "Small balls only" is enough to convey this.

3. I use headers to make the test readable. 

Because this test plan has forty-five test cases, I need to scroll through it to see all the tests.  Because of this, I make sure that every section has good headers so I don't have to remember what the header values are at the top of the page. 

In the above example, you can see the end of one test section and the beginning of the final test section, "Size and Color Rules".  I've put in the headers for Amy, Bob, Carol, and Doug, so that I don't have to scroll back up to the top to see which column is which. 

4. I keep the chart cells small to keep the test readable. 

As you can see below, as the test cases become more complex, I've added abbreviations so that the test cases don't take up too much space:

After running several tests, it's pretty easy to remember that "A" equals "Amy" and "LR" equals "Large Red". 


5. I use colors to indicate a passing or failing test.  The great thing about a simple test plan is that it's easy to use it as a report for others.  I'll be talking about bug and test reports in a future post, but for now it's enough to know that a completed test plan like this will be easy for anyone to read.  Here's an example of what the third section of the test might look like when it's completed, if all of the tests pass: 

If a test fails, it's marked in red.  If there are any extra details that need to be added, I don't put them in the cell, making the chart hard to read; instead, I add notes on the side that others can read if they want more detail. 

6. I use tabs for different environments or scenarios. 

The great thing about spreadsheets such as Google Sheets or Excel is that they offer the use of tabs.  If you are testing a feature in your QA, Staging, and Prod environments, you can have a tab for each environment, and copy and paste the test plan in each.  Or you can use the tabs for different scenarios.  In the case of our Superball Sorter test plan, we might want to have a tab for testing with a test run of 20 Superballs, one for 100 Superballs, and one for 500 Superballs. 

Test plans should be easy to read, easy to follow, and easy to use when documenting results.  You don't need fancy test tools to create them; just a simple spreadsheet, an organized mindset, and an ability to simplify instructions are all you need.

Looking over the forty-five test cases in this plan, you may be saying to yourself, "This would be fine to run once, but I wouldn't want to have to run it with every release."  That's where automation comes in!  In next week's post, I'll talk about how I would automated this test plan so regression testing will take care of itself. 

How to Design a Test Plan

Being a software tester means much more than just running through Acceptance Criteria on a story.  We need to think critically about every new feature and come up with as many ways as we can to test it.  When there are many permutations possible in a feature, we need to balance being thorough with testing in a reasonable amount of time.  Automation can help us test many permutations quickly, but too many people jump to automation without really thinking about what should be tested.

In this week's post, I'm going to describe a hypothetical feature and talk about how I would design a test plan for it.

The feature is called the Superball Sorter, and here is how it works:

• Superballs can be sorted among four children- Amy, Bob, Carol, and Doug
• The balls come in two sizes: large and small
• The balls come in six colors: red, orange, yellow, green, blue, and purple
• The children can be assigned one or more rules for sorting: for example, Amy could have a rule that says that she only accepts large balls, or Bob could have a rule that says he only accepts red or orange balls
• Distribution of the balls begins with Amy and then proceeds through the other children in alphabetical order, and continues in the same manner as if one was dealing a deck of cards
• Each time a new ball is sorted, distribution continues with the next child in the list
• The rules used must result in all the balls being sortable; if they do not, an error will be returned
• Your friendly developer has created a ball distribution engine that will create balls of various sizes and colors for you to use in testing

Here's a quick example:  let's say that Carol has a rule that she only accepts small balls.

The first ball presented for sorting is a large red ball.  Amy is first in the list, and she doesn't have any rules, so the red ball will go to her.

The next ball presented is a small blue ball.  Bob is second on the list, and he doesn't have any rules, so the blue ball will go to him.

The third ball is a large purple ball.  Carol is next on the list, BUT she has a rule that says that she only accepts small balls, so the ball will not go to her.  Instead the ball is presented to Doug, who doesn't have any rules, so the large purple ball will go to him.

So what we have after a first pass is:
Amy: large red ball
Bob: small blue ball
Carol: no ball
Doug: large purple ball

Since Doug got the most recent ball, we'd continue the sorting by offering a ball to Amy.

How should we test this?  Before I share my plan, you may want to take a moment and see what sort of test plan you would design yourself.  Then you can compare your plan with mine.

My test plan design philosophy always begins with testing the simplest possible option, and then gradually adding more complex scenarios.  So, I will begin with:

Part One:  No children have any rules

• If no children have any rules, we should see that the balls are always evenly distributed between Amy, Bob, Carol, and Doug in that order.  If we send in twenty balls, for example, we should see that each child winds up with five.  

Next,  I will move on to testing just one type of rule.  There are only two parameters for the size rule, but six parameters for the color rule, so I will start with the size rule:

Part Two: Size rules only

We could have anywhere from one child to four children with a rule.  We'll start with one child, and work up to four children.  Also, one child could have two rules, although that would be a bit silly, since the two rules would be accepting large balls only and accepting small balls only, which would be exactly the same as having no rules.  So let's write up some test cases:

A.  One child has a rule

• Amy has a rule that she only accepts large balls.  At the end of the test pass, she should only have large balls.
• Bob has a rule that he only accepts small balls.  At the end of the test pass, he should only have small balls.

B. Two children have rules

• Amy and Bob both have rules that they only accept large balls.  At the end of the test pass, they should only have large balls.
• Carol has a rule that she only accepts large balls, and Doug has a rule that he only accepts small balls.  At the end of the test pass, Carol should have only large balls, and Doug should have only small balls.

C. Three children have rules

• Amy, Bob, and Carol have rules that they only accept small balls. At the end of the test pass, they should only have small balls.
• Amy and Bob have rules that they only accept small balls, and Carol has a rule that she only accepts large balls.  At the end of the test pass, Amy and Bob should have only small balls, and Carol should have only large balls.
• Amy has a rule that she accepts both large balls and small balls, and Bob and Carol have rules that they only accept large balls.  At the end of the test pass, Amy should have both large and small balls (assuming that both were distributed during the test pass), and Bob and Carol should have only large balls.

D. Four children have rules

• Amy and Bob have rules that they only accept large balls, and Carol and Doug have rules that they only accept small balls.  
• All four children have a rule that they only accept large balls- this rule should return an error

Now that we have extensively tested the size rule, it's time to test the other rule in isolation:

Part Three: Color rules only

As with the size rule, anywhere from one to four children could have a color rule.  But this rule type is a bit more complex, because each child could have from one to six color rules.  Let's start simple with one child and one rule:

A. One child has one rule

• Bob accepts only red balls
• Bob accepts only orange balls
• Bob accepts only yellow balls
• Bob accepts only green balls
• Bob accepts only blue balls
• Bob accepts only purple balls

This tests that each color rule will work correctly on its own.  

B. One child has more than one rule

• Carol accepts only red and orange balls
• Carol accepts only red, orange, and yellow balls
• Carol accepts only red, orange, yellow, and green balls
• Carol accepts only red, orange, yellow, green, and blue balls
• Carol accepts only red, orange, yellow, green, blue and purple balls (which, again, is sort of silly, because it's like having no rule at all)

C. Two children have color rules

• Amy and Bob both accept only red balls
• Amy accepts only red balls and Bob accepts only blue balls
• Amy accepts only red and green balls and Bob accepts only blue and yellow balls
• Carol accepts only red, orange, and yellow balls, and Doug accepts only green balls

Note that there are MANY more possibilities here than what we are actually testing.  We are merely trying out a few different scenarios, such as one where one child has three rules and one child has one.

D. Three children have color rules

• Amy, Bob, and Carol accept only red balls
• Amy accepts only red balls, Bob accepts only orange balls, and Carol accepts only yellow balls
• Amy accepts only red balls, Bob accepts only red and orange balls, and Carol accepts only red, orange, and yellow balls

The last scenario above exercises a path where the children share one rule but not other rules.

E. Four children have color rules

• Amy, Bob, Carol, and Doug only accept purple balls- this should return an error
• Amy only accepts red and yellow balls, Bob only accepts orange balls, Carol only accepts yellow and blue balls, and Doug only accepts green balls- this should also return an error, because no one is accepting purple balls
• Amy only accepts red balls, Bob only accepts red and orange balls, Carol only accepts yellow balls, and Doug only accepts yellow, green, blue, and purple balls

Now that we've exercised both rule types separately, it's time to try testing them together!  Here's where things get really complicated.  Let's try to start simply with scenarios where each child has either a color rule or a size rule, but not both, and move on to more complex scenarios from there:

Part Four: Size and color rules

A. Children have one size rule or one color rule

• Doug only accepts large balls, and Bob only accepts red balls
• Doug only accepts large balls, Bob only accepts red balls, and Carol only accepts small balls
• Doug only accepts large balls, Bob only accepts red balls, and Carol only accepts small balls, and Amy only accepts yellow balls
• Amy and Doug only accept large balls, Bob only accepts small balls, and Carol only accepts purple balls
• Amy and Doug only accept large balls, and Bob and Carol only accept purple balls- this should return an error, because there's no one to accept any small balls other than the small purple balls

B. Children have both a size and a color rule

• Amy only accepts large red balls
• Amy only accepts large red balls, and Bob only accepts small blue balls
• Amy only accepts large red balls, Bob only accepts small blue balls, and Carol only accepts large green balls
• Amy only accepts large red balls, Bob only accepts small blue balls, Carol only accepts large green balls, and Doug only accepts small yellow balls- this should return an error

C. Children have a size rule and more than one color rule

• Amy only gets large red, orange, and yellow balls, Bob only gets small red, orange, and yellow balls, Carol only gets large green, blue, and purple balls, and Doug only gets small green, blue and purple balls
• Try the above scenario, but remove the large yellow ball from Amy's list- this should return an error, because there's no one to accept the large yellow balls

D. Children have more than one size rule and more than one color rule

• Amy: large red, large blue, small yellow; Bob: large orange, large purple, small green; Carol: large yellow, small red, small blue; Doug: large green, small orange, small purple
• Try the above scenario, but add a small purple ball to Amy's rules
• Try the first scenario, but change Doug's small purple rule to a large purple rule- this should return an error, because now there's no one to accept the small purple balls

And there you have it!  Forty-five rules that exercise a great many of the options and permutations that the Superball Sorter offers.  If you have read this far, you must enjoy testing as much as I do!  

How did my test plan compare to yours?  Did you think of things I didn't?  Be sure to let me know in the comments section!

You may have noticed that while this test plan is complete, it's not that easy to read, and it doesn't provide any way to keep track of test results.  Next week I'll talk about how to organize the test plan so you can run it quickly and record results easily.  

Localization Testing

If your app is used anywhere outside your country of origin, chances are it uses some kind of localization strategy.  Many people assume that localization simply means translation to another language, but this is not the case.  Here are some examples of localization that your application might use:

Language: different countries speak different languages.  But different regions can speak different languages as well.  An example of this would be Canada: in the province of Quebec, the primary language spoken is French, and in the other provinces, the primary language spoken is English.

Spelling: even when two areas speak the same language, the spelling of words can be different.  For example, "color" in the US, as opposed to "colour" in Canada and the UK.

Words and idioms: words can vary even in a common language.  In the UK, a truck is a lorry, and a car's trunk is a boot.  In the US, to "table" a topic means to stop talking about it until a later meeting.  But in the UK and Canada, to "table" a topic means to start talking about it in the current meeting- the complete opposite of what it means in the US!

Currency: different countries will use different currencies.  But this doesn't just mean using a different symbol in front of the currency, like $ or £.  The currencies can also be formatted differently.  In the US, fractions of a dollar are separated with a dot, and amounts over one thousand are separated with a comma.  In the UK, it's the opposite.  So what would be written as 1,000.00 in the US would be written as 1.000,00 in the UK.

Date and Time Formats:  in the US, dates are written as month/day/year, but in the UK, dates are written as day/month/year.  The US generally writes times using AM and PM, but many other countries use 24-hour time, so what would be 1:00 PM in the US would be 13:00 elsewhere.

Units of Measure: the US usually uses US Customary units, such as pounds for weight and feet and inches for height.  Most other countries will use the metric system for these measurements.  Most countries measure air temperature in Celsius, while the US uses Fahrenheit.

Postal Codes and Phone Numbers: these vary widely from country to country.  See my posts on international phone numbers and postal codes for some examples.

Images: pictures in an application might need to be varied from country to country, but there are some considerations.  For example, if your application was to be used internationally, you might not want to include a picture of a building with an American flag in the front.  Or if your app were to be used in religiously conservative countries, you might not want a picture of a person in a sleeveless shirt.


Testing for Localization

The first step in localization testing is to determine exactly what will be localized.  Your company may decide to localize for date and time, postal codes, and phone numbers, but not for language.  Or a mobile app may choose to only use other languages that are built into the device, so that the text of the app would be in one language, but the buttons for the app would be in the user's language.

If your app will be using other languages, gather all the texts you will need to be checking.  For example, if your app has menu items such as "Home", "Search", "Your Account", and "About Us", and your app will be localized for French and Spanish, find out what those menu items should be in French and Spanish.  It goes without saying that whoever has done the translations should have consulted with a native speaker to make sure that the translations are correct.

Next, create a test plan.  The simplest way to do this would be to create a spreadsheet, where the left column lists the different localization types you need to test and the top row lists the different countries.  Here is a very basic example:

Once your matrix is created, it should be very simple to run through your tests.  If you are testing on mobile, here's a helpful hint: When you switch your mobile device to a different language, make sure you know exactly how to switch it back if you don't recognize the words in the language you are switching to.  When I was testing localization for Mandarin, this was especially important; since I didn't know any of the characters, I had no idea what any of the menu items said.  I memorized the order of the menu items so I knew which item I needed to click on to get back to English.

Another important thing to watch for as you are testing is that translated items fit well in the app.  For example, your Save button might look perfectly fine in English, but in German it could look like this:

Once you have completed your localization testing, you'll want to automate it.  This could be done with UI automation tools such as Selenium.  You could have a separate test suite for each language, where the setup step would be to set the desired country on the browser or device, and each test would validate one aspect of localization, such as verifying that button texts are in the correct language, or validating that you can enter a postal code in the format of that country.  It would be very helpful to use a tool like Applitools to validate that buttons are displaying correctly or that the correct flag icon is displaying for the location.

Localization is a tricky subject, and just like software, it's hard to make it perfect.  But if you and your development team clarify exactly what you want to localize, and if you are methodical in your testing, you'll ensure that a majority of your users will be satisfied with your application.

Usability and Accessibility Testing

Two often-overlooked types of application testing are Usability Testing and Accessibility Testing.  Usability testing refers to the user experience: whether the app is intuitive and easy to use.  Accessibility testing refers to how easy it is for users with limited ability to use the application.  I'll be discussing both in today's post.  

Usability Testing

Usability testing is often called User Experience (UX) testing, and some larger companies have dedicated UX designers whose goal is to make their company's application pleasing to customers.  Even if you have UX people at your company, it's still a good idea to test your application with the user experience in mind.  Here are four ways to do that:

• Learn what the expected "User Journeys" are.  Usually when we are testing an application, we use it in ways that users won't, focusing on one feature or page at a time.  A good strategy is to find out how real users will be using the application and run through those scenarios.  For example, if you had an application that allowed users to order tickets for a movie theater, a user journey might be to log in, browse through the movies, look at the show times for one movie, select a show time, click the button to place the order, add the credit card information, and complete the sale.  By running through scenarios like this, you'll discover which areas might not be offering the best user experience.

• As you run through your user journeys, look for tasks that require many clicks or steps.  Could those tasks be done with fewer clicks?  This week, my husband was searching online for a new car.  He went to a website for a car manufacturer and was browsing through the different models.  Every time he changed to a new page, he was prompted to enter his Zip Code again.  That's not a great user experience!

• Test a new feature before you know what it's supposed to do.  This is a strategy that doesn't get used much any more, now that Test-Driven Development (TDD) is popular.  Even if your company isn't using TDD, you are probably present for the feature planning.  But I have found that it is sometimes helpful to take a look at a feature while knowing very little about it.  That is what your customers will be doing, so anything you find frustrating or complicated will probably also be frustrating or complicated for your customers.  An alternative to testing without knowing anything about the feature is to get someone who has never used the application to try it out.  Spouses, roommates, friends, and people from non-technical teams in your company are good candidates for this testing.  By watching them navigate through your site, you will find the tasks that might not be intuitive.  

• When you are testing, see if you can do everything you want to do in the application with the keyboard alone, or with the mouse alone.  People who use applications extensively want to be able to use them as quickly as possible.  A good example of this would be a customer service representative who has to fill out a form for every person who calls them.  If they are typing into each field, and they have to keep moving their hand over to the mouse to click the Submit button, this is a waste of their time.  If they can instead submit the form with the Enter key, their hands don't need to leave the keyboard.  

Accessibility Testing

Accessibility testing is important because fifteen percent of the population has some kind of disability, and we want our applications to be used by as many people as possible.  The three main types of accessibility testing you will want to do are Visual, Dexterity, and Auditory.  Here are some strategies for each. 

Visual Testing:

• Is the text large enough for most users?  Could users zoom and enlarge the text if needed?
• Do the images have text descriptions, so that visually impaired users who use text-to-speech features will know what the image is?
• Are the colors in the application distinctive enough that color-blind users won't be confused by them?  This helpful website allows you to load in a screenshot of your application and see what it will look like to a color-blind person.  I put a screenshot from an earlier blog post into the site, and here's what the buttons will look like to a red-green color-blind individual:
  

Dexterity Testing:

• Does your app require any complicated click-and-drag or highlight-and-click scenarios?  Imagine how difficult those would be to a person who had only one arm, or who had limited use of their hand.  Can you change the app so that those tasks can be accomplished in a simpler way?
• Are your buttons and links easy to click on?  If the buttons are too small, it may be difficult for someone with limited dexterity to click in the correct place.

Auditory Testing:

• Are there any places in your application that have videos?  If so, do those videos have captions so the hearing impaired will know what is being said?
• Are there places in your application that rely solely on sound effects in order for the user to know what is happening?  Try running the application with the sound turned off.  Do you miss any information while you are running through your test scenarios?

As software testers, we want our users to have as pleasant an experience as possible when using our application.  Usability and accessibility testing will help us ensure that our users will be able to accomplish what they want with our apps efficiently and easily.  

How to Design a Load Test

Last week, we talked about Performance Testing and various ways to measure the reliability and speed of your application.  This week we'll be talking about Load Testing.  Load testing is simply measuring how your application will perform under times of great demand.  This could mean testing scenarios of reasonable load, or it could mean testing with scenarios of extreme stress to find the limits of the application.

It's easy to find a load testing tool, create a few tests, and run them with a few hundred users to create metrics.  But this isn't particularly helpful unless you know why you are testing and how your results will help you.

So before you begin any load testing, it's important to ask the following questions:

• What kind of scenarios are you testing for?
• What is the expected behavior in those scenarios?

Let's imagine that you have a new website that sells boxes of chocolates.  You have noticed that your site is most active on Saturday mornings.  Also, Valentine's Day is coming, and you anticipate that you will have many more orders in the week leading up to that day.  In March, your company will be reviewed by a popular cable TV show, and you are hopeful this will lead to thousands of visits to your site.

With this in mind, you come up with the following expected behaviors:

• You would like your web pages to load in less than two seconds under a typical Saturday morning load
• You would like to be able to process five hundred orders an hour, which will get you through the busy Valentine's Day season
• You would like your site to be able to handle ten thousand visitors in an hour, which is how many people you expect to visit right after the TV show airs

The next step is to figure out what test environment you will use.  Testing in Production would obviously provide the most realistic environment, but load testing there might be a bad idea if your testing results in crashing your site!  The next most realistic option would be a test environment that accurately mimics your Prod environment in terms of the number of servers used and the size of the back-end database.  An ideal situation would be one in which this test environment was only used for your load testing, but this is not always an option; you may need to share this environment with other testers, in which case you'll need to be aware of what kinds of tests they are running and how they will impact you.  You'll also want to let other testers know when you are conducting your load tests, so they won't be surprised if response times increase.  

Once your test environment is ready, you can conduct some simple baseline tests.  You can use some of the strategies mentioned in last week's post to find out how long it takes for your web pages to load, and what the typical response times are for your API endpoints.  Knowing these values will help you gauge how large an impact a load scenario will have on your application.

Now it's time to design your tests.  There are a couple of different strategies to use in this process:

• You can test individual components, such as loading a webpage or making a single request to an API
• You can test whole user journeys, such as browsing, adding an item to a cart, and making a purchase

You'll probably want to use both of these strategies, but not at the same time.  For instance, you could measure how long it takes to load the home page of your website when you have ten thousand requests for the page in an hour.  In a separate test, you could create a scenario where hundreds of users are browsing, adding items to their cart, and making a purchase, and you could monitor the results for any errors.  

For each test you design, you'll want to determine the following:

• How many users will be interacting with the application at one time?
• Will those users be added all at once, or every few seconds?
• Will the users execute just one action and then stop, or will they execute the action continuously for the duration of the test?
• How long will the test last?

Let's design a test for the Valentine's Day scenario.  We'll assume that you have created test steps that will load the webpage, browse through three product pages, add one product to the cart, and make a purchase.  We already mentioned above that you'll want to be able to handle five hundred orders an hour, so we'll set up the test to do just that.  It's unlikely that in a real-world scenario all five hundred users would start the ordering process at the same time, so we'll set the test to add a new user every five seconds.  Each user will run through their scenario once and then stop.  The test will run for one hour, or until all five hundred users have completed the scenario.

Before you run your test, be sure that your test steps will return errors if they don't result in the expected response.  When I first got started with load testing, I ran several tests with hundreds of requests before I discovered that all of my requests were returning an empty set.  Because the requests were returning a 200 response, I didn't notice that there was anything wrong!  Make sure that your steps have assertions that will validate that your application is really behaving as you want it to.

Once you have the test steps in place, you've made sure that the steps have good assertions, and you have your test parameters set up with the number of users, the ramp-up time (how frequently a new user will be added to the test), and the test duration, it's time to run the test!  While the test is running, watch the response times and the CPU usage of your application.  If you start seeing errors or high CPU spikes, you can stop the test and make note of how high the load was when the spikes occurred.

Whether you need to stop the test early or whether the test completed successfully, you'll want to run a few test passes to make sure that your data is fairly consistent.  At the end of your testing, you'll be able to answer the question: can my website handle 500 orders in an hour?  If all of the purchases were completed with no errors, and if all of the response times were reasonable, then the answer is yes.  If you started seeing errors, or if the response times increased to several seconds, then the answer is no. If the answer is no, you can take the data you collected and share it with your developers, showing them exactly how many users it took to slow the system down.

Load testing should never be an activity you do to simply check it off of a list of test types.  When you take the time to consider what behaviors you want to measure, how you want your application to behave, what scenarios you can run to test those behaviors, and how you can analyze your results, you will ensure that load testing is a productive and informative activity.