Well what struck me more than anything throughout this book was this guys relentless drive for quality. Not specifically software quality, hardware testing or any other form of product testing. Just the relentless quest to make sure he created brilliantly high quality products. This obsession for quality rippled right down through Apple. It was clearly endemic. It was enforced with actions like this…

1. Pausing the release of the first iPhone
Nearing completion of the first iPhone Steve Jobs decided he just didn’t love what they’d spent the past year sweating over. So to his teams dismay he started over with the design.

2. Berating the MobileMe team for damaging the Apple name
When MobileMe was criticized for being unreliable in the Wall Street Journal heads rolled and the team was berated for damaging the Apple name. Those that were left keenly aware that they’d let the team down.

3. Acknowledging the issues with the iPhone 4
With Antennagate Jobs (eventually) laid out the truth and stated that “we’re not perfect but we want to make our users happy”. In doing so he maintained, perhaps even increased, his integrity.

Actions like this, day in day out, clearly reinforced to the rest of the company that Apple was (and is still) about quality. It’s about the products not the profit.

In the software testing domain we all talk (and frankly little gets done) about identifying defects early in the product life cycle. The age old argument that if we identify defects in the requirements capture phase then we’ll save billions (slight exaggeration) of dollars in the long term. We’ll with Steve Jobs’ drive for quality this concept was taken to another level.

When your CEO advocates quality in this way it has to rub off on the rest of the organization. It’s a million times better than someone just standing up and saying we must identify defects at the requirements capture phase. This is about instilling a passion for quality in the whole company. It’s a drive for quality from the ultimate source; The CEO.

How many CEO’s of companies today can honestly say they want quality that much? You’re presented with the option to ship a nearly completed product (like the first iPhone) or stop and say .. “this isn’t good enough”. Would you ship and start taking revenue? Or back off and start again? Far too many companies are consumed by the need to ship products and start generating revenue. Revenue first, quality second.

I expect that many CEO’s would argue that quality is top of their list. That quality is what makes them a great company. That the CEO has a list of examples where he’s castigated teams for poor quality releases may be used to prove a point. Where he may have sacked someone as a consequence of a product release that didn’t go well. It’s usually a front though. Very few CEO’s have the real credibility needed to backup their commitment to quality. Far too many are consumed by the desire to chase profit and revenue.

For Apple though it was more about quality first and then the profit will follow. Jobs was quoted as saying “the product, not the profits, were the motivation”. And therein lies the a tricky dichotomy. You need profit in order to invest in quality products. Yet with quality products comes higher profits (or at least it did for Apple). It’s the same dichotomy we face in software testing.

Do we invest heavily in testing in order to drive up product quality? Can we really say that this investment makes a significant difference to the bottom line? Who knows? One thing I do know though. Quantifying our contribution to the bottom line is near on impossible. Yet with Apple we have a clear example that by putting product quality first you can build the world’s largest publicly traded company. Surely that holds some weight when it comes to arguing for more, not less, resources being allocated to software testing?

http://www.gartner.com/id=1533716

For those of you that aren’t familiar with the Magic Quadrant methodology this is an approach for categorising positions of product vendors. The aim being to allow you to understand how technology providers deliver products that might best fit your needs. Gartner categorise the providers into Challengers, Leaders, Niche Players and Visionaries. Where challengers dominate the sector but may not be well placed for the market of tomorrow. Leaders are delivering against their vision for the market and look well placed for the market of tomorrow. Visionaries can see where the market is going or may even be dictating where it is going but are yet to capitalize on this vision. And niche players execute well in their segment but may not be placed well for competing in tomorrow’s market.

The report argues that companies are looking for solutions that enable automation, deliver traceability, improve workflow and deliver more comprehensive reporting. Another key point that they put across is that companies are looking for suppliers that have well established partner programs that can deliver as systems integrators and put consultants on the ground. It’s not unexpected to read that many of the market leaders (HP, IBM, etc) don’t have the most innovative products in the software testing arena but they typically catch up pretty quickly when they see the market move (usually by partnering or acquisitions). The visionaries in the sector are usually focused on a particular niche where their tools are purchased in conjunction with the market leaders.

