{"id":745,"date":"2013-12-16T11:43:27","date_gmt":"2013-12-16T19:43:27","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=745"},"modified":"2013-12-16T11:43:27","modified_gmt":"2013-12-16T19:43:27","slug":"death-and-testing","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/death-and-testing\/","title":{"rendered":"Death and Testing"},"content":{"rendered":"

I\u2019m heading off for a long vacation today, so this is likely my last post of the year. It\u2019s been a crazy year, and I thought I\u2019d end it with something that a lot of my recent posts have been leading to (e.g. this post<\/a> on tearing down the walls).<\/p>\n

Some of you will hate this. I\u2019m not sure if it\u2019s because you\u2019re afraid of your job, or because it\u2019s so far out of your world that it doesn\u2019t make sense. For you, let me tell you about the audience who will read this and say, \u201cho-hum \u2013 tell me something I don\u2019t already know\u201d. <\/p>\n

Testing as we know it, is changing \u2013 and the changes are big (for some folks, at least). Testing as an activity<\/i> will always exist. But I see test as a role going away \u2013 and it can\u2019t disappear fast enough.<\/p>\n

Test Is Dead (or is it)?<\/h4>\n

A few years ago, my friend James Whittaker angered testers world-wide with his talks on Test is Dead<\/a>. James premise was that for a whole lot of software out there, it\u2019s more cost-efficient to get data and issues from customers actually using the product than from a test team pounding on the product. Unfortunately, way too many testers failed to see the context and big picture of the main point and screamed loud and wide about how quality would suffer without testing.<\/p>\n

But James was far more correct than people give him credit for.<\/p>\n

Hiring testers to pound quality into a product after it\u2019s been developed is a waste of money. The more I think about it, the more I realize that Test Teams are an artifact of older, predictive (staged \/ waterfall-ish) software development models. The notion that one team (or part of a team) is responsible for writing code, and another part of the team is responsible for making sure it works as expected seems wasteful to me (even after spending the majority of my career doing just this). <\/p>\n

Test teams<\/i> are dying. You may disagree, but I encourage you to take a critical look at whether you believe a non-integrated test team is the most cost efficient way to evaluate a product. Yes, I know there are companies formed entirely around evaluating already-developed products \u2013 but I believe that the days of testing-quality-in (the equivalent of the people who clean up after animals in a parade) are ending (or ending, at least, for the quality software products of the future).<\/p>\n

Testing is NOT Dead<\/h4>\n

Before you skewer me with your protests (and some of you will, despite my best efforts to explain), let me reiterate. Testing<\/i> is not going away. The testing activity will thrive and improve and evolve. It\u2019s just time to think about getting rid of the old ways of thinking about who does the testing and where it happens.<\/p>\n

Plain and simple, we (the software industry) have been wasting money for years letting testers play safety-net for lazy developers. It\u2019s much more cost effective and efficient for developers to write unit tests and some or all functional level tests \u2013 and maybe more. Other<\/i> developers on the team (many of them former testers) should focus entirely on \u201cilities\u201d such as reliability, performance, security, etc. as well as evaluating end-to-end scenarios (epics) spanning multiple features. (related paper from me here<\/a> \u2013 it\u2019s a few years old, but I think it foreshadowed this change nicely).<\/p>\n

There are other activities – like data collection and analysis (feel free to insert the buzzword \u201cData Science\u201d here if you wish) and other tasks we need software teams to do \u2013 but we don\u2019t need separate teams for those tasks. We need people to do those things, but those specialists can work anywhere. Why is it that I\u2019ve seen just as many performance or reliability teams reporting to development managers as I have seen reporting to test managers? Some of my colleagues talk about the need for testers to \u201ctransition\u201d to data science or other roles. In reality, it may be a transition, or it may be different people. It doesn\u2019t matter (what remains true, is that we will have an increasing need for people who can analyze data). I think one of the only reasons we don\u2019t talk about having a specific \u201cData Science Team\u201d is that we already have enough disciplines in software engineering, so we default to shoving them into the best suited discipline for analysis roles.<\/p>\n

Whole Team Approach?<\/b><\/h4>\n

We need integrated teams \u2013 not separate teams. We need teams of generalizing specialists<\/i> to make great software. The disciplines and teams get in the way of efficient creation of quality software. Some say that the programmer\/test relationship provides checks and balances \u2013 but I see no reason why those discussions and positive conflicts can\u2019t happen on a team where everyone works tightly together.<\/p>\n

I\u2019ve seen a few mentions of the \u201cwhole team approach\u201d to software creation, but that term (to me) doesn\u2019t adequately describe how great teams (can) work. In a team full of generalists, everybody can do everything, but nobody does anything particularly well. That doesn\u2019t work if you\u2019re trying to make quality software. In a team of generalizing specialists, everyone does something (or a few things) really<\/i> well<\/i> \u2013 but the team members are adaptable when necessary. Teams need specialists in design, user interface, performance, reliability, deployment, internal infrastructure, data analysis, and scads of other areas. Teams also need people who specialize in testing \u2013 specialties that include end-to-end evaluation and risk analysis, as well as coaching developers writing unit and functional tests. <\/p>\n

But the separate team for test is dead. It\u2019s a waste, and we need to stop thinking about putting our specialists on separate teams.<\/p>\n

Testing is a Specialty<\/b><\/h4>\n

I\u2019m looking at a twitter feed full of comments from testers worrying about what this means to their careers. A good tester, as part of a team of generalizing specialists is worth every bit of salary and value as any other specialist on the team. Test \u201cspecialists\u201d who can\u2019t provide this level of value, however, probably should<\/i> worry about their career. Test may be dead, but good testing<\/i> will live and be valued for a long, long time. But we need to stop thinking that we need test teams to pound quality into a product, and figure out how to fully integrate great test minds into great software teams.<\/p>\n

There\u2019s a subtlety here that goes beyond semantics. Jobs (most of them, at least) aren\u2019t at stake here. The great testers of today will be great test specialists on software teams tomorrow. It doesn\u2019t\u2019 matter if they code or not, as long as they provide value and contribute. I\u2019ll repeat that, because I can almost guarantee a comment about how stupid I am for proposing a world where testers need to code. Test specialists won\u2019t (necessarily) need to code. Many of the \u201ctest automators\u201d today will write features, as well as functional tests (using their mad automation skillz) \u2013 and they\u2019ll coach the programmers on how to do the same \u2013 leveraging the specialties of each other.<\/p>\n

A glance through any testing community will show dozens of definitions of what testing is, and what testers do. It\u2019s too much. It doesn\u2019t matter. We need to stop building organizations where one team writes code and another team tests it. Testing needs to happen all of the time, and at the same time as development. For this to happen, we need to get testers out of their test teams, and fully integrated into software teams.<\/p>\n

A Better Future<\/h4>\n

Today, testing articles, posts, and tweets are filled with whining (or mere complaints) about the sorry plight of testing, the lack of testing respect, the difficult of measuring testing, and other worries of the testing community I\u2019ve been hearing for the past 20 years. <\/p>\n

But a new world where testing is merely<\/i> a specialty within the software team eliminates these worries. There\u2019s no more us versus them. We have a team, and we each supply different specialties that contribute to the team\u2019s success.<\/p>\n

Preemptive post script<\/h5>\n

I\u2019m leaving (on a jet plane), and I half-rushed this post out. I half (or full) rush most of my posts, but this one is important. I\u2019ll try to respond to comments (and hate mail) when I land, but I expect I\u2019ll have follow ups and re-writes coming. I\u2019m positive there will be much speculation on what I didn\u2019t<\/em> mention, so I\u2019ll deal with that soon as well.<\/p>\n

More will come.<\/p>\n","protected":false},"excerpt":{"rendered":"

I\u2019m heading off for a long vacation today, so this is likely my last post of the year. It\u2019s been a crazy year, and I thought I\u2019d end it with something that a lot of my recent posts have been leading to (e.g. this post on tearing down the walls). Some of you will hate…<\/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-745","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\/745","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=745"}],"version-history":[{"count":0,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/745\/revisions"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=745"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=745"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=745"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}