Questioning Testing

This years EuroSTAR 2013 theme – Questioning Testing

I was a speaker at last years EuroSTAR and I am still enthusiastic and proud to have been there. Being a speaker adds very much to the experience and since I believe I have still more to share with the community I plan to enter for a talk in this years event. Something I  can recommend to everybody willing to learn, share and invest the necessary time.

Sending in a good abstract is however not so easy and needs next to having a good idea also the ability to write a good proposal. Last December, to share how we managed to write proposals that allowed us to go to many of conferences as a speaker  Huib Schoots, Derk-Jan de Grood and I held a short workshop on proposal writing.  Derk-Jan wrote a small blog post about it. I am continuing some of that effort in this post.

Last week Anne-Marie Charrett was so kind to review one my proposals and give me some good tips. During that session I also showed her a mind map that I had made in while preparing. At some point during our session she pointed out to me that perhaps it was a good idea to share the mind map with the community. I hadn’t really thought of it myself but it immediately struck me as a good idea. So to help you on your way, and even at the risk of bringing in competition, I would like to share with you the mind map that I made while preparing my proposal. It summarizes the information that Michael Bolton and Allan Richardson shared on writing an abstract.

EuroSTAR Call for papers 2013

So good luck and maybe see you there!

DEWT 2 – Drinks, dinner, more drinks and lots and lots of talk (a.k.a. day 1)

I was very pleased to be part of the 2nd DEWT workshop. This Peer conference took place on October 5 and 6 at Hotel Bergse Bossen in Driebergen, the Netherlands. The Dutch Exploratory Workshop on Testing (DEWT) is a workshop that falls into the series of peer workshops on testing like LAWST, LEWT, SWET and GATE. The main theme of this workshop was:

 Experience Reports: Implementing Context-Driven Testing.

Friday evening started with gathering in the grand cafe, dinner and a lightning talk by myself in the conference room. I had planned and prepared the lightning talk to be about the summarized content of my EuroSTAR conference talk “Seven Questions to Help You on the Path of Testing”.

A talk that I have also entered for the next Dutch Testing Conference. The Dutch Testing Conference has a process of sending review comments on your abstract and one of the remarks in the review, a couple of days before, made me change my mind about the lightning talk. That particular remark reminded me that the context driven approach to testing is far away from being common knowledge in the software testing world.

I wondered how we communicate our view on testing and why it is that we are not really effective in bringing the message of context driven testing across?

The section below describes what my thoughts were about the content of my lightning talk mixed and enhanced with parts of the discussions arose after the discussion and later that evening when we were having drinks and the next day during the conference.

Since I started to see myself as a follower of the context driven testing (CDT) approach I have seen many a tweet and blog pass by proclaiming that if you follow context driven testing results will be much better than if you are using the old school / traditional / factory / waterfall / IEEE/ ISTQB process approaches to testing. And roughly parallel with my start of being context driven I also started to work in an agile environment. And like CDT many agilists proclaim superiority on traditional or waterfall approaches of software development. And sure enough if applied consciously and thoughtfully both approaches often yield better results than the more process oriented ‘traditional’ approaches. But even so I believe both followers of CDT and agile are making a few fundamental mistakes in their communication.

First of all the agile manifesto and the context driven testing principles have been around for over ten years now and at that time it probably was a good idea to react against the then main stream ideas of software testing. However a lot of time has passed since then and most people who had (or still have) the same feeling towards the ‘old’ approaches have changed to following the ideas of CDT and / or agile by now. So this rhetoric will have no effect on them anymore. Well maybe it could create some kind of group identity, but that can hardly be the purpose in my opinion.

Second I wonder how many people actually work in a true traditional / waterfall assignment. Personally I admit to having worked in an environment based on so-called waterfall process principles, but even then I saw myself as being in a true waterfall assignment. And in that particular case hardly anybody fully committed to doing waterfall (or to be more specific TMap) by the book. And obviously this underlines the flaw of such process and deliverable oriented approaches, but it also shows that a lot of people in such an environment do not commit to the approach as such. So trying to sway them to follow your approach because their approach is ‘bad’ might look appealing, but kind of misses the point as a lot of people in that environment will feel you are not talking about them. And even if they feel addressed by your comments how will this make them change. For the better part they already agreed with you so what your telling is either no news or not adding helpful information.

