Remove data structures noise from your tests with builders

Among other qualities good tests should be easy to read, quick to understand. When the test requires complex data structures to be sent to the SUT or to be part of a stubbed answer, it takes longer to read. Moreover those structures use to evolve as the production code does causing too many changes in the tests in order to adapt them. An indirection level in between the test and the production code helps improve readability and ease of maintenance. Builders come to the rescue. I often overload builder methods to support several data structures and then apply the conversions internally.

As an example, this is the setup of one of our tests before the final refactor:

  1. [Test] public async void
  2. raise_multiple_choices_event_on_equipment_selection () {
  3. SetupViewModelWithMockService();
  4. var selectedEquipment = new Equipment { Code = "PR" };
  5. var oneEquipment = new Equipment { Code = "PR1"};
  6. var otherEquipment = new Equipment { Code = "PR2"};
  7. var equipments = new List<Equipment>{ selectedEquipment, oneEquipment, otherEquipment };
  8. var multipleChoices = new List<CompulsoryCombinationChoice> {
  9. new CompulsoryCombinationChoice(new List<CompulsoryCombinationItem> {
  10. new CompulsoryCombinationItem(oneEquipment.Code, CatalogItemTypes.Equipment)
  11. }),
  12. new CompulsoryCombinationChoice(new List<CompulsoryCombinationItem> {
  13. new CompulsoryCombinationItem(otherEquipment.Code, CatalogItemTypes.Equipment)
  14. })
  15. };
  16. ACatalog.MockingDependenciesOf(vm)
  17. .WithEquipments(equipments)
  18. .ResolvingCompulsoryCombinationsAs(multipleChoices)
  19. .Configure();
  20. /* act ... */
  21. /* assert ... */

Imagine how ugly it was before the "ACatalog" builder. And this is the test after the builder was overloaded to supply a more comfortable API:

  1. [Test] public async void
  2. raise_multiple_choices_event_on_equipment_selection() {
  3. SetupViewModelWithMockService();
  4. var theEquipment = "PR";
  5. var equipment1 = "PR1";
  6. var equipment2 = "PR2";
  7. ACatalog.MockingDependenciesOf(vm)
  8. .WithEquipments(theEquipment, equipment1, equipment2)
  9. .ResolvingCompulsoryCombinationsAs(
  10. MultipleCompulsoryCombinationChoices(
  11. equipment1, equipment2))
  12. .Configure();
  13. /* act ... */
  14. /* assert ... */

Marionette + Require + Jasmine 2.0

I am starting to work on a new project for a new customer, I'll join the team for a couple of days or perhaps weeks. They have been spiking and eventually have decided they want to develop the front-end using Marionette.js a library on top of Backbone.js together with Require.js. I've done a spike to show them how I'd structure the files, the app and the different kinds of tests.

The app is dead simple. The is a form with two fields, "description" and "url". When the user clicks on the button below, a new link is added underneath. So it's to add links to a panel.

Versions used in this working spike:

  • Jasmine.js - v2.0
  • Require.js - v2.1.14
  • Marionette.js - v2.0.1

The repo is here:


  • bower_components - dependencies
  • node_modules - dependencies
  • index.html - launches the app
  • uiTests.html - launches Jasmine tests against the DOM, using Require.js
  • actionsTests.html - launches Jasmine tests to test business logic
  • js - this is the production code
    - app.js
    - views.js
    - models.js
    - actions.js
  • spec - these are the tests
    - viewsSpec.js - interact with the DOM
    - actionsSpec.js - no interaction with the DOM,  works on the business logic

With this structure the business logic don't have to depend on Marionette,  although it depend on Backbone models and collections.

Resources that help:


Mock objects on JavaScript

Many frameworks use the word "mock" for what in reality are "spies". But that's OK, the work "mock" in English covers actually all the possible test double types...

However according to G. Meszaros, a mock object is a specific type of test double that is configured with expectations before exercising the system under test. During the execution the mock compares the calls being made, to its expectations failing if they don't match.

The two frameworks I use for test doubles in JavaScript are Jasmine and Sinon.js. And I also use some helpers of my own. None of these two frameworks provide actual mock objects. Sinon has a "mock" function that let us configure expectations before exercising the system under test. It behaves like a mock if we are working with functions only. Nonetheless if we are working with objects (OOP), then what Sinon provides is not a mock object because a call to any other method in the object other than the expected, will not fail the test. And it should as unexpected calls should make the test fail.

The solution to have real mock objects with Sinon is just a little helper:

  2. //------ HELPER FUNCTIONS
  3. function unexpectedCall(functName)
  4. {
  5. return function(){
  6. throw new Error('Function ' + functName + ' was not expected but invoked');
  7. };
  8. }
  9. function inocuousCall(){
  10. return function(){};
  11. }
  12. function replaceAll(obj){
  13. return {
  14. methodsWith: function(fn){
  15. for (var propName in obj)
  16. if (typeof(obj[propName]) == 'function')
  17. obj[propName] = fn(propName);
  18. }
  19. }
  20. }
  21. function stubThe(obj){
  22. replaceAll(obj).methodsWith(inocuousCall);
  23. }
  24. function mockThe(obj){
  25. replaceAll(obj).methodsWith(unexpectedCall);
  26. }
  28. //------ THE TEST
  30. it("stores the user when adding a new one", function(){
  31. // the DOC (depended-on component)
  32. var repo = userRepository();
  33. // the SUT (system under test) and dependency injection
  34. var service = userService(repo);
  35. // patching the DOC, making it a mock
  36. mockThe(repo);
  37. var mock = sinon.mock(repo);
  38. // configuring expectation:
  39. mock.expects("store").once();
  41. // exercising the SUT
  42. service.add(new User({email: ''}));
  44. // verifying configured expectations
  45. mock.verify();
  46. });

In languages like Java or C#, test doubles frameworks create a replacement for all the methods in the target class/interface. In JavaScript however, frameworks replace single functions. For this reason it's possible to have the same object acting as the SUT and the double in a single test. But the fact it's possible doesn't mean it's right. Whenever you find yourself in a test using a double for some method and then invoking another method in the same object, think carefully whether the design is appropriate. That smell is usually pointing out that you should extract a new class and create a dependency between the old and the new, so that one acts as the double and the other as the SUT.

Isolation with jMockit: Stub out System from Java JRE

In general I prefer to wrap up system functions so that I can inject test doubles and test drive my designs easily. In general is not a good idea to mock objects you don't own. But this time I was doing some research, preparing one edition of my Online Training Class on Test Doubles and came across jMockit as a way to stub out System artifacts. jMockit is an isolation framework that I haven't tried before.

The idea is to stub the System.currentTimeMillis built-in function. I tried PowerMock but it didn't work for this particular case. PowerMock is brilliant for stubbing static methods and constructors as long as they are not part of the system. Very handy for legacy code.

  2. // import mockit.*;
  3. public void simulateCurrentTime() {
  4. new Expectations() {
  5. @Mocked("currentTimeMillis") System mockedSystem;
  6. {
  7. System.currentTimeMillis();
  8. result = 123456L;
  9. }};
  10. }

This is the method I had to invoke from within my JUnit test in order to stub out the function. It works! I have to say that it took me more than one hour to make it work because I couldn't find this in the documentation. I found several blog posts but they are old, the framework has changed since then. Eventually, a combination of information gathered from several posts yielded this working method.

Kids, don't do this at home!

If you want to know more, join the next edition of my training class 😉

Online training course/class: Test doubles

No long ago in the Spanish TDD mailing list, some friends said they were struggling with test doubles. A typical question is how to use them to design collaboration a la test-first. Test doubles are something people find hard to understand in my TDD training courses.
This is why I've decided to run an online training class on Test Doubles. Mostly those used in unit tests: mocks, stubs and spies.

I'll run two editions of the training, one English spoken and the other Spanish spoken. People can decide which one they want to participate in after they subscribe the online form.

We'll use mostly Java to practice as it's a language most people know. But the same concepts are valid for other languages. We'll also view examples on JavaScript and C#. Like all my training courses, this will be hands-on with very little talk from my side.

The number of participants per course is limited to 25 so that I will have time to review all the exercises during the course and make suggestions. I enjoy having time to share it with participants one by one. Don't wait too much, 25 spots will be gone soon 🙂

As this is the first edition it comes with a special price, only 49 bucks!

If you are familiar with the idea of writing a test first, you can join this class. We'll use Webex for videoconferencing as well as sharing resources together with other tools.

Find the subscription form here.

Fluent API for test doubles

There are several good frameworks out there to create test doubles with JavaScript. Jasmine  and Sinon provide test spies and stubs. JsMockito looks good too. However, creating your own API for test stubs is very easy. I've created mine as an exercise. It's a very naive implementation but it works. See the code:

  2. describe("a fluent API to create a test stub", function(){
  3. it("stubs out a method", function(){
  4. // the fluent API:
  5. function when(stub){
  6. return {
  7. thenReturn:function(arg1){
  8. stub.configureOutput(arg1);
  9. }
  10. };
  11. }
  12. function stub(actual){
  13. var expectedArgs,
  14. configuredOutput,
  15. isConfigured = false;
  16. actual.configureOutput = function(output){
  17. configuredOutput = output;
  18. isConfigured = true;
  19. }
  20. actual.someMethod = function(){
  21. if (isConfigured){
  22. if (expectedArgs[0] == arguments[0])
  23. return configuredOutput;
  24. return;
  25. }
  26. else
  27. expectedArgs = arguments;
  28. return actual;
  29. };
  30. return actual;
  31. }
  33. // the test confirming it works:
  34. var actualObject = {someMethod: function(a){return 1+a;}};
  35. var theStub = stub(actualObject);
  37. when(theStub.someMethod(2)).thenReturn(5);
  38. expect(theStub.someMethod(2)).toBe(5);
  39. });
  40. });

The implementation is not generalized to support any method or any number of parameters. I just wanted to play with the idea that I can invoke the stubbed method in the "when" statement and it doesn't execute anything apparently. It only executes the stubbed behavior once it's been configured.

It's very simple but it didn't come up to my mind when I implemented pyDoubles (now Doublex), which might have made the API even better.

London Tester Gathering Workshops

Next week, I'll be taking part in the London Tester Gathering Workshops at SkillsMatter. I'll be giving a 4 hours workshop on JavaScript aimed at software testers on Thursday. Inspired by the workshop, I am working on a JavaScript manual for testers (JavaScript4Testers) that will be available soon. The manual will serve as a guide along the workshop and in the future it might become a book, because my friend Tony Bruce is now co-authoring it with me, which is very exciting. The manual contains already some brief sections on the JavaScript language and then it addresses testing techniques, debugging, tools and some tips on performance and security. If you think this manual is looking interesting, please go to its site and write down your name an email, that will encourage us even more.

Like all my workshops, it will be a hands-on session with very little theory and lots of practice. That is how I enjoy running workshops and the way people learn more.

I am a developer, am not a tester. In fact I am terrible at catching defects. But I love working together with testers because I like their vision and their collaboration spirit. Working together is very nice and effective. And I learn techniques on how to break the software by observing them. So I am looking forward to meeting all the participants in what is going to be a great experience. The workshop's atmosphere at SkillsMatter is very friendly, we'll have plenty of time to chat, share experiences, learn and enjoy. This is the Twitter hashtag for this edition: #ltgw2013

I land in London on Wednesday 16 afternoon. To warm up and meet  friends, a bunch of developers will meet in this pub to practice coding (a code kata) at 7pm. Feel free to join us.

See you next week in London 😀

Do you want to be a CAT? (Certified Agile Tester)

Potsdam is beautiful specially in this time of the year, it's definitely a must see,  I am loving the place. However, I am not here for tourism reasons. I am attending a special training called "Train the trainers" for those professionals who want to be trainers in the Certified Agile Tester program. And it's not because I am going to be a trainer for the CAT, it's about other training program we are planning 🙂 but will talk about that in a future post.
This is the first training for testers I attend to and I am really enjoying it. Half the training is about agile. The contents are very well prepared and so the teacher. So I can tell that in this training, people learn a lot and have to study and participate a lot. Not everyone passes the exam.

In this edition there are participants from 6 different countries or so and the atmosphere is great. One of my colleagues comes from Mexico, what a long trip!

The exercise I've enjoyed the most so far is the Lego game. Building a city "the agile way". You can find all the pictures here.

And there it is the short retrospective with lessons learned from the game in our small team:

  • We didn't ask enough to the product owner in the first iteration (acceptance criteria).
  • We didn't agree on some criteria or conventions even between us.
  • We didn't do any spike to have at least a rough idea of what a story point represented.
  • We committed ourselves with a bunch of user stories for the first sprint without any clue of how much does it take to build a single house and without any acceptance criteria for it.
  • Although I didn't feel any good at the beginning of the first sprint, with all those questions on my head, I couldn't prevent my 3 team mates from start building like crazy. Uncomfortable situation for me... I felt we were going to crash but couldn't avoided, we just crashed like dummies. Fortunately we did way better the next iteration so experiencing the failure was positive and maybe necessary for us to react and improve  🙂
This game, along with the marshmallow challenge are my two favorite metaphors to introducing agile in the small.
Best look to all the trainers that are going to do the exam on Friday!

Push the “how” down: Cukeup! 2013

It's been my first time attending to an event at Skills Matter and it's been awesome 😀

Cukeup! is the annual conference about BDD and Cucumber. This was the third edition.  Let me share with you the ideas I listened yesterday. The ideas and sentences written in here are not necessarily what speakers said, this is just my understanding of them. You can now view the talks online from the SkillsMatter site.

- Keynote by Aslak Hellesøy - father of Cucumber and coauthor of the excellent Cucumber book (which I recommend) and Cucumber Recipes (brand new):
Aslak told us how the development of Cucumber is going and the new design ideas they are working on, together with a review of the many flavors Cucumber's got. I missed a reference to SpecFlow in the slides though, as it is one of the tools I use and I think Gaspar Nagy is doing a great job (and he came to the conference by the way, which was nice). The thing I liked the most from this keynote was that he announced their new book recently published, Cucumber Recipes, which is now on top of my wishlist. And also the honest way he talked about the architecture redesign Cucumber needs and how are they approaching it. This is a good example of why architecture and design are so important.

- One-line step definitions with Matt Wynne - coauthor of the two books mentioned before:
You can see the talk online here (and so the others too). Having read his first book, the new ideas I got from this insightful talk was that the popular test pyramid can be "rotated". Matt and Seb Rose came across this idea together. Basically, you can use Cucumber to describe features without the need to access the application end to end, just exercising low level classes and methods from the step definitions. In those cases Seb decorates the features with tags indicating the level of abstraction they belong in (@without_ui for example). If you haven't read Matt's book, this talk is a good summary of some parts, it features some of the most important values and principles. Remarkable ideas:
Push the "how" down because it changes often and because it will not bring people into BDD as the features written in the imperative way are hard to understand and boring, cluttered with irrelevant information. Sometimes imperative style is the result of ignorance but it can also spot lack of trust in the team.  And... don't nest steps (call another step from the step definition).

- Working in the Cucumber World with Andrew Premdas:
Andrew's advise is to benefit from both, natural and programming languages when we write features and their step definitions. In order to do that, the "World" (fixtures used within step definitions) must be expressive, self-descriptiveAlthough he discouraged us from using global variables, there are some exceptions, something useful when referring to oneself in the fixtures is to use the variable "I" (@I in Ruby). Enrique Comba also suggested using @narrator (@ comes from Ruby) as the variable used to refer to the person telling the story. Because "narrator" might be clearer than "I" when there are many steps. Andrew said it was his first talk and he did very well in my opinion because clearly his primary concern was to communicate, so the message came out effectively.

- Don't you trust me? with Seb Rose:
Trust is easier to loose than to win. When developers tell testers that everything is fine but then it breaks, they are loosing points. Same when developers don't allow testers to navigate through the code base. Testers can work more effectively if they know a bit of programming and are able to check out the source code for inspection. When team members trust each other they clean up the road for others. Documenting high level architecture and components also helps.
Then he explained an experiment he is trying out: end to end tests are good to win trust so he starts by exercising the application like that from the features. But after that, he considers whether end to end is really the right way to go, because maybe exercising low level methods rather than several layers is cheaper, as long as there are already other end to end tests covering the path. Again, the rotated pyramid.

- The Impersonator Pattern with Enrique Comba:
Enrique got many of us thinking how to leverage the pattern right after his talk. He explained it on his blog time ago. A very nice secondary effect of this pattern, is that one can rapidly review the implementation of the impersonators and get a summary of what every persona in the project can do and what can't do. Useful documentation to have, specially when you have hundreds of features and thousands of steps. It was definitely a great talk, source of inspiration. His craftsman spirit lead him to this pattern as the consequence of following the "maximize code clarity" principle.

- Hands-on Cucumber.js with Julien Biezemans and Matt Wynne:
Julien, the creator or Cucumber's JavaScript flavor was pairing up with Matt to test-drive a little game live, writing the code directly in the browser with particular web environment set up by him. I am already using Cucumber.js so nothing new about that but I didn't know about uitest.js which they were using during the session. I am actually doing something similar on my own with Jasmine to run the app within an iframe so is good to know that more people are doing that. Some other times I just run cucumber.js from the command line using zombie.js.

 - Cross-platform BDD for Mobile with Karl Krukow:
Karl showed Calabash, a very powerful framework for mobile testing. Really impressive to me. It fits perfectly with hexagonal architecture and helps to avoid duplication in the tests while testing native apps on different mobiles platforms. It's really worth having a look at Calabash. I'll definitely will do. Of course the integration with Cucumber is excellent.

- Testing web apps with Cucumber.js with Paul Jensen:
Good speaker, nice technical stack and good ideas from the talk. He showed code from his successful app Dashku and its tests. I must say that the way I write JavaScript apps is different specially because I test-drive them whereas he showed a prototype developed without tests, having them added afterwards. But still, some good points in the talk.

Now I'll watch all the sessions that I couldn't attend to (haven't found the way to split myself in two). 

See you next year hopefully!

Interview with Matt Heusser, keynote speaker at the Test Automation Day

I had the chance to meet Matt Heusser (@mheusser) during the Agile Testing Days 2012 conference... and it was great! Matt's keynote was brilliant, excellent, I really enjoyed it. But I think what I liked the most, was that he seems to be a humble and honest guy.  One of those guys who's got a lot of experience, knowledge and prestige, but talk to you with respect even if he doesn't know who you are. My good friend Ivan Stepaniuk was lucky and got the chance to share more time with Matt, where he gave us some advise.

Now I've had the honour of interviewing Matt thanks to the organization of the Test Automation Day conference, which will be held in the Netherlands in June 2013. Matt will be keynote speaker in the conference and the whole event looks very promising. If you are a tester living in Northern Europe, don't miss the event 😉

Let's go to the interview:


How is it going Matt? What have you been working on recently?
Thank you, Carlos, I’ve been busy.  Right now I am working on a local ecommerce test project, doing a lot of writing, helping to organize the test and quality track for the Agile Conference, organizing an online test competition in April, and trying to organize a peer conference in Wisconsin, likely in August, 2013.

- In the last decade, teams used to see testers as second class citizens. Testers haven't been involved in the requirements or in development stages, but just as part of the UAT process. Do you see changes in the last couple of years?
It’s a big world, and I see testers at different companies doing different things, so it is hard to draw trends.  The complaint of ‘second class citizens’, or being involved too late -- we’ve seen those sorts of complaints for a lot more than this decade.  If you go back to the test conference materials of the 1980’s, I expect you would find the same sorts of suggestions, to get involved upfront, to get the requirements right, that sort of thing.
I think two really big things happened in the first decade of this century, though.  First of all, the context-driven movement changed the question, asking “If I wasn’t involved up front, and I am brought in late, what can I do to improve outcomes anyway?”, which I think is a healthy question.
Second, the customer-facing testing branch of the Agile School started to talked about what they called Acceptance Test Driven Development (ATDD).  Part of ATDD is getting concrete, testable examples early in the process -- helping to augment requirements with specification by example.  Deming would have called it ‘operational definition.’  No matter what you call it, testers are good at coming up with the cases of software in use, and programmers are using that to drive development, which means the software is higher quality when it comes out the door.  That is eliminating dev/test defect churn, and people are noticing.

- Do you still find companies delivering software without a professional QA team or is that already overcame? How would you explain to them, in short, that they need QA?
Well, I think they need to do testing as an activity, and probably are, though they may be doing it poorly.  Programmers tend to not be great at testing for defects, customer-testing, because testing is a sort of destructive activity, and programmers tend to be constructive in thinking.  (I am a former programmer, I can say that.)   There certainly are problems small enough that that is not a big deal -- a company hiring programmers to write database reports might not need testing as a role.
On more complex things I want to look at the defects the company is showing to the customers.  Do they matter?  Are they coming in late?  Is the company experiencing lost sales or returns because of poor quality?  Are programmers spending more time fixing than in building new software?  If the answer to any of those questions is ‘yes’, the company may ask for testing help, and, at some point, get more serious about the tester role.  I don’t want to force that, though; I’d like the company to decide and then ask for help.

- Where do a professional agile tester start her career? Where is it that one can learn how to become a professional agile tester?
Well the easy way to do it is to find a company doing Agile Software Development, interview, and get hired.  That is the easy way (laughs).

I guess I don’t understand the context. Is if if you are a tester now, how do you become an Agile Tester?  My advice would be to change your organization ... or ... change your organization. Is the question how to be an agile tester, that is, how to learn what agile software development is an how testing plugs into it?  For that I would recommend finding a local user’s group, going to meetings, and reading everything you can find on the subject, from books to blogs to twitter.

- What skills are needed to be a professional tester?
Offhand, I would start with curiosity and systems thinking and the desire to learn.   By systems thinking, I mean the ability to model a situation in your mind, to make trade offs, and to figure what happens when those tradeoffs happen.  This is the kind of thing you can learn by playing Chess; Gerald M. Weinberg has a couple of good books on the topic.  Most of the other things can be taught.  Most teams following an Agile approach also require a little bit of teamwork, but  to be an effective tester, that is not always required. (laughs)

- What do an independent agile tester like you offer to companies? What is the value they can get from hiring you as a testing consultant?
 It depends on what you bring me in to do, but I can give you some examples.  The short answer is  expertise.  When a team has a problem they could probably solve, but they have other things to focus on, they can bring a consultant to get to the bottom of the problem.  My role at Excelon is a little different because in addition to consulting, I also stick around and help implement the ideas on real operational projects - I actually do testing.  That’s the second half of the value; instead of solving the problems, I can work with the teams to solve problems themselves.  Not by lecture in a classroom with powerpoint, but by working through actual operational problems.
One common thing I can do on any project, at any phase of development, is start testing.  No requirements document?  Fine.  I can test.  No access to a customer? Fine, I can test.  No spec, no project plan?  The software won’t build?  My gamble is that I can find something to do to add value to the project to justify the investment.  Given a little time, I can teach it, so you get skills on the team plus the project is actually done-done earlier, which is something you don’t get with traditional “conduct interviews and write a report” style consulting.

- Is the market asking for more professional testers? are there many job opportunities out there?
It’s funny you should ask.  I don’t know about in Europe, but right now in the United States I have a had a great deal of requests lately from all over the place in America.  At our last meeting of the Grand Rapids Testers, I think perhaps half of the people there were either building test departments or recruiting testers!


- Why should people attend to Test Automation Day conference?
Too many of us feel vaguely bad about ourselves that we aren’t doing more test automation, and when we’ve tried, we’ve had a fair bit of failure.   Test Automation has been the bugbear of software testing for years.  Let’s face it.  We aren’t likely to solve this ourselves, but by coming together, we’ve got a chance.


- What are the top three books you recommend to learn about software testing?
It depends on the audience.  To a professional tester I might recommend Lessons Learned in Software Testing by Pettichord, Kaner, and Bach.  Second, How to Reduce the Cost of Software Testing, a collection of essays I was involved in - and perhaps third, the Lee Copeland book on test design.  For a manager, executive, or someone new to the concept, you can’t beat Weinberg’s “Perfect Software” book.


- I do know agile testing is continuously evolving, is non-agile testing evolving too?
In some ways, what the agile folks were pushing for twelve years ago when they signed the manifesto are becoming the norm for all the companies I consult with - frequent meetings, (more) frequent release, a willingness to plan iteratively, and so on.  So even the “non-agile” problems are become more “agile” - lowercase a.
But I think I take your meaning.  There certainly are traditional projects; here in the United States they are likely to be financial, embedded, avionics, that sort of thing, that have a high price of failure that require a more specific process.   The context-driven world has made some big strides in that area; I also think that some of the ideas about High Volume Test Automation, the work of people like Dr. Cem Kaner and Doug Hoffman, are starting to gain traction.


- How is agile testing going to evolve in the next decade?
 Well you have to ask, in 2003, if I could have predicted where we are today.  Could I have predicted that testing would need to scale to hundreds different types of mobile devices running twitter and facebook and google plus and GPS?  Probably not.  Could I have predicted ‘the cloud’?  Certainly not in how it played out.
So testing will probably evolve to scale the needs of software we can’t predict.
Now do I see trends?  Sure.
Right now I see a new field emerging, the quality engineer, that comes out of devops. QE’s might be building the build system, the test automation, tying things together, or creating the developer tools to enable self-service environments, push button builds, and deploys/rollbacks to production.
The reason it is a new field is because the companies doing it are doing it with open source tools.  Everyone is rolling his own.  It is possible, over the next few years, that some commercial companies (or very successful open source projects) make this the sort of thing any company can implement easily - that we start to build a body of knowledge around chef and puppet and such.  When that happens, a lot of waste is going to disappear from the system.  Testers on those sorts of projects will need to find new ways to contribute and add value.
The second disruptive innovation I see are crowdsourcing projects uTest that allow companies to harness exploratory testing from the cloud.  That is going to eat into the market for testers.  Once again, to stay in the game, we’ll have to improve, because companies will be able to outsource the quick attack stuff to a crowd vendor cheap.
Of course there will continue to be big, slow, traditional companies building traditional software that don’t change much; many banks still run COBOL.  The testing equivilant to COBOL will be with us for years to come -- it just isn’t very fun!


Thank you very much for your time and your inspiring answers Matt!

I hope the readers will enjoy the answers as much as I do. This post is going to be updated in the next couple of days/weeks, I will add links to the many references Matt points out in the interview.