You might argue that this already sits with the CTO however the CTO's job is hectic enough and visibility of cross-silo performance can easily slip under the radar.The key requirement is for someone to have overall responsibility for application performance. This needs to be across all business units and all projects whether they be in discovery, in-flight or in production.

Fundamentally underpinning this role is the need to correctly align infrastructure and application KPI's. This means that an applications footprint within the IT Estate is always a known quantity in terms of resource provisioning and consumption and how It does (or will) interact with other applications and services both internal and external.

I see the CPO as working with the CTO/CIO to provide governance on Business expectations for performance and what IT can realistically deliver.They should also be involved in the software procurement process to ensure that appropriate performance SLA's are part of every supplier contract.

The dawn of a new age in IT or just common sense?

Biography

Originally hailing from Auckland, New Zealand, Ian Molyneaux has worked in IT for over 35 years. He is Head of Performance at software consultancy Intechnica, which specialises in .NET development and performance assurance for the enterprise with a focus on cloud. Last year Ian published a chapter of his book 'The Art of Application Performance Testing' as a EuroSTAR eBook. You can download a copy here.

I remember once having a tester in one of my training sessions who explained to me, that she was really satisfied at the end of her working day with a huge pile of new bug reports. She was not really bothered with the follow-up and she was certainly not really aligned with goals of the organization she was working for.

An exotic example? Maybe, but I do believe that testers in general can increase their added value if they focus on their stakeholders a little more. If you want to increase your added value there are three things to keep in mind.

Design for traceability

The first tip is self-evident really. It is all about transparency and traceability. Even a medium size project has many systems, functions, interfaces that need to be tested. Just executing a lot of tests might result in great bugs being found, but that alone is not enough. If we as testers want to add value, we should be able to translate each single bug towards items that have meaning to our stakeholders. This translation should not be a tedious process that takes hours to figure it out, but we need to have an clear overview, dashboard so you like, that can be generated easily on the fly. Unfortunately many of the test projects that I see around are neither have traceability in their architecture, nor does the test department knows what the organization really wants.

Align with stakeholders needs

Testing is a risk based activity. Sure, but recent research learned that only 50 of the testers actually do RBT. For the other 50%, the ones that do RBT, risks might seem a nice translation of the customer needs. But, risks do not tell the whole story.

We should not forget that many decisions are not based upon rational arguments, but are in fact fear driven by Project Managers and stakeholders who aim for success, comfort and a feeling of being in control. Conversely, loss, pain and fear are strong negative drivers that determine our behavior to a great extent. We cannot neglect them. How do these key players act when they are pushed outside their comfort zone and the fear of failure becomes tangible?

If we really understand what drives our Project Manager and stakeholders we can design our tests in such a way that is provides them the comfort and takes away their fears. Luckily testing is a discipline that provides us with many tools to do so. With these tools we can improve our tests, and do better test reporting. Good test reporting requires good data and an understandable message. The first is created by having a good traceability. The second is achieved by telling a good tester story.

Tell a good testers story

Recently I coached a colleague of mine who was about to present the results of his test project to the senior management. His first impulse was to announce the number of executed tests, bugs found, etc. It took him some time to translate this data into useful information.

The useful information is of course strongly related to the comfort needs of the stakeholders and it tells a story. The story explains what you and your team did, the problems you had to overcome and the solutions you found. The story also justifies the effort taken, it clearly explains how this aligns with the needs of the organization and the benefits gained from the results. Important lesson learned is that a story is nice to listen to and it's personal. You need to back up what you are saying by solid arguments, but should not blur your message by putting in too much details.

Combining these three elements will help you designing better tests, putting a focus on the right areas and make your efforts better understood. Doing these will make the difference between being one of those people in the office who cost money or one of those who matters.

Biography

Derk-Jan de Grood works for Valori as product manager and well known speaker at conferences. He is specialized in getting more out of testing by focusing on the value chain and business-it alignment. Recently he published a book in which he describes the human side of IT and explains how testing can help to increase comfort and grip for our Project Managers and stakeholders. This book is supported by a full day training that enables you to get commitment for your test activities, contribution to the project success and become the wing partner of your project manager.