Finally, and this is for me personally the main conclusion of the discussions. Being context driven is not about being against something. It is about being a (self) educated, thoughtful, skillful, open to your context testing craftsman. A craftsman that is likely to engage in to an open discourse with his peers and team mates, who’s drive it is to learn what is necessary to do the job and then learn some more just for the fun of it. As Joris Meerts aptly pointed out “Yes that does make us elitist.” For unfortunately there are not that may software testers that invest in maintaining or even extending their software testing (and general) skills, let alone seeking to collaborate with others while they are doing that.

Even after one and a half day of conferring the question on how to bring the context driven testing message and mindset across is still not answered. So let me know if you come up with useful ideas and I will collect them and come back to the subject on our next DEWT peer conference (or any time sooner when we meet).

Standing left to right:
Ray Oei, Jean-Paul Varwijk, Adrian Canlon, Markus Gartner (Germany), Ruud Cox, Joris Meerts, Pascal Dufour, Philip Hoeben, Gerard Drijfhout, Bryan Bakker, Derk Jan de Grood, Joep Schuurkes, Lilian Nijboer, Philip-Jan Bosch, Jeroen Rosink, Jeanne Hofmans
Kneeling left to right:
Tony Bruce (UK), Zeger van Hese (Belgium), Ilari Henrik Aegerter (Switserland), Huib Schoots, Peter Simon Schrijver

Belgium Testing Conference 2012

QA vs.Testing: Antagonism or Symbiosis?

The header above was the theme of the last Belgium Testing Days in Brussels on March 12-14. During the call for papers for this conference, several months ago, I was in the middle of having SOx compliance established for one of my projects. The theme caught my attention since it represented one of my feelings on the compliance process at the time.

I work at an internationally operating bank which has a few consequences for the context in which I work. The most obvious consequence is that a bank uses either financial software or software that enables financial processes. As a result the (in-house) developed software gets extra special attention with regard to accessibility (or perhaps rather inaccessibility), integrity and confidentiality (AIC). Every piece of software that is built or bought by the bank gets a so-called AIC assessment and depending on the result of the assessment and certain amount of checks, controls and measures are mandatory.

The AIC assessment itself is essentially internal to the bank. But being a bank, and especially being an international bank, this means that on top of the internal regulations all kinds of external government and financial market regulations are imposed on it. The bank QA department translates these regulations or standards into internal processes and rules. For most of the high level business processes such a translation seems fairly straight forward. These processes are often both described and measured at the same way as the regulations. It gets more difficult if you drill down into the organization and start taking all the contributing activities and tasks into account such as in my case the development of software or more particularly the testing of software.

Organizational response

One of the financial organizations common responses is to apply and design standards and procedures together with any number of deliverables.

These standards are prescriptive of nature. They tell you in general terms what their idea is. But, depending on your QA department it gets more specific. They tell you what you must do, how you should do it, in what order you should do it and how you should call it.

The so designed procedures and processes describe the steps you are supposed to do given some standard situation. And since seeing is believing they also formulate how you should proof that you followed the process. In many cases such proof is the delivery of a number of deliverables. Deliverables can be a lot of things, but typically they are in the form of documents, test ware libraries or reports.  Given a certain standard they follow a fixed format both in terms of content, that is what should be described, and in terms of lay-out, that is how it should be described.

Quality Assurance

To my experience for the most part the somebody defining the standards to be used, the procedures to be followed and the deliverables to be created are not the developers or testers nor the customer, but is a typical staff department:

The Quality Assurance department

I see quality assurance not as a singular activity. In my opinion it is a group of activities. Activities that have a difference in focus.One part of quality assurance is focussed on making the chosen framework useable and applicable within the organization. QA as the designer. The second part of quality assurance is closely related to this as it acts as the controller of what was previously designed. To this end it translates the designs into to points of measurement and puts values to the measurement results. QA as the controller. These two might go by different names in some organizations, like quality management, but in my opinion this still is part of quality assurance. The third part of quality assurance is the part in which the actual software development related activity is taking place. It is the part that also executes the previously designed steps and  reports back on them. QA as executor.