The most interesting point they put across is that Gartner expect two or three companies to move into the leaders quadrant. This is clearly not an easy space to start competing in. The reasoning behind this that a few companies with composite and cloud based offerings will be well placed to take advantage of the changing technology landscape.

As expected HP is singled out for being the dominant player in the market. Whilst pressure is building on them to provide more competitively priced products they still deliver in most large enterprises. Whilst HP’s support, in the past, has been singled out for criticism this report notes that HP have made solid improvements in this area. Again HP deliver a tool set that leaves all the competitors mirroring their approach and aiming to provide integration to their tool set. No wonder then that most consultancies and system integrators purport to support the HP tool set. Yet there is some argument that the product line has been perceived as a little stagnant.

IBM is also up there as a dominant player. Again delivering a toolset that supports the full lifecycle. And again providing a strong global presence. Yet their Jazz platform, which delivers tools across the full development life cycle, comes in for a small amount of criticism. It’s argued that some of the products deliver overlapping functionality (although it’s known that this is being addressed). Ultimately this means it’s not always clear which products need to be deployed. The main strength for IBM? Delivering a quality based approach across all the project roles covering the whole project life cycle (e.g. from unit testing to build processes).

The other vendor I wanted to pull out from this report is SmartBear. They’ve been picked out as a Niche Player based on their focus to deliver cost-effective tools that fit teams working with agile development processes. With a product range that covers application lifecycle management (including test management), test automation, code review, load testing and continuous integration. The main point of caution raised here is that the product suite is best suited for small to mid sized teams but this is clearly compensated by the relative advantages of the price points they take in comparison to the likes of HP and IBM.

Whilst this report covers many other vendors and suppliers of software testing tools it confirms the market dominant position of of HP and IBM. Yet it notes the increased competitiveness in the market and the threat some of these niche players pose to the dominant players. Many of these new players are are doing well because they provide better support and better targeted solutions. It’ll be interesting to see in the next release of this report. Which, if any, of these new software testing tool providers will have made it into the Leaders quadrant?

http://www.thetestingplanet.com/2012/03/march-2012-issue-7/

In summary Seth argues that the traditional product QA approach is changing. The concept of execute, record result then mark as pass/fail is flawed in the new world. Quite a brave argument to put forward when this concept is such a huge cornerstone of software testing. He puts forward a good case though. With the advent of large scale services (Google, Amazon, Facebook) Seth suggests that for the web this traditional concept is no longer adequate.

In order to assess the quality of web services we need to be analysing live production data. Our test input is the live users accessing the system. Our recorded results are the telemetry info being generated in the data centers that run our applications. Our pass/fail analysis will then be based on patterns or detail found in this data. This analysis then gives us insight into how the users are using the systems and the behaviour of the system itself.

Seth argues that using this approach finds defects that you’d never find in a test lab. It’s hard to disagree with this. Only real life analysis is likely to show up real life user experiences (e.g. how long it takes for a page to load across different operating systems and browsers). Effectively we’re software testing in production.

Seth calls this approach TestOps. Implying that we’re testing in the operational environment. As part of this live environment approach we have three key inputs we can work with. We can analyse our telemetry info for KPI’s (e.g. availability or performance). We can also deploy new features or releases into production where a small set of end users get access in the live environment. Essentially we’re running in a beta phase where the end user may not necessarily know they are part of a beta test. The third input can be testers that make back-end changes in an attempt to force test scenarios and then assess results.

This is a significant change in the software testing landscape for you and I. Our focus is shifting from working at the front end of the development process. In this setup we’re working with a live environment after the product has been released. Let’s be realistic though. We’re not going to see the traditional skills and practices change. This is more like an additional facet to our roles as software testers.

