As a prequel to Agile Testing Days where I will do my presentation, I am trying to interview the other speakers. Today we have Scott W. Ambler, a software engineer, consultant and author, currently Chief Methodologist for IT at IBM Corporation in their IBM Rational division. He is known as author of several books focused on the Unified process, Agile software development, the Unified Modeling Language, and CMM-based development.

Eusebiu Blindu: How would Scott Ambler describe himself in the context of the testing community and as a person?

Scott W. Ambler :I’m clearly a pro-testing person, as many within the agile community are. For many years I have promoted at test early and test often strategy in my writings as well as a test-first one. I’ve embedded testing techniques in the various methodologies that I’ve worked on over the years, in particular I’ve promoted database testing within the Agile Data method (http://www.agiledata.org) and a range of testing strategies in Disciplined Agile Delivery (DAD) (http://www.DisciplinedAgileDelivery.com). Database testing has been a radical concept, particularly in the data community, that even now very little has been written about. In DAD I promote the idea of explicitly including independent testing, when appropriate, in addition to the whole team testing approach which is currently dominant within the agile community. Whole team testing is clearly important, but there are some situations, particularly at scale, where independent testing is required. As a person I’m a father first, a husband second, and an IT professional third.

Eusebiu Blindu: How would you shortly define “Agile Testing”?
Scott W. Ambler:That’s a hard one. How about: Test often, early (if not first), collaboratively, and to the risk. Some more detailed thoughts can be found at http://www.ambysoft.com/essays/agileTesting.html

Eusebiu Blindu: Do you apply “Agile Testing” currently and if so, how exactly?
Scott W. Ambler:As you can see at the article in the previous question, there’s a range of agile testing strategies. I try to be as agile as I can at everything that I do.

Eusebiu Blindu: Can you please tell us more about Disciplined Agile Delivery (DAD) and the related book you co-authored?
Scott W. Ambler: DAD is a hybrid agile process framework adopting proven strategies from Scrum, XP, Agile Modeling, Kanban, Unified Process, and others. Interesting features for agilists are that it describes a full delivery lifecycle, not just construction; it is goal-driven, not prescriptive, providing the flexibility required to meet the unique challenges of your situation; it is enterprise aware, providing advice for how agile teams can fit in effectively into their overall organizational ecosystem; and it provides a solid foundation from which to scale agile approaches.

Eusebiu Blindu: What would be the three most important factors in your opinion when dealing with database testing (http://www.agiledata.org/essays/databaseTesting.html)?
Scott W. Ambler: First is to recognize the need to do so. The majority of organizations don’t seem to understand this, a reflection of the culture within the data management community. Second is to understand that you need to do both black box testing and clear-box testing. The teams that do database testing typically do just black box testing, which is a great start but not sufficient. Third is to understand that test-first approaches to database testing are where you need to get to. I wrote an article for IEEE Software in 2007 entitled Test Driven Development of Relational Databases (http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2007.91) so the idea has been out there for awhile now.

Eusebiu Blindu: Also because I myself started my career as IBM contractor, can you tell us what is the role currently played by the company in the world of testing?
Scott W. Ambler: IBM sells testing tools, we do testing training, consulting and mentoring. We are also providing testing outsourcing services. We do research into testing. IBM has over 400,000 people worldwide, and testing is a key aspect of our overall value proposition.

Eusebiu Blindu: You mention you are a father and a husband before an expert in the field. How important is that for the career balance?
Scott W. Ambler: It’s incredibly difficult to have a good work-life balance. If you don’t put your family first you’re probably going to be out of balance, which then leads to problems in the long run. IT work can demand long hours of you, and you need to know when to say enough is enough.

Eusebiu Blindu: In  http://www.ambysoft.com/essays/agileTesting.html it is written, kind of like a motto, “Agile Testing and Quality Strategies: Discipline Over Rhetoric”. What does “Discipline over Rhetoric” mean?

Scott W. Ambler: The challenge that I see with the agile community is that there is a fair bit of rhetoric around testing, a lot of it good but some of it bad. One of the things that I do is run industry surveys to discover what people are actually doing, what is working well, and what might not be working so well. Then I share the results (see http://www.ambysoft.com/surveys/). My testing and quality article describes a collection of strategies, some of them such as TDD and whole team testing which “conform” to the common agile rhetoric. Some strategies including independent testing and formal reviews which don’t conform to the mainstream rhetoric. In DAD we promote the idea that one aspect of being disciplined is to adopt the strategies that are appropriate to your situation and then tailor them accordingly. One of the requisites of that is to know what strategies are available to you the advantages and disadvantages of them.

Eusebiu Blindu: What is the one thing that you can name that keeps the motivation in your work? What makes it still exciting?

Scott W. Ambler: I’m constantly learning. I think that if I wasn’t learning this stuff would become really dull really quickly for me.

Eusebiu Blindu: What do you expect from the Agile Testing Days conference? Do you have in mind any particular talk that you would attend?
Scott W. Ambler: I have decided yet which talks I will attend. It will be driven by my interests at the time which in turn is driven by what I’m doing with customers at that point.

Eusebiu Blindu: How would you test a Rubik’s cube? What related to “Agile” would you apply in doing that?

Scott W. Ambler: I would hand it to my sister Carol and ask for her opinion. She loves puzzles and has mastered several different forms of Rubik’s puzzles. Collaborative testing involving an expert is hard to beat.

Eusebiu Blindu: Thanks for the time spent with this interview. Looking forward to meeting you there!

As a prequel to Agile Testing Days where I will do my presentation, I am trying to interview the other speakers. Today we have Zuzana Sochova from Czech republic. She is one of the  founders of the Agile Association Czech Republic, an association creating sharing platform for individuals, teams and companies interested in agile. She works as Agile trainer and coach offering consultancy of agile services and management, and among many other things she is a speaker at Agile conferences and a contributor to the Czech Technical University Agile project management programs.

Eusebiu Blindu: You have like a trademark that attracts curiosity your hair, which is very colorful Do you think that helps (to have a personal trademark), especially when we need to build a reputation to get clients? 

Zuzana Sochova: First, I believe it helps to have a personal trademark. There are plenty of same and ‘gray’ people. I know many well-dressed managers in dark suits and costumes, which would tell you it not acceptable to look different. But it’s up to you. It’s always your decision. However, it must fit your business I would say. I’m changing people and companies, I’m learning them to take courage and be different, be Agile. So should I look as traditional old-fashioned manager?  I’m looking for client who really need change, and need help. And those people don’t care so much about your hair color. They are more interested if you are good enough and can help them. And it helps the other way around as well, I don’t need to reject clients who just want to pretend some agile activity, they most likely not even contact me

Eusebiu Blindu: Brno or Prague?

As a prequel to Agile Testing Days where I will do my presentation, I am trying to interview the other speakers. Today we have Arie van Bennekum, (co-)author of the Agile Manifesto (www.agilemanifesto.org) , Chair of the Agile Consortium International (www.agileconsortium.net). He is a DSDM Practioner, Trainer, Examiner and Consultant.

Eusebiu Blindu: How would Arie van Bennekum describe himself in the context of the testing community and as a person?

Arie van Bennekum: My contribution to the Agile Manifesto in February 2011 was DSDM (Atern). In DSDM testing is heavily covered in one of the 9 principles (now there are 8 ) and also with 6 separate testing principles. Testing by (amongst others) the end-users gives real using-quality (they know what they need at their fingertips). On top of this is it creates acceptance because people get to know the system. Acceptance gives quality of use. This helps an organization to achieve their objectives. A perfect solution and bad use destroys any objective.

This I know, see and try to make people aware of, both inside and outside the community.

Eusebiu Blindu: How would you shortly define "Agile Testing"?

Arie van Bennekum: Testing in an Agile environment should be integrated throughout the project cycle, independent, repeatable and focused both on bugs and achievement of business objectives.

Eusebiu Blindu: Wow! "DSDM", "Atern", x number of principles…. In general we need some sort of guiding. But to do "Agile" do we need to learn every concept that is related to it, or we can manage just with what we think is agile and use no definition?

Arie van Bennekum: For me agile is not 'do what we like'. The agility is in the flexibility we have to create functionality in the solution vs. a specification up front. To be able to do so agile is a very disciplined process, so yes, we need to know the method (whatever method we use) and work according to it.

Eusebiu Blindu: I have noticed many speakers (at least in testing conferences) from Netherlands. They seem to have the highest number from Europe. Do you agree? Why do you think is that? Do you think they are more motivated?

Arie van Bennekum: Don’t know numbers but NL is keen on (business) quality. Is requires testing for both bugs (does it work right) and business value (do we achieve to expected benefits)

Eusebiu Blindu: Using wikipedia I see for principle "4. Never compromise quality" – "test early and continuous". What does this mean? How early do we need to start testing?

Arie van Bennekum: Please check the manual. The basic is that every functionality will get the needed time in testing. When there is time pressure we leave out less important functionality, we do not test less, like most projects do.

Eusebiu Blindu: I guess I just want to know what was the initial motivation for the creation of the manifesto and the events that preceded it. Is it because we need most of the time standards? I mean does we always need someone to officially say "Individuals and interactions over processes and tools"? 

Arie van Bennekum: Good point, my view is you don't tie people but you make sure you understand each other and are synchronized. This is why I like frameworks instead of detailed predefined stuff.

Eusebiu Blindu: Do you plan something like the Agile Manifesto in the future?

Arie van Bennekum: Not really but the authors agreed to meet again in 3 years. Who knows what will come out of this

Eusebiu Blindu: Is the agile model inspired from something outside the software development world?

Arie van Bennekum: It has an origin that is diverse. DSDM has its origin in Rapid Application Development which means software. It has been applied in many since, also outside software development. On top of this, DSDM covers the whole project of the solution development, including processes, user acceptance, etc. I prefer to call for that reason DSDM a solution development framework.

Eusebiu Blindu: Is the agile model currently inspiring areas that are not related to software development? 

Arie van Bennekum: Yes, you can see all sorts of developments. There is the, maybe logical, connection with Lean. Also in total different areas like pharmacie (oktober Berlin).

Eusebiu Blindu: Is there anything that you don't like about the way agile is understood/applied from what you have heard or see?

Arie van Bennekum: What i would like to see adapted a little is the strong focus on software. I would like to move it to 'solution' which includes to whole thing including change, communication, etc. A successful project is the project that helps the organization to achieve business objectives. Software is part of the solution that creates this. We need to do a lot more, it should be done too. BTW, DSDM adds a lot here.

Eusebiu Blindu: "Rapid Application Development" seems like “Rapid Software Testing". I am not sure if the "testing" version was borrowed from it, but this gives me ideas. Do you think it’s inspired to adopt other things that are related to "Agile" and insert it into testing?

Arie van Bennekum: No, I don’t think so. RAD was very poor on testing but had a lot improving actual methods at the time. It brought thinks like user participation, sessions, real prioritizing, prototyping, etc. DSDM structured this, including increasing insight, which RAD was blocking. DSDM also was and is strong on the testing parts i mentioned earlier.

Eusebiu Blindu: And a final question related to your talk at the conference, called “Get them in(volved)”: can you tell us what to expect from it?

Arie van Bennekum: Gehgehgeh, come and watch! It is all about acceptance and quality for business

Eusebiu Blindu: Arie, thanks for the time given to answer my (questionable : ) ) questions. Looking forward to meeting you there!

      As a prequel to Agile Testing Days where I will do my presentation, I am trying to interview the other speakers. Today we have  Matt  Heusser , a passionate tester that, among others, does "This Week in Software Testing" podcast, he is a member and part of Board of Directors at Association for Software Testing , a Contributing Editor at STPCollaborative and he also gave a talk at Google Test Automation Conference in 2007.

Eusebiu Blindu: How would Matt Heusser describe himself in the context of the testing community and as a person?

Matt Heusser:  Wow, Eusebiu, that's a tough one.  Within the test community, I'm sort of a holistic quality person — I have done stints as a programmer, project manager, and in test/QA.  As a consultant, I tend to focus on the whole delivery process.  Within the test community itself I tend to advocate for the tester as a specialized role, with a skills set that is different than the programmer or business analyst, not that they can't overlap a bit.  As a person, I am a writer, husband and father; a great deal of my success in the software community comes from sharing ideas through writing.

Eusebiu Blindu: Since the conference is called "Agile Testing Days", can you tell us how would you shortly define "Agile Testing"?

Matt Heusser:  I am not going to get any soft-ball qustions today am I, Eusebiu?  (Laughs).  Look, the question of What is Agile Testing is challenging on multiple levels.  Most importantly, if we write it down, people will tend to canonize the definition, to hold it up as the one right/true process to do testing, and that runs contrary to the spirit of the Agile Manifesto.  Of course, that presupposes that there is one right/true definition, and that we can all talk about it without inserting our own experiences and watering down the definition a bit. So it's a challenge.  I mean, how deep do you go?  Your one-sentence description is going to have information loss, and your five page description isn't going to be read by anyone.

But to answer your question, personally, if I had to give a couple-sentence description of "Agile Testing", I would say it is a test process designed to plug into an Agile Process as defined by the Agile Manifesto.  That means we want to be able to deploy to production much more often than in traditional models and we want to respond to change — so we have to get very good at risk analysis, at getting a great deal of confidence in the system in a compressed period of time, and we probably want to focus on actually getting things done instead of heavily, over-specialized role definitions.  Will that suffice as an answer for now?

Eusebiu Blindu: Do you apply "Agile Testing" currently and if so, how exactly?

Matt Heusser:  As I write this I am currently engaged on-site with a 'classic' agile team.  The entire team fits in one room, the code is written with 100% pair programming and Test Driven Development, stories are defined up front in a kickoff meeting and generally have an executable acceptance test element, and so on.  What my clients might be like in November, of course, is anybody's guess! 

To answer your question specifically, a lot of my advice and consulting is in the area of dealing with risk, with shrinking the time it takes to get an assessment of the software, with shrinking the "regression test window" (for lack of a better term), with helping teams to adapt to change.  So yes, I like to think that what I do is basically Agile-Testing, in the best sense of the term, sure.   

Eusebiu Blindu: Ok, so you say you can't really put a definition on "Agile" and that has be avoided. But can you make a parallel between "Context Driven" and "Agile"? Its the same, similar or different?

Matt Heusser:  I hope I've given you a working definition that is "good enough", at least.  Another definition might be preference for a certain style of working environment, combined with the belief that that preference leads to better outcomes.  So when "Agile"-infested people come into a new environment, they have a whole set of prescriptions: Pair Programming!  Test Driven Development!  Automate the Acceptance Tests – up front!  Story Driven Development!  Tear down the cube walls!  And so on.

I identify myself publicly with the Context-Driven School of Software Testing, which as a philosophy, is a little different.  I would go so far as to say that the first sin of methodology is make a claim like "This worked for me once!  Therefore, it should always work for everyone, all the time!" — that offering a prescription without first examining the patient is not best practice, but instead malpractice.

So while Agile Testing is a tool in my toolkit, one I am personally fond of, and one use often, there are some circumstances where it may not be appropriate.  Before I offer suggestions to an organization, I want to know a great deal about them.

As you can probably guess, offering training in context-driven testing is a real challenge, because you can't just tell people what to do. There are several ways around this, including workshops, simulations, and exercises designed to provide people with examples and skills training.  With enough data points under your belt, you start of say "oh, this reminds me of project foo.  How did that turn out?  Would that be acceptable to me on this project?" – you start to model the dynamics on the project and plan, instead of pulling out a plan from someone else.

Because it allows different approaches to be valid in different environments, context-driven is sort of a meta-school — it can swallow up specific methods, as long as they have a "place."  So, for example, I prefer Agile methods for projects done under changing conditions and time pressure, which happens to be the majority of my clients.  So I need to know a thing or two about Agile Testing, and Agile Software Development, in order to be effective.

Eusebiu Blindu: Liked your answer and the "meta-school" label. You have a tutorial with Pete Wallen and a closing keynote, both with very interesting titles. What should the audience expect from these? Can you give a preview?

Matt Heusser: The tutorial is going to be about testing.  Not management, metrics, templates or automation:  Actual testing.  That is to say, given a new build, which tests should you run?  What are the most powerful tests — the tests that tell you about the system?  Once you have run them, what can you say about the software?  What tests should you run next?  If you learn something about the software that might impact which tests to run next, how do you adjust?  How can you learn those things earlier?

In order to get the most benefit from our tutorial, we won't just lecture.  Instead, we'll air-drop the students into a software test environement, actually doing testing, sharing what we learned, covering the next topic, and testing again.

Yes, you heard right:  A test conference session where you actually get out a keyboard and do testing.  I know.  Who ever heard of a CRAZY idea like that? 

As for the keynote, that one will be about the dynamics on software projects — how we can structure them to encourage a successful outcome.  Or we could structure them so that everyone is competing and encourage to hide information.  I'll be covering this from within the general framework of Game Theory, that mostly came out of mathematics, where I did my undergraduate work.

Eusebiu Blindu: What is your current focus related to testing besides work? What is your plan for the next period?

Matt Heusser: My main focus is on how organizations deliver software, and how to do it well – how to make better decisions in the moment, throw away the stuff that slows us down, and do more of the stuff that speeds us up.  Along those lines, I have a preference towards exploratory methods, so I'm curious who is using how much exploratory testing to do what.  By exploratory, I mean a lot more than exploratory testing; I'm talking about how the teams are organized, how the work flows, how people are spending their time.

Toward the test side, I've spent about nine months working with a group where the whole team creates examples, that the  programmers automate as part of the development effort, using a tool like Fitnesse or RSpec.  Once those examples are automated, you have a very powerful domain specific language (DSL).  In some cases, I have seen testers reproduce defects from the field by modifying those old executable specifications — when this happens, they can turn a failing automated check over to the programmers to fix.  I think that's a good thing.  I am interested in what kinds of envrionments are fertile for that kind of approach, and the idea often falls down as it is transferred from person to person.

I am also using more tools to blend human, exploratory approaches with more traditional automation approaches — both things like the kind of model-driven approach that Harry Robinson recommends, and building better stubs, drives, and hooks into the software so testers can explore (or randomize input).  Testing complex GUIs, and just plain complex and high-volume systems, continues to be on my radar.

As I implied before, my focus seems to be shifting toward the entire delivery process and how to do it better.  Some folks call that work "Organizational Transformation", and I haven't found a better term yet.  Basically, I think most software teams can get better performance by restructuring the way they take in and do work.  My test work is probably the most visible, but you can apply the same thing to all aspects of software delivery, including the results, the real thing the customers are buying.  To put that another way, if the customer could get the same results without buying your software, of course they would.  So I care about the value delivery process, not just software.

Eusebiu Blindu: By the way, how did you get into testing?

Matt Heusser:  That's a long story, Eusebiu.  I'll try to answer it quickly.  When I started my career, I was a programmer, at a company with thirty employees; perhaps twenty-five of us were programmers.  We had no testers, no business analysts, just a bunch of programmers, a couple managers, two guys in sales, and a receptionist.  In other words, I had no safety net.  I had to learn about testing, to deliver high-quality code to the customer.  I was scared.

So I learned.

I went to school at night for my masters, and studied testing.  I read books, I went to conferences.  Half-way through my career, I moved to a larger company with a few specialities, but still no testers. People noticed that I had an interest in testing, and I started to help out on projects that were not my own.  My business card still said "programmer" (and later "project manager"), but, by 2005 or so, I self-identified myself as a tester.

When I left to go work for Socialtext, they had an HR change during the interview process.  The CEO told me that they no longer had the test manager position open, but would I like to be a programmer?  I remember replying "Why would I want that?  I can be a programmer right now."

They ended up making an opening for me in test anyway.  The rest, as they say, is history.

That's the short version.  I'll be happy to tell a longer story at the conference.

Eusebiu Blindu: Oh, thanks for the interview. I can't wait to meet you at the conference and get that story!