It is with great sadness that I have to report to the testing world the demise of the mythically, magical and altogether larger than life character Brett Gonzales - 'demise' as 'death' seems too final a word for someone who is purely imaginary. The end came swiftly; he departed doing what he liked doing best - testing, although 33,000 volts passing through his body was not one of the expected results. Brett managed to fail that test and raise the bug report - professional to the end. Burial at sea will ensue, to prevent his final resting place becoming a place of pilgrimage for testers.

An obituary will appear in the next edition of "Fishing for Wimps". Seventeen nations have already granted Brett citizenship [since 00:01 on 02 December 2011], Zimbabwe with the issue of a genuine 1928 passport (even though this was decades before the country came into existence). A book of condolence has been opened at the Peruvian embassy in Australia, and police are on hand to deal with the enormous number of people arriving. Other people may wish to wait until Brett is inducted into the Testers' Hall of Fame to salute his career.

Details of Brett's life have appeared on the EuroSTAR blog, but for readers unfamiliar with the finer points of his life, items are listed below, with one "passing reference" article included.

May 2010 - 'Missing' submission for EuroSTAR 2010

Dec 2010 - First submission for EuroSTAR 2011

April 2011 - Example of 'passing reference' article

Oct 2011 - Nomination for European Tester of Excellence award

Nov 2011 - Great Testers of our Time #12 Brett Gonzales

Nov 2011 - Hello EuroSTAR Manchester - this is Manchester (Vermont)

Brett's passing is personally a relief, having misguidedly promised to include a reference to this great tester when writing or speaking on Software Testing in 2011. (This bit, if no other, is true). It is time to draw his career to a close whilst, if not actually winning, then before the joke wears out. I can get on with my life without the shadow of Brett Gonzales looming large, and thinking when faced with a difficult requirements document "Well, what would Brett do?" Brett never married, considering himself wedded to the profession and took a keen interest in the careers of many (including the Qualtech 'girls' - although none managed to obtain a signed photograph of him). Photographs of the great man are rarer than hen's teeth. When asked if he was sad he had no children, Brett replied: "but I did. Thousands of them. All Testers".

There may be further future features from Brett, as I have been appointed his literary executor to promote the prodigious output from his keyboard, much of which is unpublished. His first book dates from the time he was designing baby equipment - "Dummies for Dummies". Two volumes as yet unpublished are "Bugs, Bugs, Bugs, Bugs, Bugs, Bugs and Bugs", and the voluminous "Brett Gonzales Book of Quotations". The latter gives items attributed to Brett, but that he never actually said; "The only good developer is a dead developer" is an example, a sentiment he would not agree with. Rumours of "Brett Gonzales - The Movie" are a total fabrication.

It is hoped that a posthumous award of "European Tester of Excellence" will be made to this giant of our industry in the future. This could be one way to stop Brits walking off with this award - yet again. No-one is quite sure of his nationality at birth, but Brett definitively is not (sorry, WAS not) a Brit.

So adios, amigo! You will be missed, by me if no-one else.

IDC and Gartner forecast that the enterprise spending on independent testing services would cross the benchmark of $30billion by 2015. Yet another highly reputed research firm, PAC has forecasted the software testing spends to hit Euro 100bn by 2014!

It is not surprising to industry folks that testing today is seen as the "Fastest growing niche in IT space" What is it that is driving such unprecedented growth in the software testing market? A closer look points us to a few towering factors that form the kernel of this spend:

1) Rigorous up-front requirement validation: As a result of poor requirement gathering, the cost incurred in removing the defects later in SDLC is very high. Adding further, the increased code complexity and high end development environment are leading to pre and post deployment defects. As a result, enterprises now understand the benefits of driving validation to the front-end. Hence they are adopting front-end validation strategy that  minimize the cost spend on quality initiatives by reducing the number of defects identified during validation life cycle.

2) Increasing use of cloud based services: With more and more enterprises offering its services over cloud, security remains one of the most important concerns. Securing the apps over the public and private cloud is one of the major mottos of any enterprise. Transparency and open access being the main features of cloud, has also led to threat like hacking of sensitive information. Thus testing the cloud is in no small measure contributing to this massive surge in enterprise spending on independent testing and validation services. Add to this, the spend on performance testing that many enterprise consider a natural pasture for cloud.

