TL;DR

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.