D is for debugging…what else?
4 Likes
design
dependency
decode
delivery
describe
decipher
detailed
domain
disciplined
domain modelling
dependency graph
4 Likes
DEFECT!
I’m getting a lot of milage out of problems with the system here hahaha
6 Likes
D is for defocus.
Sometimes you’re in too deep and your brain overthinks what it would like to achieve. If you’re no longer discovering helpful information step away for a while with the power of a defocus. Go get some fresh air or a glass of water. And then pop back to focus. It’s incredible what a short break can do. 
5 Likes
Data Driven Testing. Always… keep… your… data… separate… from… your… code…
2 Likes
Defenestration - all some code is fit for. (I can say this because I’m a programmer and have probably written some of it.)
Dialogue
Doubt - sometimes we should apply an innocent-until-proven-guilty approach (for instance, when talking with colleagues) but sometimes we should apply an until-you-show-me-convincing-evidence-I-won’t-accept-your-hypothesis approach instead. You think this software’s fit for purpose? You think that this spec/user story/etc. represents work that will result in users being happier? Those are interesting hypotheses and I look forward to the evidence that supports them.
4 Likes
D is for Data - user data vs synthetic data
2 Likes
Domain testing - I think the technique used for most interesting bugs, when doing deep testing, includes so much data
2 Likes
Data migration testing on production Database Dump 
2 Likes
D is for Detection… of what?
Bugs
Defects
Issues
Anomalies (My favourite statement)
Unexpected Data
Excess Code
(No) Problems
Any other recommendations?
2 Likes
D is for Donut - Android 1.6
2 Likes
D is for Deming, the ‘grandfather of quality’:W. Edwards Deming
3 Likes