You Aren't Gonna Need It (YAGNI)

Originally a development principle from Extreme Programming (XP), which stands for “You Aren’t Gonna Need It.” YAGNI advises against implementing features, writing code, or in the case of testing, preparing test cases unless there is a clear and immediate business requirement for them. The aim is to prevent overengineering, reduce waste, and encourage teams to focus on delivering only what is necessary at the present time.

Applied to software testing, the mnemonic YAGNI encourages testers to avoid designing test cases or creating test data for hypothetical scenarios or unapproved features. Instead, it promotes an evidence-led, lean approach to planning and execution, concentrating efforts on the risks and requirements that are confirmed and current.

A tester resists the urge to write automated tests for a new module that is still under discussion and not yet scheduled for development. Instead, they focus their time on creating and refining tests for features that are already in active development.

During a sprint, a team member suggests writing test scripts for a future integration that has not been prioritised. The tester reminds the team of the YAGNI principle, pointing out that the work might never be needed or may change significantly by the time it is relevant.

A test lead advises against preparing an extensive test plan for a third-party tool that the organisation has not yet decided to adopt, applying YAGNI to prevent wasted documentation effort.

YAGNI is closely related to Agile values and helps testers avoid speculative testing and premature optimisation, encouraging just-in-time preparation aligned with business value. It is similar in ways to DRY, don’t repeat yourself and KISS, keep it simple stupid which are also coding mnemonics.

For me, YAGNI is a great heuristic to help me stay focussed and optimise the work not done.

For example, it can be very easy to get sucked into a task, like automating a workflow, and start thinking of all the variations you could automate, functions you could make reusable, and fancy frameworks you could explore.  But what are you trying to achieve right now, and what do you need in order to do that?  What's your minimum viable / valuable product in this situation?  If you don't need it now, how likely are you to need it in future?  YAGNI says you ain't gonna need it.  So don't spend time on it right now.  It's great to future-proof a little, and build something that's good to work with, but don't go putting on all the bells and whistles right now.  If you need it in future, you can get / do / create it in future.  For now, take things one step at a time, and get some feedback on what you already have.