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.

If you’ve looked at automation solutions and then decided not to proceed, it’s probable that you hit one of these issues:

1. During the trials of your selected products you realised that the learning curve for becoming productive with a tool is far higher than expected. As a result just for the trial you find yourselves investing significant amounts of time trying to get just a basic automated test working.

2. After starting your trial, your team were overtaken by day to day events and never had the time to invest in a comprehensive software testing tool evaluation. As a result you keep promising yourself that you’ll pick up the trial again in one or two months time.

3. When you added up the costs of the software licenses, new hardware required, training and the investment in time required you quickly decided that the investment wasn’t worth it. Or at least the financial figures you came up with were unlikely to be signed off.

4. When you realised that test automation isn’t something that can implemented by one tester in his or her spare time you figured that it’s likely to require significant business process changes. This would mean setting up a dedicated automation team and trying to work out a process for evaluating good tests to automate. It may even have meant working with the development team to get changes made to the code for the automation tool to work. Either way making changes to the existing process seemed quite daunting.

5. When you looked at the recommended best practice for test automation projects you realised that you had something that looked more like a development project than a test project. Source code control, scripting languages and the certainty that your automated code would have defects, suddenly made you aware that this isn’t going to be like any other test project you’ve undertaken.

Whilst there are any number of points to put a test manager off starting an automation project, for many companies the effort, time and money is all outweighed by the benefits. When software testing tools are implemented well the following benefits can far outweigh the issues listed above.

1. Once a test is automated, unless the feature being tested changes, then it can be run consistently day in day out with little overhead.

2. It’s usually far quicker to run an automated test than to run a test manually (exceptions to the rule on this are when you have a poorly written automated test and you spend a significant amount of time maintaining and setting up a test run).

3. Automated tests can be scaled up quickly to provide load and stress testing capabilities

4. Software tests can be run continuously and out of hours. Usually the biggest benefits are gained when tied in to an automated build environment. In this kind of setup the testers don’t even need to evaluate the results. The results from an automated build can be pushed directly back to the development team.

5. the same test can be run on combinations of platform and operating system quickly and easily. Whilst it’s never quite that simple with automation tools, when you do get this right the benefits can be huge if you have a complex test matrix to cover.

There are many other benefits and also many other pitfalls. Nevertheless, as many successful test teams have found, the cost benefit ratio usually falls down a long way on the side of delivering benefits. The benefits can be huge yet despite this many never get past the first hour of trialing a software testing tool. The key, before starting a trial, is to consider these points and set realistic expectations.

1. Effective test automation requires significant changes to existing test practices. For example most successful test automation projects have dedicated test automation engineers who’s sole purpose is to focus on automation. You will need to bring in new skills or train existing staff.

2. As well as writing the automated tests the automation team needs to be responsible for putting new business processes in place. That process includes taking and evaluating requests from others as to which tests to automate. You can’t automate everything so a process that evaluates where your time is best spent is essential.

3. Supporting the development of automated software testing tools is a development project. You will need to consider requirements definition, source code control and defect tracking. The development team follow these best practices when they write code. Your automation team should be following these best practices too.

4. Monitoring the development and execution progress is essential. Without stats to monitor your progress you’ll never know if you are getting the benefits you expected in the first place. Think through and define the management information you need at the outset of the project.

5. Don’t forget to consider training and maintenance. The hidden costs of software testing tools can make or break an automation project. If you’re selecting a new automation tool chances are you’ll need training. Once the automated tests are in place you can guarantee that the code will need to be maintained. This all takes time, effort and money.

In short don’t just think that you can succeed with software testing automation by expecting one tester in your team to spend a bit of his or her spare time learning and implementing. This approach may work for some but experience shows it usually results in failure. Far better to tackle this as a development project in it’s own right. In doing so you approach the implementation of new software testing tools with the right mindset and increase your chances of success.

Now I can’t get too excited about all the arguments that surround “this” agile method or “that” agile method. I figure no one methodology is the right methodology. What’s right is your team picking the best methodology for their specific circumstances and, where necessary, modifying it to extract the biggest benefit. Having said that, there were a number of points in this webinar that really struck home. Points that I think can be applied regardless of the particular methodology you use. So Robin’s methodology may or may not interest you but I think these points may be of interest.

There are limits to the benefits of embedding software testing early in your development life cycle. Lets take the Extreme Programming approach, where developers write testcases, write the code and then decide if the code works based on the test results. The main limitation to this approach is that the developer is viewing a small piece of the code. He or she maybe unaware of the bigger pieces and may not fully understand the interaction of these pieces.