3) Building risk mitigation strategy: Though this strategy is seen more as a part and parcel of driving testing throughout the SDLC, most enterprises are taking this approach very seriously. Enterprises are trying to drive down the defects in first place so as mitigate the risk that arise post release. As a result, demand for test automation, test framework, end-to-end app testing, etc. which can mitigate the risk, are leading to  mounting demand and spend on testing services.

4) Increased adoption of TCoE: Today, enterprises are highly aware about the benefits and ROI they get through TCoE. Though not everyone is trying to setup their own TCoE, outsourcing apps to a third party independent testing vendor is always an option. By leveraging vendor's established testing framework and test processes, an organization can actually move away from their unproductive methodologies.

5) Automation: Automating common processes help enterprises reduce its time to market thus minimizing overall validation efforts. Automation of regression test beds or automation of platform configurations is the common area of interest for various organizations. Though the initial investment required in automation might be high but the benefits one gets outruns the cost easily in long run.

6) Compliance testing: The increasing number of regulatory compliances for each industry has paved the way for compliance testing. Every regulatory firm is coming up with a new set of compliances which vary for each and every industry (like PCI DSS, SOX). Failure to meet any of these compliances can cost permanent damage to one's brand and business. Thus, in order to meet these industry-specific compliances, compliance testing is gaining currency.

7) Product IP protection: Testing vendors are now-a-days offering robust protection frameworks to help enterprises (especially product based enterprises) protect their IPs against any theft. This kind of protection is extremely important in order to gain customer confidence and is directly linked to the enterprise's revenue generation strategy.

8) PaaS testing complexity: Platform-as-a-Service (PaaS) comes with its own set of testing complexity. On one hand it facilitates its customers to directly use the underlying components thus leveraging integrated development environment (IDEs) in cross browser environments, they also demand sophisticated analytical techniques to validate components functionality and performance. Apart from these, they also need to get evaluated for load testing and compatibility testing with various browsers.

The EuroSTAR conference is always the first thing in my Calendar, and the time blocked out. However, a serious diary and timing malfunction means I am not with the community in 2011, missing my first conference for 17 years. This is as a result of using Google Large Itinerary Planner (GLIP) late at night, without paying close attention. My whole autumn consulting program was geared around being in Manchester in late November, and the flights and hotels were booked months ago. I did wonder why flights from Amsterdam (Schiphol) to Manchester necessitated a change at New York's JFK airport, but did not question it in sufficient detail.

So, I currently found myself in Manchester, with a late autumn schedule of work spanning the forthcoming Thanksgiving holiday weekend (Thursday 24^th Nov). All assignments are in the vicinity of Manchester. That is Manchester, Vermont. Around here, the snow on the slopes of Mt Equinox is like a Good King Wenceslas pizza – deep and crisp and even.

However, it has been brilliant following the conference from afar. You would not believe the amount of traffic on the airwaves coming from Manchester (England), well into the United States early hours, so I am going to bed late and getting up early (and going into the office to get some sleep). As well as blogging and tweeting (and some people twittering ....... they twitter on and on and on and ON!), the growing tendency is twogging; tweeting and blogging at the same time. A master of this is Michelle Bilton, with some very inspiring material already produced. And then there was one track session speaker, blogging as he spoke. Now how do you do that! The jacket of the lady sitting in the front row of his session (which irritated the speaker intensely) must have been really bad!

I have enjoyed the references to the Euro currency crisis, and the airwaves were full after the Serbian keynote session. He seems to have got you thinking, about Berlusconi metrics if nothing else. Otherwise, it was a shame that all those from one small nation arrived thinking that they should wear fancy dress. I felt really sorry for the two people (fortunately husband and wife) who were jointly dressed as a camel; the available pictures are both hilarious and sad. It seemed that e-mail traffic to the EuroSTAR team from the group booking had been compromised – hence they all want to learn about security testing on the web. Now that seems to me like closing the stable door after the camel has bolted.

Both the Program Committee and the EuroSTAR team from Ireland have done a cracking job, with a great conference. My real joy is that the venue for the 20^th EuroSTAR conference in 2012, Amsterdam, is without a corresponding airport on the US side of the Atlantic. So I can use GLIP late at night without being sent to the wrong place!

Over and out from Manchester (Vermont).