My biggest concern? This is a beta phase where the beta testers don’t know they’re beta testers. All this telemetry info may help us identify some issues we wouldn’t have caught in the traditional software testing phases. Who’s to say that what we miss with the telemetry info will be picked up by the end user? And even if they do pick it up will they tell us? I doubt it.

I also expect, with the usual pressures to ship, that we’ll see more of the QA effort pushed into this OpsTest phase. The problem with this is that we won’t catch many of the issues the end user sees (and that our telemetry data misses). We’ll become more and more reliant on the end user and telemetry data. This is not the same as a tester evaluating the user experience. For that we need dedicated software testers with the resources and time to complete their work in the traditional phases. I agree that this is an interesting new area of software testing, but I doubt it’ll change the landscape drastically.

Testers often quote lack of time and poor resources as the reason for not changing. This is usually a cover. The biggest problem is the overall desire to change. I’ve worked in teams where line managers were resistant to change. It’s sole destroying sitting there knowing that things could work much better. On the other side of the coin when you’re part of a team that loves to improve it’s one of the most empowering feelings you’ll ever experience. Successful groups make time. Successful groups find resources. Successful software testing teams build an attitude and momentum that relishes development and improvements.

Think of it like the seesaw you played on as a child. When you and a group of friends all jump on the seesaw at the same time. You end up with 5 people on one end and 3 on the other. With enough weight on one end there’s no way the lighter end is going anywhere. Improvement is about getting enough people and weight on to the end of the seesaw that embraces change. You need the balance to swing in favour of change.

Typically there will be a few people in a software testing team that want to embrace change. They want to improve processes and implement new tools. They want to see the team succeed and they enjoy the challenge of learning new things. The problem comes when the majority of the weight is on the side of the seesaw that doesn’t want change.

If you’re one of those people that loves working on improving and developing then take stock. If you’re feeling frustrated at the lack of progress then get off the seesaw and look at it objectively. Is your manager on the end that is resisting change? Are the majority of the team on the end that want everything to stay as it is? If they are then leave. Walk out of the playground. Find another job. Find a job where people will embrace your enthusiasm for change and your skills for implementing tools. Find a software testing environment to work in where you can make a difference.

There will be resistance to change in any software testing team. The key is to objectively evaluate your chances of success. Can you achieve what you want to achieve where you are? If you’ve got enough people on your side of the seesaw then great. Keep persuading others to join you on your end. If the weight distribution looks unfairly stacked against you then find another software testing group to work with. Find a group to work with that makes you feel empowered. Work where you can make a difference. There are other teams out there that will really appreciate your enthusiasm and talent. You just need to find them.

As companies extend software applications by opening up and sharing data via APIs this puts additional demands on software testing teams. This type of testing is technical and requires an understanding of protocols and data formats that go well beyond the usual GUI stuff you run. So typically API testing ends up straddling both development and QA teams. As a result many QA teams have to work closely with a development team to implement their software testing objectives in this realm.

On a technical front many use tools like SoapUI to cover the tests. Yet even with tools like this you still need to bring this under control of your test management process and look to automate. The following video looks at an approach for linking SoapUI to TestComplete (TC8) and QAComplete.

Here we have SoapUI executing the API tests. TC8 covers the automated execution of SoapUI. TC8’s integration with QAComplete is then leveraged to provide a central reporting location for all your automated tests. With this setup you can schedule the execution of your automated SoapUI tests directly from QAComplete (great for managing regression).

If you are looking to try this software testing approach then the following steps will help. Please note that the following expects a reasonable level of knowledge of SoapUI, TC8 and QAComplete. If you’re not familiiar with these products then you can sign up for trials using these links.

     Product Trials

     Software Test Management with QAComplete
     Test Automation with TestComplete
     API Software Testing with SoapUI

QAComplete to TestComplete Integration

