Submission System & GIT + Testing Expectations Ignacio X. Domínguez Fall 2015

Submission System & GIT+

Testing Expectations

Ignacio X. Domínguez

Fall 2015

Senior Design Center - Fall 2015

Agenda

• Submitting documents and getting feedback

• Testing Expectations


Submitting Documents




Uploading a file


Submission policies

• Word format for documents

• PowerPoint format for slides

• Only your last submission will be considered for grading


Getting Feedback




Senior Design GIT Policies


Senior Design GIT policies

• NC State’s GitHub• http://github.ncsu.edu

• Pre-created and available

• You give yourselves access• More on this later

• Use of the repository we created for you is mandatory!


But why??? I want to use my own!

• We can give (read) access to sponsors

• We can monitor your progress• Insight into individual contributions

• Archival and hand-off



Software TestingIn the Senior Design Center


Software testing

Process of validating and verifying that a software program / application / product:

• Can be implemented.• Works as expected.• Meets the requirements that guided its design and development.

Software testing. (2011, August 19). In Wikipedia, The Free Encyclopedia. Retrieved 14:37, August 20, 2011, from http://en.wikipedia.org/w/index.php?title=Software_testing&oldid=445708106

http://en.wikipedia.org/w/index.php?title=Software_testing&oldid=445708106


Software testing

Black-box Testing• Knowledge/access to the code is

NOT needed• Should NOT reference code-level

details• Used to test:

• Requirements• Design• Functionality

White-box testing• Knowledge/access to the code is

REQUIRED• Used to test:

• Code correctness• Design


Black-box testing

• Testing starts at the very beginning… to help clarify customer requirements.

• Strategies:• Mockups• Use cases• Functional tests

Things I Need

Requirements

Ideas for your design


Mockups

• Help you gather and validate requirements and design

• Sketches, wireframes, mockups, prototypes, etc.


Use cases

• Help you validate requirements and design

• Serve as a guide for your implementation

• Can be easily translated to functional tests

• Should follow UML standards• Use Case Diagrams• Use Case Descriptions


Functional tests

• Also called Acceptance Tests

• Help you make sure your implementation meets all the requirements• Expected functionality• Alternative paths (error cases)

• Should be written early

• Should be run often

• Required!!!


Functional test cases

Test ID Description Expected Results Actual Results

pokeTest1 Preconditions:• The system is loaded.• Jason is a registered

user of the system.• Jason has

authenticated and is at the homepage.

Steps:1. Jason clicks “Poke”

beside his own name.

• Jason is presented with the following popup window message:

“You have successfully poked yourself. You are one sad

individual.”UniqueIDs!

Descriptive, Specific, Repeatable

Specific Expected Results!

(Even if they are not as expected)

Functional/acceptance test cases


White-box testing

• White-box testing needs code and should test code-level details

• Unit testing is a form of white-box testing

• Test “units” of code• Classes• Methods• Functions• …

• Automated using test frameworks (such as JUnit)

Things I Need Requirements Design Code Patience


Code coverage

• Propagation, Infection, Execution (PIE) ModelA test case can find a fault if:1. The faulty code is executed2. The faulty code infects the behavior/state of the code3. The unexpected behavior propagates to observable output

We can measure code execution with code coverage metrics!


100% is not enough

• Code example:function double(int value) {

return value + 1;}

• Unit test:AssertTrue(double(1) == 2)

• But wait! What happens when value = 2?

• Moral: having 100% coverage is not enough• Design your unit tests carefully

100% coverage! Great!


Testing expectations

• What are we looking for in Oral and Written Reports?• Testing strategy• Current testing progress (or lack of and why)• Tools and libraries used• Metrics

• Coverage• Number of unit tests written so far

• How many pass / fail• Number of functional test cases

• How many have been run and how many pass / fail

• How these metrics evolve over time• Any challenges or limitations


Testing expectations

• Additionally on the Written Reports

• Be very detailed!

• Justify your choice of testing tools

• Include a coverage report

• Include your complete acceptance test plan

• Discuss your testing results


OPR1 expectations

• For OPR presentations:

• Testing strategy

• Testing tool

• Expected coverage (and why?)

• Any progress so far?


Testing in Senior Design

When do we start testing? October?

You begin your black-box test plan as soon as you have requirements.

Your black-box test plan will evolve over the semester as requirements change


Testing in Senior Design

Anything else we can test?

You may want to automate your black-box test cases (e.g., Selenium)

You should also consider usability testing, stress testing, and other forms of testing relevant to your given project


Some advice: test often


Final notes

Read the Course Pack & Testing Resources Link on Website!

Ask questions early

* Sorry, entomologists

*