1. A Few Review Questions

2. SWE minor courses in the Spring
SWE minor requirements:
SWE courses available this spring:
Specifically, SWE443 will be taught:
Notice schedule change to Weds 1:30 pm - 4:15 pm in Innovation Hall 316

3. NOTE: These slides have NOT been updated for Fall 2010 – use the HTML based review instead of these. These are not complete!

4. System Test Case Enter invalid username in the input box
Able to enter text
Enter invalid password in the input box
Click login button
Error message displayed saying “invalid username or password”
Missing a “valid” test case. May want to specify types of invalid user names and passwords. Are there different equivalence classes? Combinations of various valid and invalid inputs? Empty fields?
What is wrong with this system test case? (formatting is wrong, but what else is?)

5. System Test Case Run the system and at any point press “cancel”
System cancels the action
Not specific enough to repeat.
What is wrong with this system test case? (formatting is wrong, but what else is?)

6. Many project managers fail
Many project managers fail. What are some of the main reasons projects fail and how can you lower your risk of failure?
Projects often fail not to technical ineptitude but more so due to “the human factor”: poor management, lack of planning and scheduling, inability to communicate within the team or with customers.

7. Problems with these requirements?
Users shall have an ATM Card
The game system shall provide a way to regenerate players and provide a scoring mechanism
The game system shall be fun to play
The game system may be accessible for the disabled
First one – can’t tell the user to do or not do something
Second one – split into two
Third one – not testabe; fun is ambiguous
Fourth one – “may” is not a requirement

8. What is the difference between design and analysis phase?
Analysis describes WHAT the system must do, design describes HOW the system will do it.
Analysis describes the problem domain, design describes the solution domain

9. Define coupling (and I don’t mean the terrible show from 2000)
Define cohesion
We want low coupling – modules/classes are not strongly intertwined, and therefore, changing one class should not result in many changes to other classes
We want high cohesion – a class should really be responsible for one thing, i.e. do not have a class that manages student grades AND the library system (this is bad)
Cast of Coupling (2000)

10. You and Dracula are both afraid if stakeholders get upset. Why?
They pay you…

11. Define critical path, then figure it out
Activity
Duration
Predecessor
1. Requirements collection 5
2. Screen Design 6 1
3. Report Design
4. Database Design 2
2,3
5. User Documentation 4
6. Programming
7. Testing 3
8. Installation
5, 7
9. Celebration Cruise 30 8
The critical path has no slack in the schedule. Anything that gets delayed along the critical path makes the whole project late.
Critical path: 1,2,3,4,6,7,8,9

12. Why is it necessary to quantify your plans?
What is expectation management? Why is it important? Give an example from your life where it was not done and the results?
No way to know when you have met your goals if you don’t
No way to know how you are progressing (no metrics to compare to)

13. Define verification Define validation Define IV&V
If my software requirements say the background should be blue, but I like red better, will I fail in verification, validation or both?
Verification = testing
Validation = making sure you built what the customer wanted
IV&V = Independent verification and validation; someone else does this besides the people writing the code or designing the system
You will definitely fail in verification, you may not fail in validation (your customer might not care about color…but then why did they make it a requirement?)

14. What is dynamic verification?
What is an example of static verification?
Which is FindBugs?
Dynamic = executing code
Static = static analysis tools or code reviews
Findbugs is static (never runs your code, as far as I know)

15. What is a stopping rule for testing? Or what do I mean by that?
A stopping rule is a rule to determine when you can “stop” testing. Older testing techniques provided no quantifiable stopping rule. Newer techniques using coverage criteria do provide a stopping rule
Using the older techniques, when do you stop testing?

16. What are some advantages and disadvantages of metrics based on lines of code?
Usually easy to calculate, objective
LOC do not necessarily transfer well between languages, projects or modules/classes – not every line of code has the same complexity

17. In the software fault, error and failure model, is a software fault still present if it does not generate a failure?
Yes… the failure may appear later or once new code is added, but the fault is there regardless.
Yes, you can have a fault and not have a failure

18. Define white box and black box testing
White box = you look at the code to generate test cases (often interested in some conditional coverage)
Black box = you do not look at the code when generating test cases.

19. Don’t forget… just knowing the answers to these questions is NOT enough. Look at the review guide online for the full list of things to know!!!!

20. Explain the steps in mutation testing How do I kill a mutant?
Create a set of test cases that all pass
Induce small changes to the program: mutants
Find tests that cause the mutant programs to fail: killing mutants
Failure is defined as different output from the original program
A mutant is a variation of my software created by changing lines of code. By introducing changes to the source code, I can detect if the testing done is thorough or not.
I kill a mutant by writing a test case that fails for the mutant code, but not for the original code

21. Diagrams Still know how to draw these diagrams? I would.
Use case diagram
Class diagram
Sequence diagram
Level 0 Context diagram
Activity diagram (with/without swimlanes)

22. I hope you enjoyed the class. I did!