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. Senior Design Center - Fall 2015
Software Testing
Why now?
Development method may require it
Opportunities to create a test plan as you develop
Possible need to design for testing
Senior Design Center - Fall 2015

3. Senior Design Center - Fall 2015
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
Senior Design Center - Fall 2015

4. Senior Design Center - Fall 2015
What We Expect
Unit 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.
Senior Design Center - Fall 2015

5. Senior Design Center - Fall 2015
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?
Senior Design Center - Fall 2015

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. Senior Design Center - Fall 2015
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.
Senior Design Center - Fall 2015

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

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.
Tests should be independent of each other
Senior Design Center - Fall 2015

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.
Tests should be independent of each other
Instead, maybe factor common steps into the test set-up.
Senior Design Center - Fall 2015

13. Senior Design Center - Fall 2015
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)
Senior Design Center - Fall 2015

14. Senior Design Center - Fall 2015
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
Senior Design Center - Fall 2015

15. Senior Design Center - Fall 2015
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
Senior Design Center - Fall 2015

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. Traceability to Requirements
The quantity of black-box tests is not important!
Instead: are you thoroughly testing against the requirements?
A mapping of test cases to requirements can identify areas that need more testing
traceability matrix is one option
FR 1.1
FR 1.2
UC2-S3
UC3-AF1
testID1 X
testID2
testID3
testID4
Senior Design Center - Fall 2015

18. 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
Senior Design Center - Fall 2015