Have you been in similar circumstances, when faced with a problem that you have been over and over in your mind? It may be 'work related', but possibly completely different: my wife came home from her work one day with a set of conundrums that colleagues could try and solve to gain a (small) prize. One of them was the seemingly simple question: "what is black when you buy it, red when you use it, and grey when you throw it away?" The common theme between this 'problem' and that I faced when the UAT schedule inexplicably halted is that the answer is not obvious. No matter how long you thought about the black / red / grey problem, you have not solved it until you have solved it, and for this particular question, there is almost no incorrect solution that is near but not right.

For the black / red / grey problem, the answer hit me like a bullet between the eyes later the same day I had heard the question. In case you are wondering, the answer is 'coal' - when bought, it is black, being used, it is burning, so is red, and when the fire is finished, all that is left is the ashes (grey). With hind-sight, the answer is blindingly obvious. The real problem is finding the answer! (And if you think about it, for many, many things, with hind-sight, the answer can be seen with a clarity that was not present previously).

The "bullet between the eyes" moment for the black / red / grey problem arrived when I was doing something completely different, in this case walking in the countryside, thinking about how to negotiate a hillside slope with the twin problems of a slippery path and cow dung. Thinking about something else! That was how it happened, described by Brett Gonzales as a "toothbrush moment". This wonderfully descriptive term illustrates the processes of not thinking about 'the problem', but how to get the toothpaste onto the brush (an action we all do when driving on autopilot) and suddenly ...... ping!

It is possible to have 'toothbrush moments' when engaged in all manner of things. Some of my best ones are when mowing the lawn, having a bath or walking between the train station and the office. You are doing something completely different when suddenly it hits you. That is the answer that you had been looking for. It is something to do with the way some minds continue to dwell on the matter in the background - and occasionally I wake up at 03:00 with the answer, a toothbrush moment when I am asleep!

Before finishing, may I give some words of warning about the use of the toothbrush? Firstly, it is not possible to use this 'technique' like a light, turning it on at will. Repeatedly cleaning your teeth will not always deliver the answer - otherwise Brett Gonzales would have the cleanest teeth around. The second point to make is that because you have an idea when cleaning your teeth (or whatever your best creative activity is) does not mean that it is necessarily 'the solution' - it still needs validation in appropriate ways.

So what was the problem between the System Test and UAT environments? It was down to the people running the tests. Those engaged in System Test did not know the existing business processes, whereas the UAT activity was performed by users (as the name suggests), with an intimate knowledge of the current processes. Sometimes, just sometimes, they slipped into LIVE-running when undertaking the UAT actions, rather than use the mended business activities, those that would be implemented by the new software. Obvious really - but it needed a toothbrush moment to see it. The answer enable implementation in the first quarter of the financial year, so presumably the business manager still got the bonus that was rumoured.

I had a 'toothbrush' moment when writing this article in mid November 2011. At the design stage on an agile project, there would be a challenge when processing data from the latest or a previous month for a second time. Space prohibits describing what needs to be done, but now I have the answer which came when I was doing something else - writing about "toothbrush moments". How ironic is that!

So my advice to you is to always keep a pen and notepad by the toothbrush holder. You never know when you might need it.

The award will be presented to the best story which articulates 'Developer & Tester Collaboration' addressing the main advantages of bringing these distinct teams and skill sets together.

All entries to be sent to us no later than Friday 18th November by midday and be a maximum of 500 words while entries can be based on any developer/testing solution. Please send your entry through to i-taniam@microsoft.com and our internal panel will judge each story with the winner being announced on the night.

As an incentive, in addition to this Microsoft Award, we would also like to offer the winner an invitation for 2 people to attend one of the following training courses. These will be held at our Microsoft office in Reading;

• 3 day Visual Studio Team Foundation Server 2010 overview course (March 2012)*
• 2 day Microsoft Visual Studio 2010 Test Manager and Coded UI Deep Dive (Feb or April 2012)*

*Dates of the training courses have already been set and are not transferable.

We very much look forward to reading your stories and celebrating with you at the EuroSTAR Gala Awards.

Rational Team Concert (RTC)
RTC provides these major capabilities: project planning, change management (work items), software configuration management (SCM), and build management. Teams can deliver software solutions using RTC's features, and they can also use Jazz-based connectors to access enterprise-scale capabilities and assets in Rational ClearCase, ClearQuest, Synergy, Change, and Build Forge.