You will need to install the software bridge application on the TC8 machine. Download this from here.

     http://www.softwareplanner.com/downloads/AutomatedTestingBridgeSetup.msi

The user guide to help you setup can be found here.

     http://www.softwareplanner.com/UsersGuide_TC.pdf

TestComplete to SoapUI

1. Create a testedApp in TC8 which executes a command line like this.

“C:\Program Files (x86)\SmartBear\soapUI-Pro-4.0.1\bin\testrunner.bat” -sLoging_and_Get_Config -c”Get Config” -fC:\ -R”TestCase Report” -FXML C:\Users\Bill\Documents\QAC-soapui-project.xml

This is the SoapUI command line that will execute your API tests. This command line should run successfully in a command prompt before you try to include it as a TC8 tested App.

2. Create a keyword test in TC8 that does two things on the software testing front.

      a. runs the tested app (e.g. the command line in 1 above).

      b. waits for the SoapUI run to complete.

3. Create a script in TC8 that parses the log file from SoapUI. An example script can be found at the bottom of this web page (e.g. its the 3rd example).

     http://blog.smartbear.com/post/06-10-05/working-with-xml-files-in-testcomplete/

You may need to install this on your windows box to make this work.

     http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=19662

You will need to modify this script. You’ll need to modify it so that it picks out the parts of the SoapUI log file that are important to your software testing reporting requirements. The script we’ve given you will work in principal but you’ll need to modify it to present the required entries in the TestComplete log as you see fit.

4. Create a project in TC8 that contains (2) and (3) from above.

5. When you execute the project in TC8, this will run SoapUI, collate the results (and copy the log files) back to QAComplete.

Taking your software testing a step further you can then use QAComplete to schedule automated runs of SoapUI tests. To do this setup a test schedule that calls the TestComplete project that you created above. In this way you can drive everything from QAComplete.

1. QAComplete kicks off the TC8 test.
2. TC8 runs the SoapUI tests.
3. TC8 parses the SoapUI log/results file.
4. TC8 creates test results and logs based on SoapUI log file.
5. TC8 writes test results and log files back to QAComplete.

Rather than link these tools in this way you could link SoapUI directly with QAComplete to cover scheduling and result tracking. To do this you would need to utilise the QAComplete API and write the corresponding bridge application to link SoapUI to QAComplete. Probably a more efficient solution but it would have one major down side. That is you can’t combine your API automated tests with GUI and database automated scripts.

With the setup we’ve described, once you are driving SoapUI from TestComplete you can write automated tests that encompass multiple areas of your application. By this we mean that you can test the API (via SoapUI) and confirm the GUI operation of your application with TestComplete’s GUI automation. Then add to this connectivity to your back end database with a TestComplete database connection. Then you’ve got the ability to automate the cross checking over all the major aspects of your application. Then link TestComplete back up to QAComplete where you store all of your manual and automated test results. With this you have a well integrated test management and automated software testing framework.

Personally as a tester I found UAT more interesting, more demanding and more exciting than all the other stages. Everything comes together during this phase. Managing this dictates that you become a peace maker and negotiator between the two sides. A UAT test fails and the customer tells you that the feature doesn’t do what they need it to. You talk to the development team and they say it has to work that way when you consider other aspects of the application. Your is to understand all of the technical arguments supporting both sides. More than this your role is to understand the people on both sides so that you can bring them together with the right solution or even possibly a compromise on both sides.

If you’re involved with UAT then it’s not only these technical and contractual issues that present a challenge. Surrounding this are a unique set of software testing process issues that always crop up. Usually you’re out of your normal testing environment. You are forced to work outside of your usual process and sometimes even without your usual tool set. For example 3 challenges that consistently present themselves during this phase are…

1. how to track defects effectively
2. how to record requirement changes
3. how and where do the test cases get written

