SUBJECTS
|
BROWSE
|
CAREER CENTER
|
POPULAR
|
JOIN
|
LOGIN
Business Skills
|
Soft Skills
|
Basic Literacy
|
Certifications
About
|
Help
|
Privacy
|
Terms
|
Email
Search
Test your basic knowledge |
Software Engineering Vocab
Start Test
Study First
Subjects
:
engineering
,
it-skills
Instructions:
Answer 50 questions in 15 minutes.
If you are not ready to take this test, you can
study here
.
Match each statement with the correct term.
Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.
This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. Force software to fail in order to see how it recovers
Recovery testing
Stress testing
SRS Documentation
Delegation
2. Each possible path through the code is covered
path
Elicitation
message chain
Algorithm
3. (smell) Smell deodorant
Decorator pattern
comments
Use case diagram
Lambda
4. How well your fulfil your requirements
long method
Algorithm
Constructor
Software Quality
5. People who care about the outcome
Stakeholders
black box testing
architectural design
Performance testing
6. 2nd step of requirements gathering
Integration testing
Design
intellectual property
Analysis...
7. Representational State Transfer.
REST
WSDL
Algorithm
Association
8. One or two paragraphs of text outlining a use case
Lifecycle
message chain
Casual use case
WSDL
9. Testing tactic that looks at all ways that data can flow through the code
white box testing
unit testing
Requirements
REST
10. (smell) code is repeated in multiple places
Decorator pattern
duplicated code
jquery
Fully- dressed use case
11. Comprehensive description of software's intended purpose
SRS Documentation
use case
Association
technical managerial approach
12. Testing can show the presence but not absence of errors
Warning
: Invalid argument supplied for foreach() in
/var/www/html/basicversity.com/show_quiz.php
on line
183
13. Approach to team management that splits management up into two people with separate tasks
code smell
technical managerial approach
Use case diagram
software quality
14. Freezing the state of the source code at a particular point
Versioning
Security testing
Design Patterns
code smell
15. Contract between inventor - assignee and state giving a time and geographically limited monopoly
Fully- dressed use case
Denormalization
patent
long method
16. Testing that verifies that individual units of source code are working
Security testing
unit testing
Cowboy coding
branch
17. Test cases made -> code compiles -> make code pass
Scrum (Agile software development)
Test- driven development
Lifecycle
conflict
18. Ways to express the system's subsystems and their relationship
statement
architectural design
Feasibility
Analysis...
19. (smell) Classes using things that should be private in other classes
Phase
Specification
inappropriate intimacy
Security testing
20. Testing tactic based on whether inputs and outputs match up for required functionality
Functional Requirements
Acceptance testing
black box testing
Maturity level
21. (smell) One class delegates all of its requests to another class
unit testing
Design
middle man
First- class citizen
22. 1st step of requirements gathering
Elicitation
Dijkstra's law
shotgun surgery
Stress testing
23. A way to automatically grade code based on heuristics
Database normalization
Quality metrics
Algorithm
trademark
24. Degree to which the system meets the specified requirements and development standards
Erich Gamma - Richard Helm - Ralph Johnson - John Vlissides
software quality
jquery
Denormalization
25. Tasks that a system must be able to perform
Functional Requirements
Algorithm
Phase
Usability testing
26. Testing designed to uncover regressions (where stuff that used to work doesn't work anymore)
regression testing
Parser
Stakeholders
comments
27. 'single dot rule'
Security testing
Code Quality
Law of demeter
Cowboy coding
28. Description of possible sequences of interactions between a user and the system.
Usability testing
statement
use case
intellectual property
29. Developing a plan for a product - system or component. 'how' a system should perform a task
Design
Delegation
Programming style
Functional Requirements
30. Diagram outlining the tasks that are going to be performed by the user
statement
data clumps
brief use case
Use case diagram
31. Diagram used to show how information flows around the system
unit testing
sequence diagram
SOP
patent
32. AKA: Function Constant or Function Literal A function defined - and possibly called - without being bound to an identifier.
Anonymous function
Elicitation
Acceptance testing
Constructor
33. Iterative - incremental framework for project management.
inappropriate intimacy
Scrum (Agile software development)
shotgun surgery
SRS Documentation
34. Small - behaviour- preserving - source- to- source transformation
Phase
use case
a refactoring
Code Quality
35. The rights governing the ownership and disposition of technology
Integration testing
a refactoring
intellectual property
middle man
36. Recognizable indicator that something may be wrong with code
Association
Scrum (Agile software development)
code smell
sequence diagram
37. Figuring out what the requirements are
Elicitation
Association
trademark
Parser
38. Each team member given set of features to work on
a refactoring
feature- driven development
Cowboy coding
Design
39. (smell) method has too many statements - loops or variables
long method
Programming style
comments
shotgun surgery
40. Wrote the book Design Patterns: Elements of Reusable Object-Oriented Software.
code quality
software quality
system testing
Erich Gamma - Richard Helm - Ralph Johnson - John Vlissides
41. Absence of lifecycle
Requirements
long method
Cowboy coding
Design
42. Reusable - abstract 'blocks' of design
Use case diagram
Constructor
system testing
Design pattern
43. Derived methods should not assume more or deliver less
Software Quality
Functional Requirements
Liskov substitution principle
Dijkstra's law
44. 1. A language feature that supports prototype- based programming. 2. Originally: One object relying upon another to provide a specified set of functionalities. 3. In .NET: A way of telling which method to call when an event is triggered
Delegation
Law of demeter
Closure
SOP
45. A powerful motivator for change
Erich Gamma - Richard Helm - Ralph Johnson - John Vlissides
Code Quality
conflict
Use case diagram
46. Delaying the creation of an object - calculation of a value or another expensive process until first needed.
Lazy initialization or Lazy loading (Design pattern)
comments
Versioning
SRS Documentation
47. Each condition is covered twice (true - false)
shotgun surgery
Denormalization
conflict
branch
48. Evaluates upper limits of operational parameters
Stress testing
Capacity testing
intellectual property
Use case diagram
49. Simple Object Access Protocol. Specification for exchanging structured information. Uses XML. Usually relies on other Application Layer protocols (HTTP - SMTP)
SOAP
Law of demeter
code quality
shotgun surgery
50. Single step in a lifecycle
Dijkstra's law
sequence diagram
Phase
Closure