In addition there’s a chance that the developer, when writing the testcases, is envisioning how they are going to write the program. This in turn influences the tests written. It also limits the objectivity of the tests. So testcases written by developers are not going to catch things that they don’t understand or that they’ve overlooked.

The agile movement is a reaction against documentation.
This struck a cord with me. I’m not a huge fan of lots of documentation (especially when it means writing pages and pages for a plan which no one else is likely to read). Yet from a testers perspective I really appreciate a well written design document from which I can base my tests. Some argue that agile is an approach that helps developers (and lets face it testers too) avoid writing is a fair point. We’re all guilty of wanting to develop code or run testcases rather than focus on writing stuff down. This is an interesting way of approaching this…

“Documentation is not about generating paper work but rather writing down ideas so that you and others don’t forget them.”

With that in mind the purpose of writing documents seems to take on a less onerous meaning. It’s certainly an approach to documentation that I can subscribe to. It also fits with my thoughts on software testing documentation.

Aim to catch requirements issues before they get into design.
Yes we all know this one. We all know that most bugs are introduced at the beginning of the life cycle. The practicalities of software testing early in the life cycle, especially right up at the requirements capture stage, is damn difficult though. In the real world, with time, money and delivery pressures, pushing the testing into the requirements phase can be almost impossible.

It is, however, a point worth driving home. For example in the world of Agile methodology the development team has a degree of interaction with user representatives. Yet just because a user says something doesn’t guarantee that it’s a solid business requirement. Firstly the end user might be wrong. Secondly the end user isn’t the only stake holder. Is the requirement the end user is describing right? Possibly not!

Question and test the requirements up front and you prevent mistakes making their way into the design. Prevent them getting into the design and you end up with better code. With better code the tester spends less time bogged down with trivial defects. It’s an easy argument to construct.

Pulling testers off physical software testing tasks, to work on testing requirements, is a tougher argument to defend. It doesn’t always have to be testers that get involved with this though. Yes a tester will bring that critical, left field, approach to the review process. But any review and analysis of the requirements has to be better than none at all. Persuading the project team and business analyst to spend a bit more time up front can deliver a big pay back to the testers (and the project) in the long run.

In summary, a provocative webinar with many concepts and ideas that have practical application. Certainly some interesting ideas for software testing in an Agile environment that are worth experimenting with.

In the 17th century Queen Elizabeth the 1st was one of the wealthiest people in the world. She owned around half the United Kingdom. In her dying moments she was said to have told her doctor that she, “would give all I have for a few more minutes of time.” Now whilst a lack of time isn’t that dramatic for us as practitioners of software testing it does bring the point home. It also raises the question of how much we would we be prepared to sacrifice in order to have more time to work on the quality assurance aspects of a project.

You could argue for spending more money to purchase automation tools. Or to invest more time in recruiting the best testers. Much of the time these aspects are out of our control though. As a software tester on the front line we may not have a great deal of influence on the budget we have to spend on software testing tools or control over recruiting someone else to help us with the huge amount of work we’ve been assigned.

So it’s perhaps worthwhile looking at it from a more practical point over view. For example what can I do as a software tester each day that will make the biggest difference? For me it’s the discipline of concentrating all of my effort on one single task. Most of the important testing you do requires a large block of time to complete. So it’s your ability to carve out these blocks of productive work that are critical.

The key to succeeding with this is to segment blocks of time as you plan your day. Resolve to ignore distractions, to make every minute count, to focus 100% on the task at hand and only work on that selected task. To achieve this you need to set aside a period of say 60 minutes, preferably at your most productive time of the day. For me, the previous day I block out 60 minutes for the moment I get into work the next day. I pick one specific task that I need to focus on. I even go as far as setting out everything I need to complete the task the day before. That way the moment I sit down at my desk I can just get started straight away. No procrastinating, no muddling around looking for something I need to get started, and most importantly no email. That way I know that I’ve got 1 hour of productive software testing completed right at the start of the day.

And if all that fails? Well keep this point in mind. Scientists say that as the galaxy expands, and the moon moves further away from our planet, that the earth is slowing downing. The ultimate result? Longer hours. So if you’re really struggling to find enough time to complete your software testing wait a few million years and you’ll find that you can fit more into the longer hours. ]]> http://www.softwaretesting.net/blog/2011/05/05/never-enough-time-for-software-testing/feed/ 1 http://www.softwaretesting.net/blog/2011/04/22/hidden-software-testing-tool-costs/ http://www.softwaretesting.net/blog/2011/04/22/hidden-software-testing-tool-costs/#comments Fri, 22 Apr 2011 08:36:29 +0000 William Echlin http://www.softwaretesting.net/blog/?p=170 It’s very easy to miss the hidden costs for software testing tools. Yes there’s a price on the license for the product you want to purchase but have you thought carefully about all of the hidden costs?

