Yu Prelim Elect

Figuring out what the system must do in terms of requirements and behavior

Figuring out how the system will achieve its goals through architecture and interfaces

The tactical mechanism that translates analysis into design constraints

The traditional lifecycle fallacy where analysts, architects, and developers work in isolation, inheriting unverified specs and leading to Architectural Drift

The framework that shifts analysis and design to Day Zero, translating abstract requirements into executable design contracts

The TDD phase that involves writing a failing test to force complete understanding of the requirement and expose vague conditions

The TDD phase that involves writing the simplest functional logic to pass the analysis constraint and establish a functional baseline

The TDD phase that involves cleaning code structure and applying design principles without altering external behavior

The testing technique that maps out every mathematical permutation of multiple interacting inputs to uncover hidden gaps

The testing approach applied when an application’s response depends heavily on its historical context, validating events and actions

The architectural strategy of explicitly asserting in automated tests that correct error types are thrown instead of the software crashing

The practice of validating components in absolute isolation

The practice of verifying data transfer, communication interfaces between modules, and connections to real environments like databases

The integration strategy of verifying control layers first and substituting missing low-level modules with dummy codes

Dummy codes used in Top-Down testing to simulate the behavior of an undeveloped lower-level module

The integration strategy of verifying primitive logic and hardware drivers first by relying on orchestrating programs

Programs used in Bottom-Up testing to simulate a calling component

The anti-pattern of merging all software components at the very end of development and hoping for success

The infrastructure flaw that introduces unreliability, test conflicts, and false negatives in modern integration testing

Lightweight tools leveraging Docker to launch ephemeral, real databases in system memory that are automatically destroyed after a test

The type of test double that is programmed with expectations and verifies that a specific method was called during a test

The type of test double that provides a working implementation but takes a shortcut that makes it unsuitable for production environments

The type of test double that simply records information about how it was called so it can be verified later

The testing approach that focuses on the internal structure, design, and coding of the software

The testing approach that focuses on the functional requirements of the software without looking at the internal code

The testing technique that divides input data into valid and invalid groups to reduce the number of redundant test cases

The testing technique that focuses on testing the extreme edges of input ranges where errors are most likely to occur

The type of testing that ensures recent code changes have not adversely affected existing, working features

The phase of testing that evaluates the software's compliance with business requirements and determines if it is ready for delivery

The metric that measures the percentage of application code lines executed by automated tests