At this point QA starts to be seen as testing which is captured in the following definition that is often used for both:

The process of validating and verifying that a software program/application/product meets: The requirements that guided its design and development;  works as expected; and can be implemented with the same characteristics

This definition has a certain appeal. It is understandable; it is similar to other process oriented methodologies; it aligns with the QA concept. But in my opinion it limits testing to checking.

Testing

The previous definition is not the definition I would use for testing. In my opinion the kind of information testing provides depends on the what the stakeholder values as important for the softwares quality. Therefore my definition is:

Software testing is a means to provide information to someone who matters about the product or service under test in a certain context at a certain time.

If I apply this definition to my AIC, SOx compliant context I find that the current solution QA has offered me does not meet this definition. Do not get me wrong I understand and agree that the change process and software development should be both traceable and accountable. I do however not believe that the solution is to enforce processes, procedures and deliverables that are judged by their presence and adherence to layout. What matters is the content that they should be presenting.

Not the process story but the testing story should be told

An example

This example describes in summary which measures the SOx team and I agreed on that are required by software development projects, and specifically testing, necessary to comply to Sarbanes-Oxley Act (SOx) regulation.

A SOx regulation review is targeted at the state of software development and testing at the moment of release to production. The intermediate states or progress steps in establishing traceability and documentation compliance are out of scope for the investigation.

Manual Testing

Testware management for manual testing follows the guidelines as summarized in the following steps:

  • A test plan or a similar structure identifies functional test objects that, minimally, covers the functionality as specified in the requirement or change documents.
  • For each of these test objects specific test activities are logged
  • The test structure identifies the release, individual RFC’s and relates them to the test activities.
  • A  full and complete overview of test objects, test activities and the test results should be established prior to release of the changes to production. This can be either in a testware management system, like preferably HP QC, or in another reviewable form
  • All tests should either have passed or if not passed have a logged defect and or     stakeholder decision attached that indicates that this is acceptable to go into production at this point in time

Automatic Testing

In essence the testware management for automated testing follows the same guidelines as manual testing. Main difference is that the way of documentation is adapted to the structure of automated testing:

  • A test automation tool or input data sheet used by the test automation tool shows the automated tests with a reference to the test object, functionality or RFC that they test
  • A log file (preferred), or checklist, shows whether the tests have been executed and if they have passed or failed
  • A full and complete overview of test objects, automated tests and the final      execution of tests with test results should be established prior to release of the changes to production
  • All tests should either have passed or if not passed have a logged defect and or     stakeholder decision attached that indicates that this is acceptable to go into production
  • If for automatic testing a self designed tool or framework is used the      functionality of the tool and the execution of the test cases should be validated by peer review. Results of the review should additionally be captured in the test report

The above steps should result in the following deliverables:

–          Basic testware describing the test design, test execution, test results and defects
–          Test Report, containing an advice for release

Test report

You might have noted that there is no mention of describing tests in advance, of following test scripts, nor of following standard or using templates. The SOx compliancy team’s focus is not on how the testing is executed during the project. Its focus is to see if the implemented changes are tested and that the executed tests and test results can be matched to them. Their aim is to establish that the changes do not have an unexpected or undesirable effect on the companies annual balance or regulatory capital. To that end they check if the changes are implemented as intended.

The SOx compliance essentially asks for what James Bach describes as three stories that describe the testing story:

  1. A story about the status of the product
  2. A story about how you tested it
  3. A story about the value of the testing

The only thing now left for me is to convince the QA department that even when I have not followed their standard and procedures and not used their templates I have thought about the reason behind their questions and am still able to supply the information they need. Only a bit faster and more naturally.

250 hours of practice – February/March

It has been a while since my last post. It was not that I have been procrastinating. No I actually was too busy to write a post. There were many reasons for this and most of them are covered in this post. So lets start with the biggest time consumer.

