in4matx 43 final review

verification vs validation

"implements idea properly" (ie verifies functionality) vs "implements the proper idea" (ie validates the particular functionality is useful)

black-box testing

specification-based testing (aka no access to code - box is black, cannot see code), tests overall functionality of system

white-box testing

structural testing (box is white, can see code); use source code to derive test cases, build a graph model of the system, state test cases in terms of graph coverage, different types of coverage (Node/statement coverage, edge/branch coverage, loop coverage, condition coverage, path coverage)

equivalence class partitioning

testing method whereby all possible input is divided into several classes/subdomains that are considered "equivalent" for error-finding purposes; classes/subdomains determined by intuition and looking at requirement specifications - subdomains should not overlap - example: when testing a function that multiplies two numbers together ---> multiplier(x,y), the subdomains that encompass the larger domain of all possible input would be 1. a negative number and a negative number, 2. a positive number and a negative number, 3. zero and a positive number, 4...so on and so forth.

inheritance - relationships between classes

the process of a child or sub-class taking on the functionality of a parent or superclass, also known as generalization. It's symbolized with a straight connected line with a closed arrowhead pointing towards the superclass.

model-definition of software engineering

the process of building a set of related models (aka abstractions) that represent the system-to-be

information hiding

hide design decisions that are most likely to change, thereby protecting other parts of the program from change if the design decision is changed

HCI stands for...?

human-computer interaction

UML stands for...?

unified modelling language

UML class diagrams

used in decomposing a system into modules known as classes typically used to: 1.) model domain concepts, 2.) create a detailed, 3.) object oriented design of the code

Dijkstra quote about testing

*"Program testing can be used to show the presence of bugs, but never to show their absence."* - true (in most cases) because there is an infinite amount of input for a large system and everything cannot possible be tested

high cohesion, low coupling & the benefits

*high cohesion* (functions in a module are related to each other) & *low coupling* (modules are separated by general purpose of functions inside of them, aka there are different modules for different overall purposes like receiving user input, printing output, etc.) - benefits of hc: easier to find things - benefits of lc: changes don't propagate (i.e., changing one thing will not require you to change the *all* modules), reuse is facilitated

software process models (remember: bwrisroxa lmao)

- *build-and-fix* - *waterfall* - *rapid prototyping* - *incremental* - *spiral* - *RUP* - *OSS* - *XP* - *agile*

Relationships between classes

- *inheritance* - *association* & multiplicity - *whole-part aggregation and composition*

other white box testing coverage

- *loop coverage*: every loop has been executed a number of times - *condition coverage*: every if statement executed T or F at least one - *fault injection*: test exceptions are raised - *path coverage*: every path is executed (impossible)

approaches to software design (remember SFROUS)

- *software architecture*: the set of principal design decisions about a system, different styles - *functional decomposition*: the entire system is decomposed into tasks and subfunctions - *relational database design*: similar to spreadsheet; organizes data in tables (or relations) - *object-oriented design and UML*: an "object" contains both data and methods & a "class" is a blueprint for making objects - *user-interface design*: UI mockups - *sketching*

Nielson's heuristics - HCI

- *visibility of system status*: shows what's going on with the system, ex: progress bars, confirmation of completed action, etc. - *match system words to the real world*: 'desktop', 'files', etc. - *user control and freedom*: navigation tools, undo/redo - *consistency and standards*: using icons that are known, ex: magnifying glass to search, heart/thumbs up to like - *error prevention*: greyed out buttons no longer clickable, warnings - *recognition rather than recall*: autocomplete, suggestions, etc., ex: when selecting a font, the name of the font is written in that font - *accelerators*: shortcuts - *minimalist design*: CRAP (contrast, repetition, alignment, and proximity) - *help users recognize and recover from errors*: warnings, 'incorrect password', 'must contain a number', etc. - *help and documentation*

whole-part aggregation and composition - relationships between classes