Yes we know these are areas that most software testing teams have solved a million times over. The trouble is when you’re on a customers site as part of a User Acceptance Testing program. You don’t usually have access to your defect tracking tool of choice. The client forces you to go back to the dark ages and start tracking defects with Excel. A stream of emails are used to explain some subtle changes to a requirement and the original requirements document doesn’t get updated. The client doesn’t have access to your test management tool so you have to write the test cases in word and then record results in Excel again.

You may have the perfect process when working in your own environment. However, the moment you get pulled into UAT you’re forced to compromise and start reinventing your process. You need a process that can work for the customer in the customers environment. Following is an example of how we can address some of these software testing issues with a test management tool called ALMComplete. A lot of other tools out there have similar features so we’re trying to focus on the principals here rather than the tool itself.

In particular this software testing video looks at:

1. Logging Defects – keeping everything in sync and visible.
2. Tracking Changes to Requirements – maintaining traceability and the approval process.
3. Writing the Test Cases – tracing approvals from your client.

UAT presents a unique set of challenges to the QA team. Don’t approach it thinking your usual processes and tools will deliver everything you need. Your customers requirements (both practical and process) will mean you have to bend towards meeting their needs. Typically your clients processes and practices will be completely different and probably far less mature than yours. If you can help guide them with some gentle persuasion you’ll reap many benefits from keeping close to your usual process and utilising existing tools you have. UAT is not just an extension of your usual software testing process. Quite often it demands a different approach altogether. However, if you have a clear picture of how you want to run your UAT from the start you can make sure this part of your software testing runs smoothly with your tools and your process.

What’s best in Software Testing?  A tester that learns the business or a business person that learns testing? This was an interesting question put to a group in a recent software testing forum.

On the one hand a software tester brings definite skills and experience to a project. Even if he/she understands little about the business processes he/she understands about good QA practice. In addition most QA engineers worth their salt have a feel for the discipline and have a 6th sense when it comes to finding bugs. Couple this with someone who can look at a project objectivity with a fresh pair of eyes and it’s not difficult to see why we tend plumb for a QA engineer first.

On the other hand someone from the business side of things coming into undertake software testing brings a wealth of industry knowledge. Industry knowledge that has usually been built up over years. That experience counts for a lot. Quite often such a person, working as part of a test team, can look well beyond a feature not working. They can pin point why a feature that might work from a functional perspective, won’t work in the business context.

I expect, from experience, we’ve all seen analysts look at a software testing project and criticise what’s been done. “What you have may well work but it won’t do what the end user needs it to do”. Equally as QA engineers we’ve all found bugs in systems where a certain piece of functionality appears to work from the end users perspective.

From a simplistic point of view we can break it down with these age old questions …

1. Are we building the right product?

2. Are we building the product right?

The analyst may be better at answering the first question. The QA engineer, better at answering the second. Ultimately though, when we’re software testing, we need to answer both. So does this suggest that it’s best to have a combination of skills applied?

Possibly one good tester that understands the business process very well is worth more than two good testers that don’t understand the processes very well. Does this mean thought that as software testing professionals we should not only specialise in testing but also in a particular industry too? Certainly this helps and without doubt already happens a lot. You can see this when browsing any job spec for a software tester. Most job spec’s don’t just ask for a generic tester. They ask for a tester with specific skills in a related industry discipline.

Coming back to the question, is it more productive to get someone from the business side of things and teach them to test on a project? Or get a tester and teach them the business aspects on a project? Maybe to answer this we can look at the extremes. Would you want a test team full of analysts that know everything about the industry? Yet they know very little about good QA practice and possibly haven’t developed that testing 6th sense? Or would you want a test team full of QA engineers that know nothing at all about the business? Would a mix of the two be the best way to go?

It could easily be argued that the ideal team would be a mix of talents and skills. What happens if you’re choosing between a single tester or a business analsyst though? In this scenario maybe it’s more about how quickly one person can learn what he/she doesn’t already know. How quickly can the analyst learn to test effectively. How quickly can the tester learn the business process aspects? With software testing, as in many other walks of life, perhaps the best option to go for is the person who’s most enthusiastic about learning.

