{"id":192,"date":"2010-09-01T12:21:09","date_gmt":"2010-09-01T19:21:09","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=192"},"modified":"2010-09-01T12:21:09","modified_gmt":"2010-09-01T19:21:09","slug":"putting-the-pieces-together","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/putting-the-pieces-together\/","title":{"rendered":"Putting the pieces together"},"content":{"rendered":"

My last two posts (one on Tester DNA<\/a>, and the most recent on worries about the future<\/a>) were written in isolation. The started the DNA post many months ago, and the future at least a year ago. I started and stopped completing the posts several times since their inception before finally completing them. For a bit of perspective, I currently have nine blog posts in my draft folder. Sometimes I think of something I want to write about, but realize that I don\u2019t know what to say. When this happens, I start writing anyway \u2013 no matter what comes out. When I feel like I\u2019ve written enough to dump my thoughts and save a draft. Then, I take a look at my drafts folder every week or so and see if there\u2019s anything I want to finish \u2013 most just sit there until I give up and delete them. Overall, though, I would guess that a tenth or so of my posts, at most, sit in the draft folder before being posted \u2013 for blog posts, I favor much more of a stream of consciousness approach over heavy editing (which is easier for me, but I imagine it can be difficult for my readers).<\/p>\n

Anyway\u2026I ended up posting two random articles in a row from my drafts folder backlog. I didn\u2019t mean<\/em> for the posts to be related, but they are \u2013 I guess \u2013 or maybe I\u2019m stretching things. At any rate, in response to my \u201cthe future is bleak\u201d post Rikard Edgen<\/a> asked which types of bugs I thought testers would miss. I thought I\u2019d (kind of) answer that, and also explain why systems thinking is so important for testers.<\/p>\n

Let\u2019s start small \u2013 so small that we may not even need testers! Here\u2019s a bug free program**.<\/p>\n

\n
void main()\n{\n    printf("Hello World");\n}<\/pre>\n
<\/div>\n
Not very exciting \u2013 it doesn\u2019t really do anything (**and it can\u2019t be localized). Overall, it\u2019s pretty useless, so for example\u2019s sake, let\u2019s expand our view of small to a small class or unit<\/em> of functionality \u2013 you know, about the size you\u2019d write unit tests<\/em> for. You may have a bit of functionality \u2013 for example, selecting a book from a database. I like to picture a unit of functionality like this:<\/p>\n
\"Look<\/a> <\/p>\n
The unit is much bigger than the \u201chello world\u201d example above, but with good design and good unit testing, it\u2019s quite possible to write an entire unit that\u2019s nearly bug free (from a functional level at least). In fact \u2013 I often speak of a dream of mine where testers never<\/em> find unit level functional bugs, and that developer tools and approaches eradicate these types of errors in software forever\u2026but I dream a lot.<\/p>\n
People expect software do be useful, and an application that does nothing but select a book from a database wouldn\u2019t be very useful at all\u2013 people probably want to add or read reviews, see publisher information, sort book lists, or add the book to a shopping cart for purchase. By the time the software ends up being usable (or marketable), it has a lot of units.<\/p>\n
\"A<\/a> <\/p>\n
Now \u2013 even if all of the units are well designed and well unit tested, I would bet money and stock options that the application has plenty of bugs. This is because many bugs will occur where these units connect into larger pieces of functionality. In 1999, NASA lost $125 million<\/a> because of a metric mismatch between two units (I bet the units functioned perfectly in isolation). These \u201cconnection points\u201d (or dependencies) are a pretty common place for bugs to occur. The good esters understand where the pieces connect and \u201csee the big picture\u201d of the application in order to guide their testing. The testers with the systems thinking bit in their DNA, do pretty well at this, but it can be challenging for even the best of testers as applications get larger. At some point testers will need to use analysis tools to help them understand the connection points and dependencies, but their brain is still valuable in understanding the big picture of how the bits work together. <\/p>\n
Now \u2013 as applications get bigger, this get\u2019s harder. It\u2019s impossible for a single tester to keep the big picture of something like SQL Server or Excel in their head \u2013 even a \u201ctrivial\u201d application like the authoring client I\u2019m using to write this post has a lot of moving parts and can be difficult to keep track of from a systems view.<\/p>\n
One of my worries about the future is that trivial applications won\u2019t exist anymore \u2013 ok \u2013 they\u2019ll exist, but they\u2019ll be part of much larger systems. In the examples above, those units that connected together into functional pieces became functional pieces that connect together into applications. Now, envision a world where applications (including services and devices) connect into mega-applications,services, and a world of interconnected deices. <\/p>\n
\"Oh,<\/a> <\/p>\n
If you believe my theory about bugs occurring at connection points, and that hugely interconnected software systems of the (near) future will look like this, you should realize that this is going to be just a bit<\/em> more difficult to test. My stance is that you just can\u2019t test a system such as this the same way you test a simple application. Sure, we\u2019ll need to design the software so there are fewer connection points \u2013 or that the connection points are well managed and tested (you know \u2013 better than they did on the orbiter team). That also means that it would be beneficial if testers could test the design<\/em> of the software (and that the design is testable). I expect testers will use sophisticated tools to help target their testing and recognize where error prone areas exist (and be able to run the right types of tests to reduce risk). An exploratory approach will still be prominent, but the challenge is where to look first, and what to do when you get there<\/em>. This is where I think the tester DNA \u2013 problem solving, quick learning, and big picture thinking will be critical. And it will still be extremely difficult to test such a system. <\/p>\n
Of course, it\u2019s a valid argument to just build a system first then wait for test to catch up. That\u2019s pretty much what\u2019s occurred in software engineering up to today, and software is still advancing (although software quality, arguably, is not). My worry is that gigantic software systems are even more prone to critical errors due to an exponential number of code paths as well as the \u201cdeath by a thousand cuts\u201d effect of thousands of components \u2013 each containing \u201conly a few\u201d bugs. <\/p>\n
My opinion is that we actually need to improve the way we do testing (actually, the way we create software from beginning to end) before<\/em> we can pull off building a system like this. There\u2019s a good chance I\u2019m completely wrong\u2026but maybe I\u2019m right.<\/p>\n","protected":false},"excerpt":{"rendered":"
My last two posts (one on Tester DNA, and the most recent on worries about the future) were written in isolation. The started the DNA post many months ago, and the future at least a year ago. I started and stopped completing the posts several times since their inception before finally completing them. For a…<\/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":false,"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-192","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\/192","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=192"}],"version-history":[{"count":0,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/192\/revisions"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=192"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=192"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=192"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}