COMPSCI 169A Quiz 4

0.0(0)
studied byStudied by 0 people
0.0(0)
full-widthCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/97

flashcard set

Earn XP

Description and Tags

Modules 7 + 8

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

98 Terms

1
New cards

does behavior driven design emphasize validation or verification

validation (building the right thing)

2
New cards

what is the Connextra format for user stories

As a ( type of stakeholder )

So that I can ( achieve some goal )

I want to ( do some task )

3
New cards

what does the SMART acronym stand for in relation to user stories

Specific, Measurable, Achievable, Relevant, Time-Boxed

4
New cards

how do we most effectively conceptualize a UI and simultaneously work with customers

lo-fi UI mockups via pen and paper or whiteboard → storyboards to facilitate clicking on links and moving between pages

5
New cards

how do we measure productivity when working on user stories

assign points to each and measure velocity in each iteration

6
New cards

what is a spike in relation to Agile development

a short investigation into a technique or problem (eg. new tech or library) that the team wants explored before starting to code

7
New cards

what is the backlog in terms of user stories and Agile development

collection of stories that have been prioritized and assigned points but have not been started in this iteration

8
New cards

what is the “icebox” category in Pivotal Tracker

contains user stories that have not yet been prioritized or started

9
New cards

what is the “current” category in Pivotal Tracker

stories in progress

10
New cards

when is a task in Pivotal Tracker moved from the icebox into the backlog

when it goes from estimated to prioritized

11
New cards

when is a task in Pivotal Tracker moved from the backlog into current

when it goes from being assigned to being started

12
New cards

true or false: you should track bugs/debugging in Pivotal Tracker and assign points to it

false

13
New cards

true or false: you should not use Pivotal Tracker as a to-do list

true

14
New cards

what is the framework that allows you to transform user stories into real tests

Cucumber

15
New cards

how many scenarios should a singular feature have

at least one

16
New cards

a user story typically maps to how many features

one

17
New cards

how many steps does each scenario usually have

3-8

18
New cards

how do step definitions use Ruby code to test steps in Cucumber user story tests

matching regexes

19
New cards

what are the five step keywords to make scenarios specific

Given, When, Then, And, But

20
New cards

true or false: the five step keywords in Cucumber scenarios are interchangeable because they are all aliases for the same methods

true

21
New cards

what is a happy path in a Cucumber scenario

when everything goes according to plan

22
New cards

what is a sad path in a Cucumber scenario

when things do not go according to plan; it simulates when a user makes a mistake or does not have proper set up or accesses for a given feature

23
New cards

what is the tool that simulates a headless browser to help with testing

Capybara

24
New cards

how do you form capture groups in Regex so that you can capture parts of a string or step def so that you can use it in the “do” block of your test?

([^”]*) → looks for any sequence of characters that is not a double quote