The most obvious hidden cost is training. Yes the vendor you purchase from will point you in the direction of training courses and clearly state the price of these training courses. Just because you’ve been on a training course though doesn’t mean you know what you are doing. It’s like passing your driving test and then spending years building experience. The training course will teach you how to use the tool but only time and effort will provide you with the experience you need to become really productive.

There’s also the temptation to skip any training. How many of us are guilty of just ignoring what’s on offer and assume we can learn the package in our own time without the need for any training? Many of us do this because we know the cost of training will add significantly to the purchase price. If the purchase price goes up then the chance of the purchase being signed off is less likely. So we forgo the training thinking that we’ll work it out ourselves anyway. More often than not this is false economy. Four or five days of training usually results in a saving of 4 times that in wasted time working things out for ourselves. Productivity goes up significantly after training and the likely-hood of a successful test tool implementation goes up significantly too.

It’s not difficult to quantify the benefits of purchasing training. It is time consuming to add that information to a well constructed software testing tools business case. It’s always worth investing that time.

One of the other important hidden costs is infrastructure. Quite often tool vendors won’t quote the cost of supporting applications in the headline price for the product. For example many software testing tools require a back end database and the tool vendor conveniently forgets to mention the cost of this in the headline price of the product. Granted for many companies they’ll already have site wide licenses for the databases back end but for many companies they won’t. The associated purchase price can be significant.

Integration is the other area that is forgotten about all together. Rarely these days does a software application exist in a vacuum all on it’s own. With many other business applications already implemented it’s more common to want, or even need, some degree of integration with existing systems that the software test team uses. Whilst you might have the in house knowledge and resources relating to your existing systems it’s likely you’ll need to bring in expertise for any new tool your purchasing. Specify your exact requirements for integration at the start to avoid any unpleasant surprises after you’ve completed the implementation of a new software testing tool.

The other game the software test tool vendors tend to play is putting many of the features you need in a higher priced edition of the product. So whilst the headline purchase price might look within your budget the price you really need to pay, for the feature set you need, is significantly higher. Be sure to question the vendor in detail about specifics during a product demo.

Lastly, the other charge that many teams forget about is the cost of peoples time to implement the tool successfully. The cost of software testing tools are usually insignificant compared to the staff costs. When you factor in the cost of having many members of your team implementing, learning and getting started with a new tool the cost can take on a whole new dimension.

Even if you can’t estimate all of these points accurately, a rough estimate will give you a completely different perspective on the purchase price. In short make sure you list and estimate all of these hidden software testing tool costs right from the start.

Many testers thrive off chaos but ultimately the chaos approach doesn’t scale and usually falls apart under tight deadlines and with complex products. Having said that smaller teams can deliver an effective test function with little structure in place. Again though this depends largely on the competence of a small number of testers and tends not to scale as a team grows.
At some point a team usual begins to feel the need for a formal process.

That point usually comes as the amount of software testing needed escalates. There’s nothing like a poor quality product release to prompt a demand for more testing. Also, as the requirement to test surfaces in multiple teams within an organisation the demand for formal process can become apparent too. The other point at which formal process can be useful is when your outsource. The idea of outsourcing is usually to avoid any of the overheads of managing the testing in house. If you have few procedures is in place then it is difficult to convey your expectations to an outsourced team.

Ultimately the purpose of implementing procedures is to save your team effort, money and time. If the cost of implementation outweighs the cost savings then you have to question the need to implement. Although if you see increases in quality then the trade off, of more effort, money and time may be a trade off you’re willing to take.

With the need for a standard process identified the strategy for implementation needs to be considered. This is likely to involve appointing someone to drive the implementation, identify the scope, define an implementation plan and monitor the roll out. All of this is usually best covered with a small software testing pilot project before any organisation wide roll outs are considered. The goal being to test your approach on a small scale, make adjustments where necessary and then roll out further within the organisation.

With a procedures implemented the work doesn’t stop there. Ongoing maintenance is an important part of making sure the benefits are maintained. New procedures can be out of date pretty much as soon as it’s implemented if changes elsewhere within the organisation impact the team. So the implementation must be reviewed at regular intervals to see if areas of the process need to be tweaked or changed. Various review points can be chosen to evaluate the effectiveness. These review points would include the end of project, changes to the development procedures, implementation of new software testing tools, issues identified through monitoring metrics and changes to the organisational structure.

Implementing a standard test process should not be taken as a lightly. Having said that the implementation of an effective software testing process can bring big benefits in terms of quality, time, effort and costs to an organisation.

8MVFPTX38K9W