BBST Foundation

For those who do not know what this is I can almost hear you thinking.

“A foundation course? Doesn’t this guy have enough experience already and now he does Black Box Software Testing Foundation course. ”

Well let me put it this way. There are foundation courses and foundation courses. The Black Box Software Testing (BBST) Foundation course is as it says a foundation for further education and it is a good place to start your testing career. It’s just that it has a distinctive approach to it. First of all it is a four-week online course. Which is longer then almost any other course on software testing. Second it focusses on getting the participants to become critical and thinking software testers. It does this not by handing you any predefined recipe. It gives you the ingredients and the possibility to work with them. Let me, as an example, give you a short overview of the content:

Basic definitions                                              Programming fundamentals and Coverage
What is a computer program                               Numbering
Types of testing                                                   Storage
.                                                                           Representation
Strategy                                                               Data and Control structures
What is testing                                                     Coverage
Testing missions
Testing strategy                                              The impossibility of complete testing
                                                                          The basic combination rule
Oracles                                                                Paths and sub paths
System under Test                                              Data flows
Heuristics                                                             Sequences
Consistency oracles
More types of oracles                                       Measurement

All captured in :

  • 20+ articles and several books to read
  • 306 slides
  • Over 3 hours of video lecture
  • 5 quizzes
  • multiple individual and group assignments
  • Exam and exam grading
  • Over 70 hours of thinking, preparing and answering either individually or with team members from multiple time zones

Given that I also have worked these four weeks and maintained a family life I have made long days in February. But it was all worth it. Even if you have, like me, some experience in software testing it is a splendid (re)sharpener of your critical thinking skills with regard to software testing. Not only with the content of the course itself, but also with the interaction you have with the twenty or so other participants. Especially the group assignments and the assignments that need reviewing each others work give you a good insight in cultural and thinking differences people have. And from this and from the comments you can get a lot of more wisdom.

So some seventy of so hours spent on BBST Foundation. Well on my way towards the end goal of two hundred and fifty. But you might have noticed that this covers only February and this post is written half way March. So what more have I done.

Proposals

The end of February and beginning of March was also the time in which several deadline for calls for papers came in to view. I do not know if this really is considered practice, but it gets you to think and write about software testing anyway. Within one week I entered five proposals for a track and one for a tutorial for EuroSTAR, TestNet spring and autumn event and the Agile Testing Days. And I already am more than happy to tell you that the tutorial on the use of mind maps in testing, that I thought of together with testing buddy Huib Schoots, already got accepted.

But not only did I spent time on my own proposals. Zeger van Hese, this years program chair, invited me to help review some of the many proposals that EuroSTAR has gotten this year. And even if the amount of, anonimized, text is not so much I did want to do a serious review and evaluation of the proposals. (Like I would like others do with mine.) Some of them were good, some were bad and for some I was indecisive.

TestNet book

And there was more time spent reviewing. A couple of months ago I had committed to reviewing the TestNet jubilee book on the future of software testing. Obviously at the time I had not imagined to be this busy. But at the cost of some sleep I managed to finish the review prior to my next challenge.

The book itself is a great reference to over think where testing is going to and what choices you as tester need to make to make yourself both comfortable and future proof the coming five years.

Conferences

Although I have given talks and workshops before I had never been a speaker at a major international test conference. March 14 I made my debut on the international stage at the Belgium Testing Days. As I will be spending a separate post on the content of my talk I will limit for now with the remark that it was great fun to do and that it was great to meet both familiar and new  faces.

Meanwhile during this period Markus Gärtner published an interview with me on his blog as prequel to Europe’s first context-driven testing conference “Let’s Test“. The only downside for me seems to be that I am actually not able to attend, due to a lack of funds.

To complete the conference experience for the coming period I am invited to be a test expert at the Dutch Testing Conference (agile, context-driven testing and exploratory testing) and I invite participants to ask me questions during the conference.

#AgileTD (2)

Agile Testing Days

