{"id":802,"date":"2014-02-17T15:31:13","date_gmt":"2014-02-17T23:31:13","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=802"},"modified":"2014-02-17T17:06:42","modified_gmt":"2014-02-18T01:06:42","slug":"some-principles","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/some-principles\/","title":{"rendered":"Some Principles"},"content":{"rendered":"

I\u2019ve been thinking a lot less about testing activities lately, and much, much more on how we to make higher quality software in general. The theme is evident from my last several blog posts, but I\u2019m still figuring out exactly what that means for me. What it boils down to, is a few principles that reflect how I approach making great software.<\/p>\n

    \n
  1. I believe in teams made up of generalizing specialists \u2013 <\/em>I dislike the notion of strong walls between software disciplines (and in a perfect world, I wouldn\u2019t have separate engineering disciplines).<\/li>\n
  2. It is inefficient (and wasteful) to have a separate team to conduct confirmatory testing (e.g. \u201cchecks\u201d as many like to call them). This responsibility should lie with the author of the functionality.<\/li>\n
  3. The (largely untapped) key to improving our ability to improve software quality comes from analysis and investigation of data (usage patterns, reliability trends, error path execution, etc.).<\/li>\n<\/ol>\n

    I haven\u2019t written much about point #3 \u2013 that will come soon. Software teams have wasted huge amounts of time and money equating test cases and test pass rates to software quality, and have ignored trying to figure out if the software is actually useful<\/em>.<\/p>\n

    We can do better.<\/p>\n

    A few links:<\/p>\n