Have you got any thoughts on how the role of the software tester might change over the next decade? At a software testing forum in the UK last week there was an interesting discussion on this. Discussion is probably the polite way of putting it. It was verging  more on argument most of the time. See if you agree with some of the key points that were put forward.

Onshore/Offshore

Someone suggested that half the current onshore testing roles will move offshore. This is an old argument now and for well over a decade we’ve been able to work remotely. With tools like GoToMeeting and Webex that ability is becoming ever easier. Whilst the arguments for and against offshoring continue I personally think this argument is a distraction.

Should we stop using these terms onshore and offshore altogether? In many disciplines now (and I’m not just talking software testing here) work can be carried out anywhere on the planet. It’s been a global market for decades  and it’s going to remain a global market. Accept that to compete you need to be good at what you do and price yourself competitively. Oh, and you need to be able to communicate effectively.

Communicate Effectively

When we talk about communicating effectively we’re not talking about being able to pick up phone, send an email or conduct a web meeting. We’re talking about being understood and understanding the people you are working with. If you’re providing a service to a client you need to be able to understand the client. And the client needs to be able to understand you.

If your customer is Chinese then you may need to communicate effectively in Chinese. Even if you speak the same language, if you’re not on the same wavelength, you’ve no hope of delivering what your client expects. It’s no longer about the ability to communicate. It’s about the ability understand. No matter if the person you need to understand sits next to you or is located half way round the globe. If you can’t understand them go and work with or for someone else that does understand you.

This is one of the key reasons I believe the terms onshore and offshore are obsolete in the software testing world. They are too simplistic. We say offshoring worked or didn’t work. It’s just too simplistic to credit the success or the failure with this concept of offshoring. It’s a multitude of factors that determine success. Those factor include communicating effectively and finding the best people for the job.

Finding the Best People

Picking the best people you can find is as important today as it was yesterday. Cost is never going to be the only factor. For that reason your skills and reputation will still have the biggest influence on your ability to work in software testing. For the individual this may mean you need to market yourself globally. Today with remote working job sites like oDesk and vWorker it’s easy to market yourself globally. Lots of other testers are so why aren’t you?

It’s easy to use these remote working web sites. So pulling together a global software testing team is quick and simple. The only difference now is that managers have a much bigger pool of people to select the best talent from. A global pool of brilliant testers.

Over the next few years we’ll see more and more companies bringing teams together with remote working job sites. Rather than outsource to one company we’ll bring in the exact talent we need. We’ll be picking remote working individuals, rather than outsourcing large pieces of work to a separate team.

Summary

No doubt over the next decade we’ll continue to use the terms off shoring and on shoring. Personally I’d like to see us stop using these terms. The terms mislead and leave you in a mind set that thinks you should look to one over, and above, the other. Stop thinking in this mind set and we can start thinking in terms of finding the best people to build the best team.

Aim to build the best software testing team with the best people you can find, and forget about where they work on the planet.

Visit a modern car plant and you’ll be struck by the attention that is given to setting out everything for the worker. Everything is set out so that it helps them become as productive as possible. Every tool that it needed is placed so that it is immediately to hand. Tools are even placed so that they can be picked up with little movement from the worker. This attention to the workers environment is built on the principal that many small improvements can add up to massive gains.

So the question is, when did you last look at your software testing environment? When did you last try to identify small changes that could add up to a big improvement for your team? Well to start you off here are eight examples of how software testing tools can be used to improve the productivity of a QA team.

1. Review your process. Do you have any unnecessary forms to complete, data capture requirements that you really don’t need, etc. I’ve worked with some teams where the data capture requirements (demanded by the management) meant the team we’re filling out around 10 different spreadsheets every day. Are you spending more time capturing data than running tests?

2. Where a tester might be reviewing a requirement within the test management tool, make sure the tool supports emailing direct from the tool. Save the QA engineer having to move between applications to email developers for clarification. This has the added benefit of leaving the email chain against the requirement for other testers to see too.