From 14 to 17 November 2011 The Agile Testing Days took place in Potsdam (D). Here is my second impression of my visit there.

Preparation

I am an advocate of being well prepared when going to a conference. This enables me to  make informed choices of which tracks I really want to follow or not. This time I added two additional things to my preparation. First I did a poll on Twitter and LinkedIn. I wanted to know who else would be going to the conference and at what time they would arrive in Potsdam. I myself would be arriving on Sunday and wanted to meet other conference attendees. It always surprises my how well this works. On Sunday I met with Lisa Crispin and went out to have dinner with her and eight other testers, of which four were conference speakers. The second part of the preparation was more pragmatic. I wrote a number of blog posts an agile basics, gave a tutorial and a workshop at TestNet.

Surprise & Tutorial

Monday started with a quick breakfast and registration for the conference at which I got a bag with conference information, some tourist information (incl. a bottle of local beer) and also the program for Testing & Finance. A few months earlier I had entered a proposal for that conference and since I hadn’t gotten a reaction I was curious to see who, if not me, were on the program. To my surprise I found myself having a track at the end of day 1. A brief check learned that they had tried to reach me the day before at my home e-mail address that had not checked since I left home.

The rest of the Monday was filled with a one-day version of Jurgen Appelo’s Management 3.0 course. This course I can only wholeheartedly recommend to both managers and testers alike. Besides the necessary theory, the course also is punctuated with reading tips and practical exercises. My personal take-away from this tutorial is the use of complexity theory and the notion that, despite of the fact that all models are fallible, several weaker models can be as effective and as a strong model, and certainly no better model. I will dig into that at some time soon and combine that with Jerry Weinberg’s books on Systems Thinking.

Some of the highlights of the track days

Keynote by Johanna Rothman – “Agile Testers and test managers”
In the keynote, the changing roles of testers and test managers were discussed. For example, testers will need to cooperate more intensively with developers. Test managers should be leaders in the organization and pursue the following key activities: Monitoring of the project portfolio; Removing organizational obstructions, Create confidential relationships, Leading the hiring process, Increasing the capacity of the organization and finally the Start up communities of practice. I liked the keynote enough to be following her tutorial at the Belgium Testing Days in March 2012.

Track by David Evans – “What testers and developers can learn from each other”
This track showed that testers and developers, while working on the same product, see this with a different perspective. Testers often seem more capable of changing perspective. By being able to do so testers can learn developers that there are different kinds of tests. A good model for showing this is the “Agile Testing Quadrants” as defined by Crispin and Gregory from the book Agile Testing. But I a will keep further description short as you can see the whole presentation on YouTube at, http://skillsmatter.com/podcast/agile-scrum/what-testers-and-developers-can-learn-from-each-other

Track by Rob Lambert – “Do agile testers have wider awareness fields”
This track went in to the need to be aware of your context and to use this awareness to your benefit as a tester. Perhaps it is the process or maybe it is the people? Or is the awareness field of agile testers is not wider at all? Agile testers however seem to display a higher ability to feel, to perceive, to know and to be aware of themselves and the world around them. Traditional testers often seem to have a more limited consciousness in terms of testing, and development roles. Even if it is wider, it is often less versatile than in an agile environment. There is however a distinction between social (situational) awareness and personal awareness. One reason for the difference in perspective among other things, is that the focus of testing in a traditional development environment is narrower than the focus of testing in an agile environment. A greater awareness and a broader focus, often leads to an increase in choices. This allows you to choose one of the possible paths instead of chosing a prescribed path. A greater awareness is also a first step on the path of change. However you can not follow all paths. It is necessary to have sufficient self-knowledge and to know your limits. More on this in this prezo.

Track by Huib Schoots – “So you think you can test”
Huib actually wasn’t on the initial program of the Agile Testing Days. But a few of the presenters were ill and since Huib happened to have his laptop with this presentation on it at the venue he offered to pitch in. The organization graciously  accepted his offer and Huib made his first appearance at an international conference. As the title suggests his talk was on what makes a good tester and how to become one. I really enjoyed his talk but rather than to describe it here I am going to point out a series of columns on this Huib is writing.

