{"id":928,"date":"2015-06-12T10:51:21","date_gmt":"2015-06-12T17:51:21","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=928"},"modified":"2015-06-14T19:49:53","modified_gmt":"2015-06-15T02:49:53","slug":"building-quality","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/building-quality\/","title":{"rendered":"Building Quality"},"content":{"rendered":"

I mentioned in my last post<\/a> that I have a new job at Microsoft (and I discussed it a bit more on the last AB Testing<\/a>). During the interviews for the job, I talked a lot about quality. I used the agile quadrants as one example of how a team builds quality software (including my roles in each of the quadrants), but I also talked about quality software coming from a pyramid of activities and processes. I\u2019ve been dwelling on the model for the last week or so, and wanted to share it for comments and feedback\u2026or to just brain-dump the idea.<\/p>\n

Processes \/ Practice \/ Culture<\/h4>\n

The base of software quality (and my pyramid) is in the craftsmanship and approach of the team. Do they care about good unit testing and code reviews, or do they check in code willy nilly? Do they take pride in having a working product every day, or does the build fall on the floor for days on end? The base of the pyramid is critical for making quality software \u2013 but on established teams can be the most difficult thing to change.<\/p>\n

Code Quality (correctness)<\/h4>\n

An extension of PP&C above is code correctness. This is a more granular look specifically at code quality and code correctness. This includes attention to architecture, code design, use of analysis tools, programming tools, and overall attention to detail on writing great code.<\/p>\n

Functional Quality<\/h4>\n

Unit tests, functional tests, integration\u00a0 \/ acceptance tests, etc. are all part<\/em> of product quality. I italicize, because for some reason, some folks think that quality ends here \u2013 that if the tests pass, the product is ready for consumers. (un?)Fortunately, readers\"image\"<\/a> of this blog know better, so I\u2019ll save the soapbox rant for another day. However, a robust and trustworthy set of tests that range from the unit level to integration and acceptance tests is a critical part of building software quality.<\/p>\n

Automate Everything<\/h6>\n

There are some folks in software in the \u201cAutomate Everything\u201d camp. A lot of testers don\u2019t like this camp, because they think it will take away their job. Whatever.<\/p>\n

As far as I can tell from my limited research on this camp, Automate Everything<\/em> means automate all of the unit functional and integration tests\u2026and maybe a chunk of the performance and reliability tests. For some definitions of \u201cEverything\u201d, I agree. Absolutely automate all of this stuff, and let (make) the developer of the code under test do it. The testers\u2019 mind is much better put to use higher up the pyramid.<\/p>\n

<\/h5>\n
<\/h6>\n

-Ilities<\/h4>\n

Performance, reliability, usability, I18N, and other non-functional requirements \/ ilities are what begins to take your product from something that is functionally correct to something that people may just want to use. Often, the ilities are ignored or postponed until late in the product cycle, but good software teams will pay a lot of attention to this part of the pyramid throughout the product cycle.<\/p>\n

Customer Quality<\/h4>\n

It doesn\u2019t matter how much you kick ass everywhere else in the pyramid. If the customers don\u2019t like your product, you made a shitty product. It may be a functionally correct masterpiece that passes every test you wrote, but it doesn\u2019t matter if it doesn\u2019t provide value for your customers. Team members can \u201cact like the customer\u201d, be an \u201cadvocate for the customer\u201d, or flat out, \u201cbe the customer\u201d, but I\u2019ll tell you (for likely the twentieth time on this blog), as a member of the product team, you are not the customer! <\/em><\/strong>That said, this is the part of the pyramid where good testers can shine in finding the fit and finish bugs that cause a lot of software to die the death of a thousand paper cuts.<\/p>\n

Now, if you do everything else in the pyramid well, you have a better shot at getting lucky at the top, but your best shot at creating a product that customers like<\/span> crave is to get quantitative and qualitative feedback directly from your users. Use data collection to discover how they\u2019re using the product and what errors they\u2019re seeing, ask them questions (in person, or via surveys), monitor twitter, forums, uservoice, etc. to see what\u2019s working (and not working), and use the feedback to adapt your product. Get it in their hands, listen to them, and make it better.<\/p>\n

More to come as I continue to ponder.<\/p>\n","protected":false},"excerpt":{"rendered":"

I mentioned in my last post that I have a new job at Microsoft (and I discussed it a bit more on the last AB Testing). During the interviews for the job, I talked a lot about quality. I used the agile quadrants as one example of how a team builds quality software (including my…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[1],"tags":[],"class_list":["post-928","post","type-post","status-publish","format-standard","hentry","category-allposts"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/928","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/comments?post=928"}],"version-history":[{"count":0,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/928\/revisions"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=928"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=928"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=928"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}