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

Agenda Submitting documents and getting feedback Testing Expectations Senior Design Center - Fall 2015

Submitting Documents Senior Design Center - Fall 2015

Uploading a file Senior Design Center - Fall 2015

Submission policies Word format for documents PowerPoint format for slides Only your last submission will be considered for grading Senior Design Center - Fall 2015

Getting Feedback Senior Design Center - Fall 2015

Senior Design GIT Policies Senior Design Center - Fall 2015

Senior Design GIT policies NC State’s GitHub Pre-created and available You give yourselves access More on this later Use of the repository we created for you is mandatory! Senior Design Center - Fall 2015

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

Software Testing In 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 Senior Design Center - Fall 2015

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

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

Mockups Help you gather and validate requirements and design Sketches, wireframes, mockups, prototypes, etc. Senior Design Center - Fall 2015

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

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

Functional test cases Test IDDescriptionExpected ResultsActual Results pokeTest1Preconditions: 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.” Functional/acceptance test cases Senior Design Center - Fall 2015

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

Code coverage Propagation, Infection, Execution (PIE) Model A test case can find a fault if: 1.The faulty code is executed 2.The faulty code infects the behavior/state of the code 3.The unexpected behavior propagates to observable output Senior Design Center - Fall 2015

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

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

OPR1 expectations For OPR presentations: Testing strategy Testing tool Expected coverage (and why?) Any progress so far? Senior Design Center - Fall 2015

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

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

Some advice: test often Senior Design Center - Fall 2015

Final notes Senior Design Center - Fall 2015 * Sorry, entomologists *