- aggregation: one object contains a set of other objects; these relationships are transitive and asymmetric (for ex. a crate object would contain bottle objects) - composition: a variant of aggregation which adds the property of existence dependency (for ex. can't have a room without a house)

what is QA (quality assurance) and its goals?

- all activities designed to measure and improve quality in a product; includes verification and validation - verification is making sure the idea is implemented properly - validation is making sure the right idea is implemented

OSS - software process models

- benefits: - weaknesses:

XP - software process models

- benefits: - weaknesses:

agile - software process models

- benefits: - weaknesses:

spiral - software process models

- benefits: 1 - good for new projects with uncertain, complex requirements 2 - risk-driven: building as you go along 3 - iterative - weaknesses: 1 - developers have to be competent at risk analysis

rapid prototyping - software process models

- benefits: 1 - improves of customer involvement 2 - more focus on getting the proper system out

incremental - software process models

- benefits: 1 - more customer feedback 2 - analyze, code, and test piece by piece; less errors

RUP - software process models

- benefits: 1 - risk-driven 2 - incremental 3 - lots of tool support 4 - provides a lot of guidance - weaknesses: 1 - maybe too much guidance??; is very complicated (need a process expert to implement it) and

waterfall - software process models

- benefits: 1 - promotes understanding of requirements irst 2 - disciplined, rigorous, formal 3 - lots of documentation 4 -Easy to track progress 5 - Good for short, simple projects w/ well -understood requirements 5 - Provided a starting point for other software process models - weaknesses: 1 - rigid, not amenable to change 2 - limited user input 3 - bad for long-term projects with any ambiguity in requirements (aka all of them!)

build-and-fix - software process models

- benefits: good for smaller projects that don't require maintenance - weaknesses: not rigorous enough for non-trivial projects

association - relationships between classes

- bidirectional and unidirectional association, whereby both classes are aware of each other and their relationship with the other, represented by a straight line between two classes and whereby one class is aware of the other and interacts with it, modeled with a straight connecting line that points an open arrowhead from the knowing class to the known class

storyboards - HCI

- depict sequences of user interactions - pictures of the user-interface - context the system is being used in - show emotions and motivations of end users

error vs fault vs failure

- human mistake in programmer's mind - like not accounting for leap year (error) - defect in code - code does not account for leap year(fault) - may not always happen depending on how frequently software is used or how it is used, but returning incorrect output or behaving incorrectly (failure)

personas (what are they, what are they used for, and what do you need to make a persona?) & scenarios - HCI

- personas are fictitious user archetypes which are used for design and user testing; are supposed to represent a type of user; a persona needs a picture, a real name, a nickname that exemplifies the type of user they are, and relevant characteristics - depict personas in certain situations; helps developers understand who is using the system and what their motivations are

why is HCI/UCD important?

- sales double - Traffic count more than doubles - user performance improve: cuts time by more than half

when is testing over?

- timeboxing: aim to reveal as many faults as possible in a fixed period of time with a fixed budget & target specific areas of the system - aim to meet the quality requirements for a project - when found bugs stabilizes to a number near zero after a number of tests - pepper the code with defects and observe how many of the added defects are discovered & from this, infer how many bugs are left to find, assuming that the added defects are similar to the actual ones

edge/branch coverage - white-box testing

1 float quizAverage(float[] scores) { 2 float min = 99999; 3 float total = 0; 4 for (int i = 0 ; i < scores.length ; i++) { 5 if (scores[i] < min) 6 min = scores[i]; 7 total += scores[i]; 8 } 9 total = total - min; 10 return total / (scores.length - 1); 11 } ¦-------------------¦ ↓ ¦ ①→②→③→④→⑤→⑥→⑦→⑧→⑨→⑩ →⑪ ¦ ¦-------⤴ ↑ ¦-----------------------¦ - test case: {1,2} - more likely to reveal logical errors, more thorough than node coverage, ensures all branches ¦----⤴ are taken

node/statement coverage

1 float quizAverage(float[] scores) { 2 float min = 99999; 3 float total = 0; 4 for (int i = 0 ; i < scores.length ; i++) { 5 if (scores[i] < min) 6 min = scores[i]; 7 total += scores[i]; 8 } 9 total = total - min; 10 return total / (scores.length - 1); 11 } ¦-------------------¦ ↓ ¦ ①→②→③→④→⑤→⑥→⑦→⑧→⑨→⑩ →⑪ ¦ ¦-------⤴ ↑ ¦-----------------------¦ (incorrect oof) - test case: {2} - select test cases such that every node ◯ in the graph is visited, selects minimal number of test cases

HCI: User Centered Design Methods

1.) *interview and observation* of people who will be using the system 2.) *personas*: fictitious user archetypes 3.) *scenarios*: fictitious stories about personas 4.) *storyboards*: fictitious comics about end users 5.) *swimming lane diagrams*: depicts task flow among objects and particpants 6.) *site maps*: shows the user-interface from screen to screen after clicking buttons/performing some action, i.e., the navigation through screens 7.) *mockups* and wireframes: difference is that wireframes are more bare and used more to determine layout while mockups include colors and other details to determine the look and feel 8.) *design guidelines*: standardization, based on research for well known usability 9.) *heuristic evaluation*: Nielson's heuristics 10.) *interaction design patterns*: established ways of completing some task like logging in, searching, creating a certain type of site etc. 11.) *user testing*

levels of testing

_ *unit testing*: testing of a single code unit - * functional/ integration testing*: testing of interfaces among integrated units - *system/ acceptance testing*: testing of complete system for satisfaction of requirements

multiplicity - relationships between classes

_______________ 웃²..* ------- ¹ |play game| ⎻⎻⎻⎻⎻⎻⎻⎻⎻ - need two or more players to initiate 1 game

test oracles

a mechanism for deciding whether a test case execution succeeds or fails - dictionary, calculator, another human, etc.; difficult to automate in some cases

Every design notation supports...?

abstraction

swimming lane diagrams - HCI

depicts task flow among objects and participants (both of whom are placed on the left column adjacent to the 'swimming lane' rows)

boundary value analysis

many errors at boundaries of input (for example, there may be confusion in the code between <,>, <=, etc.); boundary value analysis uses the same classes as equivalence partitioning, but tests at the boundaries of the classes, rather than just any element from the class -example: testing for zero (the boundary between positive and negative numbers)

what is A/B testing?

releasing different versions of a system and comparing the results of each (amount of users, user feedback, etc.) to possibly then change the system to the version that worked best