practices

250 hours of testing practice

/ Arborosa / 4 Comments

The promise

On January 3, 2011 Phil Kirkham posted a question on the Software testing club:

“so if you were to set a target of doing 2 hours practice a week every week this year, how would you spend your 100 hours ?”

Having missed the post initially I read the post as early as the week before Christmas. So I really had not enough time left to get to 100 hours in 2011. After reading the post and comments I felt however that Phil was making a valid point. One should spent time and effort on practicing and in my comment on his post I made the following promise:

“As 2012 is on the brink of starting I will try to put this into practice. As two hours seems a bit low I will spent 5 hours per week on practicing and some extra time on logging and writing short (monthly) posts about it.”

2012

So today is January 1st and I am starting to live up to my promise. Every week of this year, except for the summer holidays, I will try to practice for at least 5 hours and log the things I do. At the end of every month I will write a post sharing my activities, providing short reviews and formulate my insights.

I have started practicing earlier today by reading “Essential Software Test Design” by Torbjörn Ryber. A book that I had downloaded as a PDF before and of which I found after a number of pages and comments from fellow DEWT’s that I wanted to have the hard copy. Later today I will make time to listen to TWiST # 76. I am not yet sure what I will do for the rest of the month, but as said before I will keep you posted.

For now I wish all of you a wonderful, succesful and entertaining 2012 and I hope to meet lots of you in person this year!

Testing is some value to someone who matters

/ Arborosa / 7 Comments

Concern

I have a concern. We online testers have one thing in common: we care enough about our craft to take the time and read these blogs. That’s all very fine. However most testers, and this is based on my perception not research, most testers do not read blogs, or articles, or books or go to conferences, to workshops or follow a course. Well some of those testers do, but only when they think their (future) employer wants them to. And when they do they go out for a certificate that proofs they did so.

Becoming a tester

Regardless of where we start our carreer, be it in software engineering, on the business side or somewhere else, most testers start out with some kind of introductory test training. In the Netherlands, where I live, most of the time that means you’re getting a TMap, or sometimes an ISTQB training. And my presumption is that you get a similar message on what testing is everywhere:

  • Establishing or updating a test plan
  • Writing test cases (design; procedures; scripts; situation-action-expected result)
  • Define test conditions (functions; features; quality attributes; elements)
  • Define exit criteria (generic and specific conditions, agreed with stakeholders, to know when to stop testing)
  • Test execution (running a test to produce actual result; test log; defect administration)

But there are likely to be exceptions. For instance at the Florida Institute of Technology where Cem Kaner teaches testing.

Granted neither TMap nor ISTQB limit testing solely to this. For instance TMap starts of by defining testing as: “Activities to determine one or more attributes of a product, process or service” and up to here all goes well, but then they add “according to a specified procedure”. And there is where things start to go wrong. In essence the TMaps of the world hold the key to start you testing software seriously.  But instead of handing you down the knowledge and guide you to gather your own experiences they supply you with fixed roadmaps, procedures, process steps and artifacts. All of which are obviously easy to use for reproduction in a certification exam. And even this still could still be, as these methods so often promote, a good starting point to move on and develop your skills. Unfortunately for most newbies all support and coaching stops once they passed the exam. Sometimes even facing discouragement to look beyond what they have learned.

Non-testers

To make matters worse the continuing stance to make testing a serious profession has brought line managers, project managers, other team roles and customers the message that these procedures, processes and artifacts not only matter, but they are what testing is about. These items (supposedly) show the progress, result and quality of testing being undertaken. Line and process managers find it easy to accept these procedures, processes and artifacts as measurement items as they are similar to what they use themselves according to their standards. So if the measurements show that progress is being made and that all artifacts have been delivered they are pleased with the knowledge that testing is completed. Customers or end users go along in this but face limits in their belief of these measurements as they actually experience the end product. Like testers they are more aware that testing is never really ended and about the actual information about the product and not about testing artifacts.

So?!

New methods and approaches such as agile testing have brought the development roles closer together and have created a better understanding for the need and content of testing to both the team and the stakeholders. Other approaches, like context driven testing, focus more on enhancing the intellectually based craftsmanship of testing, emphasizing the need for effective and efficient communication, the influence of context on all of this and that software development is aimed at solving something. And thus the aim of testing is shifting from checking and finding defects to supplying information about the product. Regardless of this however and inspite of how much I adhere to these approaches I think they have a similar flaw as the traditional approaches. Like TMap or ISTQB neither of them go outside of their testing container enough to change the management and customer perception. They still let management measure testing by the same old standards of counting artifacts and looking at the calendar.

Challenge

I think we as a profession should seek ways of changing the value of testing to our stakeholders. To make them understand that testing is not about the process or procedure by which it is executed nor about its artifacts, but about the information and value to achieve business goals it supplies.

I myself cannot give you a pret-a-porter solution so I challenge you, my peers, to discuss with me if you agree on this vision and if you do to form a new approach for this together. I will gladly facilitate such a discussion and deliver its (intermediate) results to a workshop or conference at some point.

Exercising agility

/ Arborosa / Leave a comment

Sprint 0 – The idea

While getting in the mood for the Agile Testing Days 2011 in Potsdam I remembered  seeing a XP exercise sometime before. Essence of the exercise was to use the agile manifesto, its principles and to link them to development practices. This really felt as a great practical extension to my previous two posts on agile. Only trouble was that it had forgotten who wrote it so the exact steps were unknown to me. Also I remembered that it originally targeted an XP development audience and  that I felt that it needed some adjustment to be useful for (non-coding) testers.

