SDLC
This model of SDLC moves through phases sequentially: concept, requirements, design, development, test, and maintenance
The Waterfall model
This STLC phase comes first and involves understanding the scope and objectives of testing before any tests are written
Requirement analysis
This OOP principle allows a subclass to be used wherever a parent class is expected, enabling one interface to represent many types
Polymorphism
This Git command sends your committed local changes up to the remote repository so teammates can access them
git push
This Agile role is responsible for maximizing the value of the product and managing the product backlog
Product Owner
This document produced during the Requirements phase of the SDLC formally captures what the software must do
Software Requirements Specification (SRS)
This type of testing verifies that individual units or components of the software work correctly in isolation
Unit testing
This OOP principle bundles data and the methods that operate on it together, hiding internal state from outside code
Encapsulation
In Git, this intermediate area holds changes you've staged with 'git add' before they are permanently committed
The staging area
This clean code principle warns against adding functionality before it is actually needed, keeping codebases lean
YAGNI: You Aren't Gonna Need It
In the WRSPM model, these two letters represent the real world environment assumptions that the software relies on but cannot control
W and E: World and Environment
This type of testing is performed by end users or clients to confirm the system meets business needs before final acceptance
Acceptance testing
This design guideline states that each class or module should have one, and only one, reason to change
Single Responsibility Principle
This key in a relational database table uniquely identifies each row and cannot be null
Primary Key
In Scrum, this fixed-length work period (usually 1–4 weeks) produces a potentially shippable product increment
A Sprint
This SDLC activity bridges testing and implementation, taking code from a tested state and making it live for users
Software deployment
Verification asks 'are we building the product right?'. This related concept asks this different but equally important question.
Validation: 'Are we building the right product?'
This architecture pattern separates an application into Model, View, and Controller components to divide concerns cleanly.
MVC (Model-View-Controller)
This SQL clause is used to combine rows from two or more tables based on a related column between them
JOIN
This term describes the implied cost of shortcuts and quick fixes in code, or future work needed because the easy solution was chosen now
Technical debt
This type of requirement describes HOW a system performs an action (such as speed, security, usability), rather than WHAT it does
Non-functional requirement
True or false: software can be proven completely bug-free. What is the accepted answer in software engineering, and why?
False. Software complexity makes exhaustive testing impossible, bugs can always exist in untested paths
This OOP concept is often warned against overuse, preferring this alternative relationship ('has-a' instead of 'is-a') leads to more flexible designs.
Inheritance: composition over inheritance is preferred
This is the key distinction between Git and GitHub: Git is a _____, while GitHub is a _____
Git is a version control tool (local software); GitHub is a cloud based hosting service for Git repositories
This clean code principle advises keeping designs and solutions as simple as possible. Its acronym spells out a word meaning the opposite of complex.
KISS: Keep It Simple, Stupid