Welcome to the Intellitest 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 on Day Dream Travel
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. In the Intellitest classes we teach you how to overcome this.

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 Day Dream Travel URL	Day Dream Travel 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.

DATA.GUI.0019   Data Validation
(Note: Here's another style of test case writing)

Steps:

1. Open site
2. Go to quantity field, enter "1", purchase
3. Go to test data -- fields 1
4. Insert test data -- data type 1
5. Click PURCHASE
6. Verify Expected Results
7. Repeat steps 2-6 for remaining test data-types
8. Repeat steps 2-7 for remaining test data-fields

Test Data -- Fields:

1. First Name
2. Email
3. Postal Code
4. Amount Due

Test Data -- Data Types:

1. Alpha characters (try some, not all)
2. Null (leave field blank)
3. 0 (zero)
4. Numeric
5. Special characters: `~!@#$%^&*()_+-={}|[]\:";'<>?,./
6. Function keys (F1 -- F12)

Expected Results:

• Amount Due is not editable, presents an audible tone or error message.
• First Name and email allows alpha, numeric & special characters.
• Postal Code allows numeric only. Presents an audible tone or error message at tab or OK of form.
• Function keys in all fields are invalid and should present an audible tone or error message on tab or OK of form.
• Note: There is no specification for how this site should handle null fields. If the result is not intuitive, enter a bug.

Day in the Life Note:
As you can see from the site there is only one field. If you were doing a real test, there may be many more fields listed under TEST DATA -- FIELDS. For the purpose of this scenario, it has been reduced to just four fields and five data types -- just enough to give you an understanding that some types of testing is very tedious. Also note that there can be errors in the test cases, because test cases can be written prior to the software being ready and software changes while it is being developed. For example, the case states that there should be Name, Email, Postal Code and Amount Due on this form. Is the bug in the test case or in the site?