A Few Review Questions

SWE minor courses in the Spring SWE minor requirements: http://cs.gmu.edu/programs/undergraduate/minor/swe/ SWE courses available this spring: http://cs.gmu.edu/syllabus/syllabi-spring11/ Specifically, SWE443 will be taught: Notice schedule change to Weds 1:30 pm - 4:15 pm in Innovation Hall 316

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

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?)

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?)

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.

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

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

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)

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

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

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)

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?)

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)

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?

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

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

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.

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!!!!

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

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)

I hope you enjoyed the class. I did!