In the area of project management, RTC 3.0 provides formal project planning, scheduling, time tracking, and resource management functions, such as Gantt Charts and risk management artifacts. This is in addition to the existing support for agile project planning, including plan risk assessment, support for developer taskboards, release planning, and Web-based access to project iteration plans and permissions.

Within a project, business users and customers can access the repository and project dashboards directly. Thus there may be little or no need for custom management reports-customers can see the project work items and dashboards, understand the status of the project, and directly add their own issues or change requests. However, this also means that customers can closely monitor a team's progress and potentially scrutinize decisions made within the team. Rational product teams leverage this increased customer involvement to build stronger relationships and demonstrate their quality work through frequent releases. As customers become accustomed to releases that are weeks rather than months apart, they become more engaged and flexible. They learn that with short iterations, issues that are not resolved in a particular iteration may be delivered in the next one, only a few short weeks away.

In the dashboard, RTC now supports the OpenSocial standard as well as IBM iWidgets. This means that any tool that supports this standard can be incorporated into an RTC dashboard, and tools like Gmail™ and iGoogle™ can incorporate RTC dashboard gadgets into their homepages.

Rational Quality Manager (RQM)
RQM is Rational's Web-based test management portal built to the Jazz architecture. RQM helps teams drive quality from a business perspective and better align development, testing, and delivery teams' activities.

Focused on addressing the needs of business analysts and QA professionals, RQM employs a test plan-centric view of testing assets. It provides the ability to use different perspectives for accessing and viewing testing assets, based on the user's role. For example, managers can review timelines and status reports for testing cycles, while business analysts can concentrate on test coverage for business requirements. In addition, test planning assets can be related to specific testing executables stored in Rational functional and load testing tools.

Extending the value of Rational Quality Manager, Rational offers Rational Test Lab Manager, a solution for test lab management. Users are able to inventory all of their test lab assets (e.g., CPUs, middleware, databases, applications), derive utilization rates for those assets, schedule a specific configuration to use for a testing session, and then physically deploy that configuration.

Rational Requirements Composer (RRC)
In the area of requirements definition and management, Rational offers new visual tools and provides integration among requirements, SCM, testing, and other ALM tools.

RRC provides graphical modeling, storyboarding, and sketching tools for eliciting and defining requirements, and uses a wiki-like platform for enhanced collaboration among stakeholders and development teams. RRC also includes a Web client with support for review and approval of requirements.

Users can also relate this rich requirements content through RequisitePro to other lifecycle assets, including test cases created in RQM, and thus be able to determine test coverage and traceability for requirements. Over time, Rational intends to evolve its requirements management portfolio to provide a unified set of capabilities based on the Jazz architecture.

The Rational Solution for Collaborative Lifecycle Management share common services for dashboarding, Work Items and administrative task like setup, user administration and process definition.

For detailed descriptions of RTC's capabilities, go to http://www-01.ibm.com/software/rational/products/rtc/
For detailed descriptions of RQM's capabilities go to http://www-01.ibm.com/software/awdtools/rqm/
For detailed descriptions of RRC's capabilities go to http://www-01.ibm.com/software/awdtools/rrc/

Alternatively, come and visit the IBM stand at EuroSTAR where we will be happy to show our toolset.

And now it is time for the European testers to fill in the questionnaire.

What is all about? The word benchmark suggests the possibility of making comparisons and I am aiming at two levels.

First of all it is about you, the software tester. It will be possible to compare yourself to other European testers: your backgrounds, your education, what kind of organization are you working for, etc. It is also about the way you work as tester: e.g. what are your favorite test techniques, from which point on are involved in a project and who many or your test colleagues are using master test plans compared to you?

We have to wait to see the second comparison because this will be done in time. After this first European Benchmark more benchmarks must follow, say every two or three years. Then we will see the major changes in the world of testing: e.g. will agile take over and become the most important method for developing software?

The questions of the benchmark are brought together in a motto:

Tester @ work, because it is about you, the tester. It is about the organization were you are testing (and this can differ from the organization which pays your salary) and it is about how you do your test work.

But before we can make these comparisons and we will know everything about the tester@work we need data. We need you, to fill in a questionnaire of 40 questions (in 10 minutes time) and in the spring of 2012 the first results will be published in a e-book brought to you by EuroSTAR.

So go to www.softwaretesten.nl or www.estb.nl and fill in the questionnaire and also ask all your colleagues to do the same!