3. Configure escalation rules within your tools to identify common scenarios that need to be acted upon. For example automate the sending of notification emails for high priority testcases that haven’t been run within a certain time period. This save team leads having to manually identify these cases.

4. Implement software testing tools that capture all the information in one place. Perhaps you’re capturing results, and you need to capture the time taken for execution too. Can you implement a test management tool that captures all of this information in one place?

5. Encourage people from outside the QA team to proactively provide the information QA engineers need. For example, do the developers put design specs in a common location, are customer issues relayed back to the team effectively, etc. Small improvements here can save hours of wasted time looking for information.

6. Set up individual reports and dashboards to meet the needs of each QA engineer. The goal here being to help the tester save time looking for performance statistics.

7. Provide mechanisms for people to get answers to questions quickly. Make it easy to assign tasks to other department and ask questions through chat tools and forums.

8. Automate the test environment set up process. Not only does this avoid the possibility of testing with the wrong environment but it can save a significant amount of time when implemented across the whole team.

I’ve only listed a few examples that come to mind here. The point though is to make you think about how you can improve your process with small enhancements. It’s so easy to continue sleep walking with a process that is nowhere as efficient as it could be. The key is to wake up and encourage your team to start looking for these improvements on a daily basis. Look at how you use your software testing tools and see how they can be configured to help, not hinder, the tester.

If you’ve got others ideas that you think can help improve the software testing process why not post a comment below and share them?

According to my wife this was the wrong answer. Apparently the right answer should have been my wedding day. Fair point. Trouble was it was too late to back track. I’d blurted my answer out before thinking. Wife not very happy.

(Don’t get me wrong. My wedding day is up there in the top two best days of my life. A day with my dad as an eleven year old, with no cares or worries in the world, just pips the wedding day to the post.)

Anyway, I should have thought harder before opening my mouth. If I had I would have considered the wedding day answer. And, in light of who was asking the question I would have adjusted my answer accordingly.

Which got me thinking about how we mentally adjust our answers in our work life. We all do it. At some point we tell people what they want to hear rather than what they need to hear. This is never more true than in software testing.

As testers we’re usually the bearers of bad news.

“Products not going to ship on time”.
“You’ve done a lousy job implementing that feature”.
“No way are we going test this properly with this measly amount of test resource”.

All typical statements we think about and usually want to say.

We learn pretty quickly that being this blunt in the software testing world doesn’t earn us any friends. In fact it usually alienates people. The blunter we are the less people tend to listen to us. And if there is one thing, as software testing professionals, that we really need it’s people to listen to us. If developers and project managers aren’t listening to the software testing team then most likely the projects heading for a fall.

As testers this ability to get our message across without offending and without alienating people is essential. It’s a skill. It’s a skill just like being good at finding bugs is a skill. Our success as software testers depends on us mastering this skill. If you constantly come across as the bearer of bad news and negativity then people start to avoid you. That doesn’t help.

I’ve worked with several testers in my time who where phenomenal at finding bugs. Yet their ability to get their message across to their development counterparts was sorely lacking. As a result they alienated the developers they were working with. Once you’ve lost the co-operation of your counterparts you’ve lost one of the best resources you’ve got to help you pin point bugs. Part of our jobs is to work constructively and effectively with developers to find and resolve defects together. This is why it’s so important to master the skill of getting our message across with tact and diplomacy.

Now I know there are exceptions. Sometimes tact and diplomacy need to be thrown out of the window. You need to get a critical point across and you decide to put it bluntly. Putting it bluntly, when people are used to you being tactful and diplomatic, makes them sit up and take notice. This is best done with thought and consideration. Not unthoughtfully and inconsiderately.

This is a skill I like to think I learnt early on in my software testing career. Why it’s taken me 10 years of married life to learn the same lesson I’m not sure.