1. Software Testing Fundamentals
MTA Exam
Software Testing Fundamentals

2. 98-379: OBJECTIVE 3
Create Software Tests

3. LESSON 3.5
Define Appropriately Scoped Test Cases

4. overview Lesson 3.5 In this lesson, you will review the following:
Boundary conditions
Level of detail
Validity

5. GUIDING questions Lesson 3.5
What is a boundary test?
What is a “happy path” test case?
What type of test generally requires detailed steps?
Answers:
Tests that focus on how the software behaves when data are at or near their minimum or maximum levels.
A positive test; a test using data or inputs that are expected or typical.
Manual test.

6. Lecture Lesson 3.5 Test case design considerations
In many situations, the possible permutations of an application’s data—and the possible paths through the code—are very large.
Consider an application that asks the user to input a few numbers. Theoretically, there are an infinite number of possible inputs!
Therefore, developers and testers have to accept that complete testing may be impossible, or at least impractical.
Test case design is about selecting test cases that have a high probability of catching most defects.

7. Lecture Lesson 3.5 Happy path test cases
In test-driven development, including agile models, tests are written before a unit is coded. Often, the first tests created are for standard, expected data.
For example, a developer creating a website login interface might start by creating some tests using valid username/password combinations— tests that are expected to pass.
Some testers and developers refer to this as a happy path test case.
While happy path tests are a valid starting point, additional tests are clearly necessary.
For example, what happens when an invalid username is entered?
Be sure students get the notion behind the name “happy path.” This is the test case that makes us (and our code happy)—we’re getting what it expects and what it was designed to use!
Obviously, happy path test cases are not very useful for verifying our code, but it can be an important starting point for developers developing a new class or unit.
Note: the term “happy path” can also be referred to as a positive test—a test that is expected to pass.

8. Lecture Lesson 3.5 Zero and null test cases
In the case of numeric data, the unit should be tested for correct handling of zero values.
Likewise, create tests to verify how null values are handled.
In the case of strings, it may be advisable to test with an empty string (“”)

9. Lecture Lesson 3.5 Boundary test cases
Boundary tests focus on how the software behaves when data are at or near their minimum or maximum levels. These boundary cases are also called edge cases.
For example, if a method makes calculations based on a month entered by the user (1 for January, 2 for February, etc.), what happens if the month is 13? Other possible boundary cases for this scenario would be 12 (the highest valid value), zero, and negative numbers.
In general, if values near boundaries are handled correctly, it is often the case that it should behave correctly in most other cases as well.

10. Lecture Lesson 3.5 Manual test cases
Because manual test cases may be executed by different testers at different times, it is important that the include enough detail to ensure consistency.
Manual test cases are broken down into discrete steps, each with a description of the action and the expected result.
Visual Studio allows you to attach a file with additional details or a screen shot to assist the tester.
The user login example might have a test case with these steps:
“Click the sign-in link in the top right corner.”
“Enter your user name into the prompt.”

11. Lecture Lesson 3.5 Manual test cases continued
The user login example might have a test case with these steps:
“Click the sign-in link in the top right corner.”
“Enter your user name into the prompt.”
“Type your password into the password prompt.”
“Click the ‘Sign In’ button.”

12. Lecture Lesson 3.5 Exploratory testing
Development teams sometimes supplement detailed testing with a more exploratory approach, allowing testers more freedom.
In these test cases, directions may be much more general and feature-focused:
“Sign in to the website.”

13. In-Class Activity Lesson 3.5
Scenario:
In response to customer demands, Woodgrove Bank has hired a development team to create a new online banking application that is easier to use and with more features. It is a very involved project so testing at every step is critical. The first feature to be tested is the behavior of the Debit method of the BankAccount class. The team must be sure that only a valid amount (one that is less than the account balance and that is greater than zero) is withdrawn from the account.
Directions:
Before beginning of the activity, you will need to download the source code and copy it into your new project, as directed.
Complete the Walkthrough: Creating and Running Unit Tests for Managed Code (
The first section of the Walkthrough (“Prepare the walkthrough”) includes instructions for getting the necessary code. For your reference, here is a link to the code:

14. In-class activity Lesson 3.5
Follow up:
After completing the walkthrough activity, share your experiences with a partner.
What difficulties did you experience?
How did you resolve them?
Identify three things you learned from this activity.
Share student responses in a class discussion. Help students make connections between what they learned and how it applies to either the scenario or typical workplace activities.
If there are unresolved difficulties, engage other class members in resolving the problems.

15. REVIEW Lesson 3.5 Can you answer these? What is a boundary test?
What is a “happy path” test case?
What type of test generally requires detailed steps?
Answers:
Tests that focus on how the software behaves when data are at or near their minimum or maximum levels.
A positive test; a test using data or inputs that are expected or typical.
Manual test.

16. ADDITIONAL RESOURCES Lesson 3.5
MSDN® Resources
Manual System Tests
Black Box and White Box Testing for Application Blocks
Test Automation Code Review Guidelines