Besides filling it in at home, it will be possible to fill it in at the EuroSTAR conference. You will find computers available at the lobby.

If you want to know more about the benchmark? Please contact me at a.kramer@eclipseit.nl

There is a lively debate as to whether 100% code coverage is a) attainable and b) necessary. As an ex programmer, I would suggest that 100% code coverage is not really attainable and, in fact, the better the programmer the LESS likely is this to be attained.

So should 100% code coverage be the goal? In my opinion, no, and research by Richard Bender, of Bender RBT Inc, suggests that 90% code coverage would be the maximum that can be expected. A more effective and realistic goal is a 100% functional coverage, in other words, ensuring that all of the specified requirements are satisfied by the tests.

Yet once you have decided on your test cases, you still need to prepare the physical data to test your application and all too often, the creation of data to satisfy the test usually takes 3 to 5 times more effort than it takes to design the test cases themselves.

Populating data directly into databases via APIs or directly into disparate applications is hard work and must be factored in. In our case, we use Datamaker to populate the data directly into the database.

Generating data is by far the most effective method of creating perfect test data. The advantage is that you produce the right kind of data you need; ensuring accuracy and the right spread of data guaranteeing the data is as you need it.

In addition to this, the next time you need to test you will already have test data that can be modified slightly and used with slightly different combinations of data criteria.

As testing now accounts for up to 60 per cent of the development lifecycle of an application, there is a strong business case for ensuring that test data is fit for purpose. Datamaker test data management solutions now work with HP testing technology and can be embedded in HP driven enterprise management.
It is another step forward towards ensuring that whatever the system and whatever the challenge, creating the specific data needed to comprehensively test new functionality will no longer be a stumbling block.

October saw the announcements of various Nobel prizes - or as I heard from a Norwegian economics professor recently: The <organisation's> prize in <subject> in memory of Nobel…

I read an article, ref [1], on some characteristics that could be identified in Nobel prize winners (especially the physical scientists) and I started seeing a similarity to some good/useful traits in software testers. Of course, there is no such prize for software testing, but if we were to 'recognise' good testers and good testing, what might some of those characteristics look like? Well, let's take a look…

1. Be inquisitive - your whole life

This is one of the building blocks of good testing. Inquisitiveness leads to reflection which leads to questions which leads to more reflection, etc. The subject of the reflection may be the product or project under test, it may be ones own toolkit (both physical and mental) or it may be a discussion or conference presentation.

"Every man ought to be inquisitive through every hour of his great adventure down to the day when he shall no longer cast a shadow in the sun. For if he dies without a question in his heart, what excuse is there for his continuance?" Frank Moore Colby

2. Tell and describe to others what you are doing.

This is another building block for a good tester - and crucial. The ability to describe (report) on your activities - why you are taking certain courses and not others is an important ability. Describing and discussing the activity with different people (especially non-testers) is a wonderful educational exercise - learn to like it and you'll like to learn!

"Communication is a skill that you can learn. It's like riding a bicycle or typing. If you're willing to work at it, you can rapidly improve the quality of very part of your life." Brian Tracy (American TV host)

3. Question commonly-held truths

If you're not asking or thinking about questions then you're probably not learning. Do you know what assumptions you work with in your daily work? Are they good/ok to have? Do you know why you are doing things? Maybe, now is a good time to re-evaluate.

"In religion and politics people's beliefs and convictions are in almost every case gotten at second-hand, and without examination, from authorities who have not themselves examined the questions at issue but have taken them at second-hand from other" Mark Twain

4. Be tenacious

It's not usually plain sailing being a tester. Sudden unanticipated changes occur in a projects or assignments. Some discovery might mean some amount of re-work or backtracking is needed. It might mean you 'wasted' some work or effort in a different direction. Setbacks occur, but these are lessons to store away in your library of experiences. Take a look at those experiences periodically (some call this a retrospective) and think if there are things to change or lessons to be learned.

"Patience and tenacity of purpose are worth more than twice their weight of cleverness." Thomas Henry Huxley (Biologist)

5. Be ambitious

Keep reminding yourself what your goal is (or goals are). Whether this is something for your current project or as part of a stepping stone in your career. If you want to be a good tester you need to think about the things that need improvement and work on them, as well as the areas to continue doing well.

"I'm tough, ambitious, and I know exactly what I want. If that makes me a bitch, okay." Madonna