At the same time I was getting ready to participate in the TestNet workgroup theme night with the Agile Testing workgroup. While e-mailing with the workgroup chair, Cecile Davis, I offered to use a recreation of the exercise suitable for testers and to translate the manifesto and principles into Dutch along the way.

Sprint 1 – Proof of Concept

At the following meet the other workgroup members liked my idea and draft version of the exercise. So at the TestNet workgroup night on November 8 I have presented and executed the exercise in front of some 30 people.

All in all the execution of the exercise was a success and I received positive feedback. Several participants were interested in doing the exercise with their team. But personally to be honest I quickly saw after the introduction that in spite of the good idea the six exercise steps I had written were not going to work with such a large group. So the exercise was saved by improvising, getting some goodwill and by offering additional explanation during and after the execution. Also I discovered that trying to keep it inside the period of an hour was a real challenge.

In good agile tradition I concluded the evening with a retrospective. Combining feedback from the participants with my own feedback I put new items on the (virtual) backlog. First one was to write this post, second to do a re-write of the exercise in general and thirdly to make an adaptation of the exercise steps in order to make them suitable both for smaller and larger groups. Both the content and the ‘new’ exercise steps of the exercise will be part of the following sections. The Dutch version, containing I believe the first complete translation of both the agile manifesto and the principles, will be placed on the TestNet ‘Agile Testen’ workgroup page [TBD].

Sprint 2 – The exercise (published version)

Preparation:

  • Large separately printed sheets of the agile manifesto and the twelve principles
  • As many  A4 / Letter print outs with the practices on them as you have participants
  • Post-its or similar
  • Markers
  • Introductory presentation about the agile manifesto, the principles and the practices
  • Know what you’re talking about
  • A room with possibility to form groups, walk around, and hang the print outs on to the wall.

Step 1:
Give a (short) presentation on the Agile Manifesto and its principles.
Depending on the agile experience of your audience this can be shorter or longer. Check my previous two posts for to get additional information or inspiration.

Step 1B (small groups):
Group members discuss what the principles mean to them and how they map to the Agile Manifesto.
Depending on the time you have and on the familiarity of your audience with the Agile Manifesto you can spent longer or shorter amounts of time on this. In larger groups this tends to take a lot of time and is probably best added into the step 1 presentation or left out all together.

Step 2:
Present the practices and handout a hardcopy version of them to all participants.
Depending on the experience of your audience (and the time you have) you can provide information about all of the practices (takes a lot of time), or let the audience indicate which ones need to be elaborated or skip explanation al together.

Step 3:
Have the group go up to all of the principles and have them discuss  and map the practices that they think fitting to the principle. Mapping should be visualised by writing the practice on to a post-it and sticking it to the top of the sheet if it is a good fit, to the bottom of the sheet if it only fits partially.
The group should form a consensus on the which practices fit and to what extend. The aim here is to learn by actively linking practices to agile principles by discussion and argumentation. When necessary the facilitator should provide additional information and elaboration about the practices. 

Step 3B (Large groups):
Divide the audience into smaller groups of no more than 6-8 people. Then execute step 3 by letting them go by all principles from a different starting point.
To aid the visual result you can hang multiple versions of each principle (as many as you create groups) next to each other and differentiate the groups choices in this way.

Step 4 (Large groups only):
Have each group pick one or two of the principles and let them explain why they chose those practices and why they placed them higher of lower on the sheet. The other groups should be able to ask questions.
This step is more about sharing information and reasoning then that it is about argumentation and justification. A single group will have done this automatically during the exercise.

Final step:
Have all members evaluate what they have learned and taken away from this exercise. One of the take aways should be to pick one or more practices that they are going to actively work on during the next period. Then execute a (quick) retrospective on the execution of the exercise.
Depending on the group size and time you have left this can be down by letting each member express this to the group or to let them do this individually later.

The agile manifesto, the principles and the practices

To conclude this is what it is all about. Starting of with the practices:

Practices

A practice is something that has proven to be valuable in a certain context and offer insight into solutions that may or may not work in your situation.

You can do this with the list below for a start. But preferably create you own shorter, longer or more suitable list. Basically you can do this with any kind of practices not just test related practices.

  • Manage risk
  • Execute your project in iterations
  • Embrace and manage change
  • Measure progress objectively and understandably
  • Test your own test cases
  • Leverage test automation
  • Team change management
  • Everyone can test (and owns quality)
  • Understand the domain
  • Describe test cases from the user perspective
  • Manage versions
  • Co-locate
  • Leverage patterns
  • Actively promote re-use
  • Rightsize your process
  • Continuously reevaluate what you do
  • Test Driven Development
  • Concurrent Testing
  • Pair Testing
  • Specification by example
  • Acceptance Test Driven Development
  • Plan sustainably
  • Stand-up meeting
  • Plan in relative units
  • Configuration management
  • Learn by doing
  • Whole team approach
  • Shared Vision
  • Use Case Driven Development
  • Risk Based Testing
  • Evolutionary (Test) Design
  • …..

The agile manifesto

We are uncovering better way of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • Continuous attention to technical excellence and good design enhances agility.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Remembered who the original exercise was from: David A. Koontz