1. In the Senior Design Center
Software Testing
In the Senior Design Center
few easy questions:
1. Why test software?
2. Can you ship untested software in industry?

2. Software Testing Why now? Development method may require it
Opportunities to create a test plan as you develop
Possible need to design for testing

3. What We Expect Your project includes a test plan
Documented in your written reports
With updates included in your oral reports
What’s a test plan?
“Oh, we definitely plan to thoroughly test our project.”
“We’ll be using Selenium and JUnit to test our project.”
Not a Test Plan
Also Not a Test Plan

4. What We Expect Unit testing Acceptance testing
Usually automated / easily repeatable
Usually white-box tests
So, you can use metrics like code coverage to show you’ve done a good job.
Acceptance testing
Usually manual (still repeatable, but with effort)
You can automate yours, if you want.
Usually black box tests of the whole system
So, you can compare against requirements to show you’ve done a good job.

5. Acceptance Testing A suite of multiple acceptance test cases
Usually a few for each functional requirement.
Maybe a few supporting non-functional requirements
Performance / resource usage?
Response Time?
These can be written early
As you develop requirements
Revised and extended as the requirements mature
What does a test case look like?

6. (Bad) Acceptance Test Cases
Test ID
Description
Expected Results
Actual Results
restaurantSearch1
Preconditions:
The system is loaded.
Jason is a registered user of the system.
Jason has authenticated and is at the homepage.
Steps:
Enter a type of restaurant.
System reports all the nearby restaurants of that type.
(Even if they are not as expected, or not yet implemented)
Unique
IDs!
Specific Steps and Results?

7. (Better) Acceptance Test Cases
Test ID
Description
Expected Results
Actual Results
restaurantSearch1
Preconditions:
The system is loaded.
Jason is a registered user of the system.
Jason has authenticated and is at the homepage.
Steps:
Enter “sushi” as the restaurant type.
System reports all the nearby sushi restaurants.
Still vague.
Better

8. (OK) Acceptance Test Cases
Test ID
Description
Expected Results
Actual Results
restaurantSearch1
Preconditions:
The system is loaded.
Jason is a registered user of the system.
Jason has authenticated and is at the homepage.
Steps:
Enter “sushi” as the restaurant type.
System reports: Sushi Hut (1 mile away) McSushi (3 miles away) Sushi King (4 miles away)
Good
But, how do you know you’ll get this?

9. Acceptance Testing Acceptance tests are usually supported by test data
Created by the team
Should be simple (so you and anyone else can tell what the right system behavior should be)
Acceptance test plan should include
Explanation of what you’re testing
How to set up for each suite of tests
What the test data is (are) like
The table of test cases
Discussion of test results.

10. Pro-Tip for Acceptance Testing
Don’t copy-and paste
From expected to actual results 

11. Pro-Tip for Acceptance Testing
Don’t copy-and paste
From expected to actual results 
From one test case to another 
This creates a maintenance problem.

12. Pro-Tip for Acceptance Testing
Don’t copy-and paste
From expected to actual results 
From one test case to another 
This creates a maintenance problem.
Instead, maybe factor common steps into the test set-up.

13. Unit Testing
With unit testing, we take advantage of what we know about the implementation.
We have access to the source code
We know how it’s organized into components
We know the dependency structure
So, we can do things we couldn’t do in acceptance testing
We can test individual components (in an order that makes sense)
We can measure code coverage (to see if we’ve done a good job)

14. Unit Testing Coverage expectations
The Course Pack says to plan for 70% coverage
But, the right coverage targets depend on the component under test
You could achieve 100% code coverage … and still have bugs

15. Unit Testing Your project will probably have different components
Maybe in different languages
Maybe requiring different approaches to unit testing
This is going to require some explanation
Unit test plan should include
Explanation of what you’re testing
Explanation of your choice of testing tools
How to run the unit tests
Code coverage report
Discussion of test results

16. Testing in OPR 1 You can report on: Testing strategy Testing tools
Progress so far
A glimpse into your acceptance test plan?
Number of tests, how they’re organized, number passing?
Preliminary unit test results?
Number of tests, how they’re organized, coverage?

17. Testing in Senior Design
Every project is different
You’ll need to figure out the right way to assure the quality of your project
With help from your sponsor
… and your technical advisors
This may include some additional forms of testing
Performance testing?
Usability testing?
Stress testing?
Ask questions and get help early
Testing resources on the SDC website