6. Take research seriously! Make research and investigation a lifestyle

This is life-long learning. It's not enough to learn something once and think that you 'know' it - if you haven't experienced failure with your new learning then you've missed a learning opportunity! Reflect on your learnings and be open to new avenues for research.

"If we knew what it was we were doing, it would not be called research, would it?" Albert Einstein

"Research is creating new knowledge. " Neil Armstrong

7. Have a structured approach

Have a story for what you do and why. This is not just about connecting your project needs (requirements) to your analysis, execution and reporting, but also creating a meaningful and convincing bug report.

Some (managers?) interpret structure as excluding exploratory approaches and, usually, adopt a Taylorist approach to testing, ref [2]. Usually when people don't see structure it's because something doesn't fit their 'template' of structure. If you have structure in your work make sure you communicate/display this.

"Innovation is not the product of logical thought, although the result is tied to logical structure." Albert Einstein

8. Find an interesting area and a good mentor

Testing has many facets to get involved with - the topic area is wide, never mind the different domains involved. Whether you want to be a specialist or a generalist, look for people to learn from, to bounce ideas off, to help you grow as a tester. Whichever area you touch search out mentors that either specialise or have relevant insights or that can point you in the right direction of somebody else that can help.

Surround yourself with bright, smart and knowledgeable testers. You can do this via local groups at your place of work, local groups in your vicinity or by online communities.

"Mentor: Someone whose hindsight can become your foresight" Unknown

References

[1] This list was inspired by an article in a Swedish technical paper (NyTeknik, 5 Oct 2011)

[2] Taylorist approaches in testing: http://testers-headache.blogspot.com/2011/08/taylorism-and-testing.html

Bio:

Simon has worked with professional software testing since 1992, as tester, team leader and coordinator, thinks of himself as an emergent learner and divergent thinker.

He actively expands his variety of sources to improve the way he and others think about testing and test leadership, which he considers an activity at the crossroads of the social sciences, prize-winning investigative journalism and humility.

He believes in good testing - grounded in the idea that we search for questions appropriate to the problem.

Occasional speaker, occasional blogger, constant learner.

Blogs at http://testers-headache.blogspot.com/

Tweets at @YorkyAbroad

After Brett Gonzales was found to be ineligible for the European Tester of Excellence award, the EuroSTAR offices were inundated with requests for more information about his career. (Inundated = two e-mail enquiries [both from brett.ignatius.gonzales@gmail.com , as it happened] and an incoherent answer-phone message). So after wide-ranging investigations, we would like to share with the wider testing world further details from this giant of our industry. This continues the "Great Testers of our Times" occasional series, with previous entries appearing in the Norwegian Midwives Journal and the Geneva City Newsletter as well as on the Great Testers of our Times web site (www.you_are_having_a_laugh.com ).

The best way to illustrate his long and productive career is to give information on four projects Brett has worked upon. Four project, four continents; how cool is that! Readers will be amazed at his incisive insight, determination and sheer hard work as he fought against aggressive timelines and internal company politics, forever keeping his end-goal in mind: 'How can I ensure that I make myself indispensible, and hence able to command large fees into the future?'

Brett was the sole tester involved on the Implementation and Conversion for the Euro (ICE) project for Danish United Mutual Provident (DUMP). He was brought in 5 months before the introduction of the Euro, after his turbulent time at the Danish Cheese Board (DCB)*. Design and coding had been underway for many months, and Brett managed to turn the project around, and enable the immovable target to be met. Or it would have been, if Brett had not revisited the documentation four days before go-live, and seen that the whole of the requirements, written years before, was prefaced by the words "On the assumption that Denmark will join the Euro, the following matters need to be covered in their entirety ........". This signalled the end of THAT particular project, and sunk the promising career of many of those involved. But not Brett!

* At DCB, there were problems with the production control software, and the organisation almost went broke when unable to sell 15 tonnes of 'Danish Purple' cheese and 20 tonnes of 'Danish Black'.

In late 1998, Signor Gonzales advised the Malaysian government on Y2K issues. His novel approach was the realisation that Malaysia would not be the first country (in terms of sunrise) that would encounter 00:00 on 01/01/2000. There would therefore be over five hours to solve the problem - surely this would be sufficient to fix one defect, for "the Millennium Bug" was only the one problem, wasn't it? Australia and New Zealand would have fixed 'the bug' first, so Brett reasoned that he could use his extensive network of worldwide testing contacts to "borrow" the solution. His action on this project alone saved the country $millions; more that the combined GDP (at 2010 values) of at least 14 sub-Saharan African countries.

