Collection of blog posts that I read on Saturday, February 29th, with TLDR summary.
Socratic Vs. Euclidean Forms Of API Documentation [source] by Todd Hoff
Euclidean – state your axioms and let users derive the rest. Easiest for the API provider, but hardest on the user. Socratic – an open-inquiry meant to bring about a deeper understanding of the API user. You get the Euclidean part, but you also get a FAQ, you get recipes for common tasks, you get error conditions and possible responses, and you get working code examples.
Don’t try to sanitize input. Escape output [source] by Ben Hoyt
Every so often developers talk about “sanitizing user input” to prevent cross-site scripting attacks. This is well-intentioned but leads to a false sense of security, and sometimes mangles perfectly good input. The only code that knows what characters are dangerous is the code that’s outputting in a given context.
Ruby on Rails do it from version four. I use this feature when I evaluate possible web frameworks for my clients.
The Automated Testing Trap [source] by Pete Walen
Pete is not against automation. He brings conversation recap from his local tester’s meetup #GRTesters. The topic was how to approach to automation problem.
Would Heu-Risk It? Part 21: The Hive [source] by Lena Wiberg
Lena explains defect clustering with a real-life story.
Information Loss in Software Testing [source] by Matthew Heusser
This one is about information loss in the organization, the higher you climb in the organization, the less information you get.
From the QA trenches: 6 signs of project success or failure [source] by Andy Patrizio
The software testing staff can be the proverbial canary in the development of coal mine. They see indications of success or failure well before anyone else.