Welcome to a typical Day in the Life of a Tester. This hands-on scenario will give you a chance to explore what being a tester is like.

It is not necessary for you to do this scenario in precisely the eight hours described below. The scenario is described in terms of an eight hour day just as an example. You could run the scenario in one hour if you like.

Now, enter the building; walk to your cubicle, and begin your day as a Software Tester...

9:00am	Arrive at work; boot up computer; check email. Email From: Testing Manager Subject: Testing Today We've gotten a new build from Engineering of the Day Dream Travel site. Please run test case buy.func.0001 and let me know the results by noon. Thanks. Day in the Life Note: What is unstated in this email and you are expected to know is that you need to report the results in the test case database or via email and enter all bugs found in the bug database. Note that it is common that you are given incomplete instructions and that you need to interpret what is being said.
9:10am	Begin testing using test case buy.func.0001
10:15am	Check email. Email From: Testing Manager Subject: Change in priorities Thanks for looking at the Buy feature. Will you take a look at field validation? Please run test DATA.GUI.0019. Day in the Life Note: This test case is less detailed than the first one you ran but an example of what you might actually get. See what you can do with it.
10:20 am	Begin testing using test case DATA.GUI.0019.
11:45 am	Remember to send your boss an email with the results from that first test.
12:00 am	Lunch (sometimes it's with other testers and engineers, and other times -- especially in the final 3 weeks of a project -- it's at your desk as you continue running a test.)
1:00 pm	Return from lunch, and check email. Email From: Testing Manager Subject: Problem area I apologize for continuing to change your priorities, but... Marketing is having difficulty with the Search feature. Will you please take a look at it and see what you can find? This is a new feature and we do not have any written test cases for it. Please just ad-hoc through the area and see what you can find. Please email me with your results and enter all bugs in the bugbase. Thank you.
1:05 pm	Decide whether you finish the data validation test or check out the search problem. (You check out the search problem.)
1:10 pm	Begin ad-hoc testing of the search area ("ad-hoc" -- also called "kamikaze" -- testing means that you test it without a test case or guideline. Use your knowledge of how the web works and your intuition).
3:30 pm	Check email. No new messages.
3:31 pm	Email results from your ad-hoc test to your boss.
3:45 pm	Continue running the data validation test DATA.GUI.0019.
5:10 pm	Enter the bugs that you found in the bug database.
5:45 pm	Since this is Friday, write a status report email to your boss.
6:00 pm	Go home.

How does this day differ from an ordinary day?

• Ideally, you will be assigned an area to test (like printing or purchasing) and given the time to complete an area before testing another area. However, the above shifting of priorities does happen a lot.
• It is highly unlikely that you will be given a test case as detailed as the first one. In some companies, you get something like the second one, a checklist, or an outline. It's very common to only ad-hoc test.
• It is likely that you will also be verifying bugs (i.e., making sure that bugs that the engineers fixed are really fixed).
• It is unlikely that you will get the above type of emails from your boss with specific directions. It will be assumed that you know what to do with test results and bugs. You may not be asked with "please" and "thank you", and it is rare that you would get an apology for changing your priorities.
• Not all companies collect test results; all should collect bug reports.
• In most companies testers are not tied to the clock. It is rare that a time clock is used. You are responsible for working an eight hour day, although it may or may not be required to be eight consecutive hours at your desk. Some phases of the project are slow and others are very busy. In the slow phases, expand your brain by reading testing books, running tutorials for apps you use (word processing, spreadsheet, database, or test tools), or learn more about the type of software you are building. In the busy times, be prepared to work late, eat pizza for dinner at work, and work some weekends. It's hard, but it can also be fun.
• In most companies, testers are encouraged to mingle with the engineers and learn about the software that the engineers are creating and the areas that the engineers are worried about. Test these areas first. If the engineer thinks there are bugs in an area, there probably are. However, in some companies there is an adversarial relationship between testers and engineers. The testers are always the "bearers of bad news". Just be aware that this can still occur.

Day In The Life Of A Tester -- Test Case 1

Test Case ID	buy.func.0001
Summary	Buy a trip
Creation Status	Completed
Test Case Priority	1-High
Main Test Area	Purchasing
Estimated Effort	1 Hour
Sample Data Location	None
Test Conditions	None
Browsers	Netscape and Explorer

Steps:

#	Action	Expected Result
1	Start computer	Computer starts, Win95, 98 or NT is visible
2	Bring up Browser
a	Go to task bar	Grey task bar appears at bottom of desktop
b	Click "Start"	Win95/98/NT pop up menu appears
c	Drag mouse over "Programs"	Additional menu with application folder icons appears
d	Drag mouse over "Netscape"	Additional menu with Netscape Navigator application icon appears
e	Drag mouse over "Netscape Navigator" and release mouse	Navigator browser starts up
3	Go to site
a	Click the e Luxury URL	e luxury site appears
4	Purchase Trip
a	Scroll down site	Site moves vertically in the browser window.
b	In Quantity field, enter 1	"1" appears in the quantity field.
c	Click Purchase button	Form disappears, new page appears with purchase confirmation, correct number "1" and correct price "$1,450" and correct tax at 10% is "$145"
d	Click Purchase button	Form disappears and order confirmation page with unique order confirmation number appears. Page has buttons to return to shopping, home, sitemap or your account.

Day in the Life Note:
Other tests that are closely related and should be done in conjunction with this are:

1. Buy, then modify.
2. Buy, then cancel the purchase.
3. Field Validation of all fields in the Purchase form.
4. Sequences, for example: Buy, Buy, Buy, Modify, Buy, Cancel, Buy, Buy, Buy, Cancel, Cancel, Cancel.
5. User Scenario: How would a new travel user use this product?

The following tests are more rigorous and are performed once the main functionality of the application is solid. These tests are related to the Buy test:

1. Stress: Enter 100+ characters in each field
2. Stress: Buy 100+ new trips (like a travel agent would do)
3. Stress: Create a low memory condition, then Buy
4. Stress: Create a low disk space condition, then Buy
5. Hardware Compatibility: Try browsing the site and purchasing items on different hardware (486, Pentium 100, Pentium 200 etc.)
6. Software Compatibility: Try browsing the site and purchasing items on different operating systems (Win3.11, Win95, Win98, Win2000, WinNT, Macintosh), and/or on older and new beta versions of the browsers.
7. Software Compatibility: Try browsing the site and purchasing items while other applications are running (word processing, bug database, email, browsers), and switch back and forth between the applications.