Brett also saved millions when he worked for Bolivian State railways. His initial suggestion for process improvement was to introduce inspections. This was misunderstood (lost in translation, perhaps, as his Catalan Spanish is sometimes deliberately deemed incomprehensible in Latin America) and instead of software inspections, ticket inspections were implemented. Revenues increased dramatically, and Brett was awarded free rail travel throughout South America for life.

Aside from his usual role, Brett worked as Project Manager to implement in-bound and out-bound passenger segregation at Johannesburg airport on behalf of "a major South African airline". His idea of using step-wise refinement was received enthusiastically and embraced by the whole team. Subsequent recommendations for escalator-wise refinement and corridor-wise refinement were not implemented. However, the project completed within time, within budget and was of higher than expected quality, yet another time that Brett hit 'the big three' in his long and illustrious career.

Ladies and gentlemen, I give you Brett Gonzales; a true 'Great Tester of our Time'.

SPOOF

Here is a suggested two step approach to process improvement.

Firstly, you should customize your process to meet the types of projects your organization undertakes - for example, you may use an OOTB Scrum template, a Iterative template, or a standard Traditional (Waterfall) process template. These process templates should be reusable assets that you can quickly and easily apply to any project, with the ability for further, project-specific customizations.  These project specific customization can then be used as templates for new projects.

Next, you should enact that process to drive the workflow and team 'rules of the road" into everyday team activities. Only by making process creation and enactment seamless activities can you ensure that the process is actually being followed.  Without process enactment, guidance simply becomes "process shelfware" that gets read once and is quickly forgotten.

It's also helpful to provide a phased-in approach to process enforcement. Ideally, teams can enjoy lighter weight process enforcement early in the software life cycle, encouraging early stage experimentation. Closer to release, rules should be enforced with greater rigor to protect the integrity of the release.

Or have you got the same experience as I do that the difference in projects is made by people?

One project is a great success and another is a complete disaster. Even though both use the same process, the same test method and the same toolset, how come?

The difference is found in: psychology!

The reasons for the way in which people work together (or not!) make all the difference. People base their actions on their view on reality. Their view is not always correct.

Lets take the an example: A test manager who reports to the end-users "there are 100 defects" triggers the end-users "FEAR"! Often unnecessary. When the same test manager reports a bit more in-depth the end-users would learn there are 100 defects, of which 50 have been solved, 27 are low-risk and deferred to the next release, for 16 defects there's a work-around and the remaining 7 defects can be solved and retested in time. They would be happy about progress and quality. The basic message is the same but the psychological effect is totally different.

Another example: You are testing risk-based (aren't you?) so for a low risk area you may decide that exploratory testing, based on a charter for a timebox of 4 hours is sufficient risk-mitigation. You may however find that a professional tester doesn't want to limit his testing to this. He will argue that with exploratory testing only, he won't uncover all defects thus having residual risks. Behind this is the testers FEAR that something will break in live operation and he will be blamed, because users will state that the system is "not very well tested". But it was low-risk so the consequences of the bug are not dramatic. How do you cope with this FEAR? Involve both the tester and the end-user in the risk analysis and the subsequent test strategy so they will really understand that if a part of the system is low-risk then all residual risks caused by remaining defects are low-risk and thus accepted by the client. By having people understand the reasoning behind choices makes them work together much better.

I am convinced that improving the testing process starts with improving the understanding that people have of their project, the goals and the reasons behind the choices made. Based on practical experience the TPI NEXT book states 'Communication is a means of team building'.
Are you interested to know more about the psychological side of the pursuit of quality? Come and hear my talk at the EuroSTAR conference on tuesday afternoon. I will tell you much more about FEAR (for example that this acronym stands for Fantasy Experienced As Reality) and I will demonstrate the graph of testers happiness!

Next to the conference itself I look forward to also meeting you at the expo, at breakfast, lunch and dinner, not to forget in one of the pubs in Manchester! (over food and drinks it's much easier to discuss psychology and other aspects of the wonderful profession of software testing and quality assurance)

See you in Manchester!!