Keynote by Liz Keogh – “Haiku, Hypnosis and Discovery: How the mind makes models”
Liz put an extraordinary exercise into her keynote. She let the audience pair up to create Haiku’s. Together with Johanna Rothman and I came up with the following sentences that we combined to the following Haiku:

Foggy breath
An agile journey
Bright blue burst over the rocks

Or a more famous one from Matsuo Basho:
Furuike ya                  Old pond
Kawazu Tobikomu     Frog jumps in
Mizu no oto                The sound of water

Liz continued with a hypnosis session to explain that concentrated and focussed attention on positive experiences can bring a state of mind that widens perception and activates the ability to see patterns and models. Huib Schoots volunteered to go on stage and be hypnotized. It was impressive to see how more than half of the audience participate and was elevated by the experience.

Keynote van Gojko Adzic – “5 key challenges for agile testers tomorrow”
Gojko concluded the track days with an inspiring keynote talk on five challenges agile testers are facing:

#1 Shorter delivery phases
#2 Agile is now main stream
#3 Faster feedback
#4 Large “enterprise” projects
#5 Validating business, not software

His final message was to adopt principles, adapt practices, teach each other how to test, help business to define and validate actionable metrics, visualize risk value areas and to draw up contexts to inform testing. This definitively struck a chord with me. As I am working at a large enterprise transitioning to agile. I can fully understand that the energetic and all present Gojko won the MIATPP Award 2011 as “The most influential Agile Testing Professional Person 2011”

Final day

The final day was a series of parallel sessions with Open Space, Coding Dojo, Testing Dojo and last but certainly not least TestLab. To be honest I was both to actively involved and tired after the previous days to take sufficient notes. But what I can share with you that these possibilities to actively use what you have learned, to spar with your peers and to be coached by the organizers and speakers that are there makes this part of the conference potentially the most valuable part.

A journey to #agiletd (1)

Agile Testing Days 2011 – Potsdam

In October I started a series of posts on agile. For me there were three reasons to start writing those posts. First, I worked in an agile environment, second, I felt there had to be more to agile than its most commonly mentioned method SCRUM and third it was a way of preparing myself to go to the Agile Testing Days. Now that I have returned from the conference I would like to share my experiences with you in several posts. I am going to use the discussion  with Huib Schoots about going to conferences as a starting point to describe the social aspect of going to a conference. Other posts will go deeper into the content when I have digested the information bombardment.

Why should testers attend conferences?
My argument at the time  was: “Conferences typically are the place where you can learn the latest developments and opinions, submerge yourself into the testing mindset, confer with your peers, refresh your ideas and expand your network”.

Well at the Agile Testing Days this was absolutely true. But, and this is something I will have to be adamant about, this does not happen automatically. There are a few conditions to consider. Preparation You need to prepare yourself; for instance by knowing who the speakers are and what their subjects are. And not only to determine to which talks you want to go but also to ask yourself if it would be interesting to talk and discuss with them about it. Being Approachable Most of the speakers and delegates, as I have experienced, are very approachable and like to talk to you about almost anything. A conference can be so much better if you are open to this yourself and are courageous enough to step up to others and start a conversation. Look beyond the program Conferences, typically those that host different nationalities of speakers and delegates, do not stop when the talks are finished. Get together with the people you meet. Go out and have dinner with them, or get a drink at the bar. Why would you lock yourself up in your hotel room. A conference is not like a class room where you enter at a scheduled time and leave once class is over. Enjoy Go and talk about what you have on your mind. It does not even have to be about anything from the conference or testing even. There is great stuff to learn, great people to meet and lots of fun to have. And even if you think you have nothing to talk about there is a lot to gain by listening and watching the interaction. But I am pretty sure once you are there conversations will happen.

So what did I do?

