Testing & Movies & Stuff

Change Logs: The Treasure Maps of Committed Code Picture this: Your team is working hard, landing commits, shipping them out the door, and then something hits a snag. You might use a source tool to narrow down the error message that came up. Or maybe pick apart a test that failed to find out why there is suddenly something mucked up in the code. You may even swim through a sea of commits in an attempt to find the one that might have possibly caused the issue, especially if you didn't find it in the last commit.  There is a simple tool that could help you and your customers. Using a change log can give a team several advantages.  1) You can group commits into a timeline and apply them to a known release window. 2) You can view multiple groupings in the same chronological change log. This could present a pattern that might help track down the issue. 3) Your customers can also read the change log and know what they are receiving in the latest patch, update, or release you've deplo

(Originally Posted on CrossBrowserTesting.org) To understand how to reach a zero defect status quo, think about defects like you might think about bread. Bread is the absolute best right out of the oven. Slather it with butter and pop it into your mouth. It’s heaven. The worst bread can get is when it’s molded over and completely inedible, but it can also be helpful.  Defects are often seen as bad things. That’s not necessarily true. Defects tell you something about what’s going on with the state of the application. If defects were to equal hot, tasty bread you pop right into your mouth, would you think about avoiding them? Maybe, maybe not.  There are probably plenty of reasons to avoid bread. Allergies. Carbs. Gluten tolerance. Those reasons are absolutely respected. Replace the idea of bread with anything that works just as well. Suggestions are welcome! Measuring The Freshness Of A Defect Let’s consider the bread analogy a little further. Bread goes through states of change. That