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

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

3. Submitting Documents Senior Design Center - Fall 2015

6. Uploading a file Senior Design Center - Fall 2015

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

8. Getting Feedback Senior Design Center - Fall 2015

11. Senior Design GIT Policies Senior Design Center - Fall 2015

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

13. 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

16. Software Testing In the Senior Design Center

17. 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=445708106http://en.wikipedia.org/w/index.php?title=Software_testing&oldid=445708106 Senior Design Center - Fall 2015

18. 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

19. 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

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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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 2015 100% coverage! Great!

27. 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

28. 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

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

30. 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

31. 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

32. Some advice: test often Senior Design Center - Fall 2015

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