Having said all of the above you might question how I fared myself. Well I started with inquiring who else, other than my colleagues (Frank Pellens, Huib Schoots, George Stevens and Robert Copoolse), was going to go the Agile Testing Days by sending out a few tweets on this matter. As it turned out there was a division between either the Agile Testing Days and with EuroSTAR within my followers. After some conversation Lisa Crispin and I agreed to meet on the Sunday evening before the conference. Now having set a date others would be able to join in. We ended up having a very enjoyable and entertaining dinner at Petite Pauline with Tamara Taxis, Liz Keogh  (Picture: Liz folding origami animals from Euro bills), David Evans, Stephan Kämper, Huib Schoots, Bob and Lisa Crispin and myself. Back at the hotel we went for another drink at the bar and found that several people that we as a group knew, like Michael Bolton, were to be found there also. So even before the conference had started I was meeting new people, talking to them and started a rolling snowball that would keep on growing during the rest of the conference.

Now that I had made contact and kept an open spirit I found myself getting to know lots of new and interesting people during the conference. Additionally I reconnected with people who I had met before and all of them added to my story of these Agile Testing Days. A story that enriched me and let me have much more content, context, depth and interactivity during the conference than when I had only gone there to listen.

PaTS

One of the other highlights was something Huib Schoots and I organized. Having heard about lightning talks and rebel alliances at other conferences we kind of felt the Agile Testing Days should have something similar. And if it were to happen we wanted to be part of it. So what better way to ensure that than to organise one ourselves. We contacted the guys from Diaz-Hilterscheid and after some explanation we were allowed to rent a room at the venue. Shortly after we made an initial selection of people we would like to meet and that we knew were coming to the Agile Testing Days. In that mail we called our gathering the Potsdam agile Testers Session or PaTS. We planned to start with the people who reacted positively on our mail and would see who else would like to join us whilst in Potsdam. On the third day of the conference we (Rob Lambert; Rob van Steenbergen; Daniel Lang; Janet Gregory; Simon Morley; Brett L. Schuchert; James Lyndsay; Stevan Zivanovic; Jim Holmes; Bart Knaack; Lisa Crispin; Olaf Lewitz; Mike Scot; Jurgen Appelo; Thomas PonnetCecile Davis; Michael Bolton; Huib Schoots and myself)  got together in the TestLab, ordered some beer and pizza and started talking.

We started by making up a prioritized list of subjects of which we did the following:

    • What makes a good tester (Nice post on this by Olaf Lewitz); Quote by Michael Bolton: “To see complexity in apparent simple things And to see simplicity in apparent complex things.”
    • Manage / lead testers to become great; Qoute by Michael Bolton: “Learning does not stick if it does not sting a little bit.”
    • DEWT / Peer groups (DEWT = Dutch Exploratory Workshop on Test)
    • Acceptable level of risk

My following posts will be go deeper into the content or the conference and PaTS, but for now there is the following post by Jean Claude Grosjean; “Agile Testing Days 2011: Day 1 – What a fabulous day

Conferences – to go or to not (let them) go….

Conferences

Every third quarter of the year a small discussion starts in our office. The subject of discussion is

 “Are any of our testers going to attend a conference, and if so how many and who?”

Generally the discussion tends to lean more to the how many then to if any testers are going. So in the past years on average four to six testers attended for example EuroSTAR and the Dutch Testing Conference. The question who was going to a conference solved itself most of the times. The number of testers wanting and able to go did usually not exceed the number of places available.

Cost and return

Having attended several conferences myself I know that the result of attending can be very rewarding. Conferences typically are the place where you can learn the latest developments and opinions, submerge yourself into the testing mindset, confer with your peers, refresh your ideas and expand your network.

Conferences, especially when they are abroad, are however rather costly given that you easily spent between 1500 to 2500 euros per person. This might not be much more than a three or four-day course, but then again it is a conference and not a course. And this seems to create the need to sell the attendance of a conference to management. So my question to you the reader is:

What do you,

or rather what does your manager,

see as valid justification to attend a conference?

I would like to ask you to participate in a small inquiry and leave your justifications as a comment.

To start a few I thought of myself:

    • As a reward or bonus
    • To expand the attendees knowledge
    • To expand the organizations knowledge letting the attendee convey what she has learned (How?)
    • There is no justification it is money waisted as the organization never sees any return