eg. When /^(?:|I)fill in "([^"]*)" with "([^"]*)"/ do |fld, val|

25
New cards

what is the object in Capybara that returns a representation of a top-level HTML element that supports expectations (eg. expect(...).to have_css('#some_div') → what is ...?

page

26
New cards

what tool allows you to “time travel” to support time- or date-sensitive features

Timecop

27
New cards

what tag must you include before every scenario that tests a page whose functionality relies on JavaScript

@javascript

28
New cards

what is an imperative scenario

long, includes specifics about implementation and simulating what a user would do

29
New cards

what is a declarative scenario

describes state and high-level actions, often in terms of domain language (think “I declare bankruptcy!” from The Office → If Michael had his way with things, he would be able to say this and things would happen automatically behind the scenes without him actually having to do something)

30
New cards

descriptive declarative scenarios tend to ___ steps from imperative scenarios to make themselves more concise

reuse

31
New cards

what is an explicit requirement

in BDD, user stories developed by stakeholders. usually captured by acceptance tests

32
New cards

what are implicit requirements

logical consequences of explicit requirements. usually captured by integration tests

33
New cards

steps written in “domain language” (informal language specific to your app) tend to be more [ imperative / declarative ]

declarative

34
New cards

what does the requirements elicitation step involve in P&D perspective on documentation?

  • understanding functional feature and non-functional performance requirements

  • project manager must learn what the customer wants via interviewing, cooperatively creating scenarios, or creating use cases

35
New cards

what does the requirements documentation step involve in P&D perspective on documentation?

  • equivalent to the writing of user stories in Agile

  • document requirements laid out in Software Requirements Specification (SRS) → may have one high-level SRS for management/marketing and one low-level SRS for dev team

  • have stakeholders read SRS, build a basic prototype, or generate test cases to test validity, consistency, completeness, and feasibility of requirements

36
New cards

what does the cost estimation step involve in P&D perspective on documentation?

  • manager decomposes SRS into tasks

  • estimates weeks per tasks (one should be bound between 1 and 8 weeks)

    • estimate via experiential estimate → based on PM’s experience

    • or via quantitative estimate → lines of code or constructive cost model

37
New cards

what does the scheduling and monitoring step involve in P&D perspective on documentation?

  • equiv to Agile assigning points and velocity

  • use a chart to show task parallelism and find critical (longest) path to create optimal schedule

  • monitor progress by comparing predicted time for tasks and expenditures to the actual time and expenditures

38
New cards

what does the change management for requirements, cost, and schedule step involve in P&D perspective on documentation?

  • use version control systems for both the code and SRS in case customers ask for changes to requirements as project evolves

39
New cards

what does the requirements checking step involve in P&D perspective on documentation?

  • PM uses tools for requirements traceability to check if the code is passing the tests that deal with all the requirements in the SRS

  • forward traceability → traditional path checking from requirements to implementation

  • backwards traceability → mapping from a detailed requirement back to a high-level requirement

40
New cards

what does the risk analysis & management step involve in P&D perspective on documentation?

  • improve accuracy of budget and schedule by identifying risks early

  • technical risk → eg. database can’t scale

  • organizational risk → eg. team is unfamiliar with a tool

  • business risk → eg. we will deploy too late for the market

  • might create risk table to identify and prioritize risks

41
New cards

Cucumber is associated with [ BDD / TDD ] and RSpec is associated with [ BDD / TDD ]

BDD; TDD

42
New cards

what is the BDD + TDD cycle

  1. fail a Cucumber step

  2. write a failing RSpec test

  3. pass the RSpec test

  4. pass the Cucumber step

43
New cards

what is the Red-Green-Refactor testing framework

  • red → capture something your code should do in a test, and fail the test because you haven’t written code for it yet

  • green → write out the simplest possible code to make the test pass

  • refactor → DRY out with commonality with other tests

44
New cards

what does the acronym FIRST stand for in testing?

Fast, Independent, Repeatable, Self-Checking, Timely

45
New cards

in the Agile lifecycle, devs are expected to write their own automated tests, but sometimes a QA team may conduct manual human-run [ unit / functional / integration / acceptance ] tests

acceptance

46
New cards

adding a new feature requires you to write three new things

  • new route

  • new controller method

  • new view

47
New cards

what is a unit test

checks the result of calling a function that needs no preconditions or setup, has no side effects, and doesn’t depend on or call other functions

48
New cards

what is a pure funciton

functions that have no side effects and whose return value is always the same for the same arguments

49
New cards

what does AAA stand for in RSpec testing

Arrange (like Given), Act (like When), Assert (like Then)

50
New cards

what does an expectation look like in RSpec?

expect(expression).to(matcher)

51
New cards

what is the difference between before :each and before :all

  • both set up testing environment (eg. creates variables)

  • before :each → setup before each test

  • before :all → setup once before all tests are run

52
New cards

how to isolate unit tests that have depended-on components (relies on results from calling other methods)

  • Arrange → isolate SUT from dependencies via doubles that force desired behavior

53
New cards

how to isolate unit tests that have side effects (causes change in application state visible outside of test code itself)

  • Arrange → observe relevant state before executing test code

  • Assert → observe state again and check for side effect

54
New cards

how to isolate unit tests that are not pure functions (output depends on other factors like time of day or randomness)

  • Arrange → isolate non-determinism in stubbed method call using a double; use Timecop to stub the system clock

55
New cards

what is a seam in testing

a place where we can change the app’s behavior without changing the source code of the app → allows for isolation of behavior in testing

56
New cards

what does expect(Movie).to receive(:find_in_tmdb).with('hardware') do?

  • expects the Movie class to receive a call to a method named find_in_tmdb with a particular argument

  • key is that it doesn’t actually matter whether or not the method exists or works → the test will stub the method call

  • have this line before the Action is taken, because it creates a spy on the method which reports whether or not the method got called

57
New cards

what is a double in testing

something that stands in for the real thing, like a controller method for searching TMDb that doesn’t exist yet

58
New cards

what is an mock / instance double in testing

creates a stunt double instance of a class that says that it is an instance of Movie, but it can’t do anything a Movie can do

  • need to endow it with desired behaviors for testing via allow(double).to receive(:title).and_return('Snowden')

  • use this when you need a stand-in with limited ability

59
New cards

what is the difference between expect(obj).to receive and allow(obj).to receive

expect errors out if the test finishes with obj never having received a call, while allow merely lets obj receive the call, but we do not care if it is called at all because that is not the test’s purpose

60
New cards

unit testing should sub [ close to / far from ] the top of the stack and integration testing should stub [close to / far from ] the top of the stack

close to; far from

61
New cards

what is a fixture

statistically preload some known data into database tables before testing

62
New cards

why are fixtures usually undesirable

dependency issue (not necessarily independent)

63
New cards

when might using fixtures be good

for testing configuration data or data that does not change often or at all (eg. timezone, language). something that is not manipulated by models

64
New cards

what is a factory

allows you to create objects on a need-by basis and selectively override attributes

65
New cards

when might using factories be good

when you want to easily set up model objects independently → they will be unaffected by the presence of objects they don’t care about

66
New cards

what is the gem that helps you build and use factories

FactoryBot

67
New cards

when FactoryBot builds a new object, such as FactoryBot.build(:movie, :title => 'Milk'), what happens

it creates movie in memory without adding to the DB, and overrides the regular :movie factory’s title with ‘Milk’ → allows you to create a Movie object without having to worry about the details

68
New cards

true or false: factories make has_many and belongs_to relationships easy in testing

true → you can create a Review without first having to create a Movie if you set up the factory nicely

69
New cards

what kind of tests (3) are Cucumber scenarios?

system, acceptance, and full-stack tests

70
New cards

what kind of test are RSpec tests?

integration tests

71
New cards

what is a module / function test

tests behavior across methods and classes

72
New cards

what is a smoke test

minimal attempt to operate software → see if anything is obviously wrong before running the rest of tests

73
New cards

what is a compatibility test

testing an app’s UI in different browsers

74
New cards

what is a regression test

ensures that previously-fixed bugs do not reappear

75
New cards

performance / stress / computer security tests are all examples of what kind of tests?

non-functional tests → ensures software meets operational criteria

76
New cards

what is an accessibility test

ensures software is usable by persons with disabilities

77
New cards

what is method coverage

call every method

78
New cards

what is call coverage

call every method from every call site

79
New cards

what is statement coverage

have I touched every statement → eg. touch every if statement (does not have to execute both true and false cases)

80
New cards

what is branch coverage

test every branch in both directions

81
New cards

what is branch coverage + decision coverage

evaluate every subexpression in the conditional such that they are true and false

82
New cards

what is all-paths coverage

tests every possible route (eg. if statement with variables x, y, and z → test 2³ = 8 possible paths)

83
New cards

what is modified condition / decision coverage (MCDC)

  • every point of entry and exit in the program has been invoked at least once

  • every decision in the program has taken all possible outcomes at least once

  • each condition in a decision has been shown to independently affect that decision’s outcome

84
New cards

what is the level of coverage that is generally considered good enough

high statement coverage

85
New cards

basic blocks are executable blocks of code with no possibility of branching. how is this related to control flow coverage

if blocks are joined in a graph via conditionals in the code, then control flow coverage is just covering the graph

86
New cards

what is define-use coverage

given a variable x, a define-use pair consists of a site where it is assigned a value and a place that value is used. DU-coverage checks the fraction of all pairs that are covered

87
New cards

what are black-box tests

based on software’s external specification

88
New cards

what are white/glass-box tests

design reflects knowledge about software’s implementation

89
New cards

what are mutation tests

small, syntactically-legal changes are automatically made to program source code → small changes should cause at least one test to fail. otherwise, lack of test coverage

90
New cards

what is random / black-box fuzz testing

generates completely random data or randomly mutates valid input data

91
New cards

what is smart fuzzing

incorporates knowledge about the app’s structure to construct realistic but fake fuzz data

92
New cards

what is white-box fuzzing

uses symbolic execution to simulate program execution and observes the conditions under which each branch is taken or not. then generates fuzzed inputs to exercise not-taken branch paths 

93
New cards

in P&D, who performs unit testing

devs

94
New cards

in P&D, who performs high-level tests like module, integration, system, and acceptance tests?

QA team

95
New cards

what is top-down integration for QA testing in P&D

starts at the top of the dependency graph to get high-level functions like UI working early. con is that it requires many stubs to get the app to work

96
New cards

what is bottom-up integration for QA testing in P&D

start at the bottom of the dependency graph to avoid having to create stubs and be able to integration everything in a module. con is that you can’t see app working until all code is written and integrated

97
New cards

what is sandwich integration for QA testing in P&D

happy medium between top-down and bottom-up integration → reduce stubs by integrating some units bottom up, and try to get UI operational by integrating some units top down

98
New cards

how is the code verified in P&D (3 options)

  • human does proof

  • computer does proof via automatic theorem proving

  • computer does proof via model checking