Steria RightTest awarded TMMi Level 3 certification
November 23 2012
Steria, a leading provider of IT-enabled business services, has today been awarded TMMi level 3 certification for its “Steria: RightTesting”methodology for software testing. Steria is the largest IT services company internationally to achieve this level of certification, the first in France and the fifth overall worldwide, demonstrating its commitment to excellence in software testing, technology transformation and IT cost reduction for clients.
Software testing is growing in importance as organisations face increasing compliance and regulatory risks. The ability to assure software quality to prevent potentially disastrous technology outages and errors is now a board level issue for many organisations.
Steria has been recognised for its robust and repeatable approach to testing, which is aimed at preventing problems before they happen, so saving organisations a huge amount of time and resources. “Steria: RightTesting”services bring significant benefits to clients including improved efficiencies and reduced costs.
The certification was awarded on behalf of TMMi by UK-based IT solutions and services company and accredited supplier Experimentus, following an in-depth assessment of a number of Steria’s projects. The TMMi certification was awarded for the “Steria: RightTesting” methodology that underpins its application testing portfolio, which is comprised of three service phases – “RightTest Consulting”, “RightTest Transformation” and “RightTest Managed Services”.
This well-respected, international certification is a testament to Steria’s continued commitment to driving efficiency for clients and assuring software quality. The certification is the result of a rigorous assessment, carried out at a number of client premises and at Steria’s Rennes-based Shared Services Centre. Interviews were conducted with project teams’ members on how Steria helped to test and improve various applications of clients’ core business, which in the case of a leading French telco included customer relationship management, invoicing, order processing and business fleet management.
Klaus Olsen, chair of TMMi said, “The testing industry has evolved tremendously over the past 10 years. Organisations are taking a much more proactive, preventative approach to software testing because they have learned the hard way the impact errors can have on the rest of the business. It is fantastic to see more organisations embracing the benefits of software quality assurance using the TMMi model.”
François Enaud, Steria Group CEO, says, “Organisations are waking up the fact that software defects can have massive impacts on not only operations, but brand reputation as well. Our “Steria: RightTesting” services are growing in importance as a result. We take testing very seriously and are of course delighted to have been recognised for our efforts in this area. We intend to build on our success by continuing to evolve our approach to end-to-end testing to ensure our clients receive the absolute best in their IT systems.”
Weighing up the options for software testing
August 13 2012 | computerweekly.com | Karl Flinders
Experimentus consulting director Geoff Thompson comments on the outsourcing of testing being a positive thing that, with the right focus and experience can create real value for the customer and supplier. He goes on to warn against common mistakes which result in it not always being the fastest or cheapest way to test.
Read the full article here:
http://www.computerweekly.com/feature/Weighing-up-the-options-for-software-testing
Aricent Group is First Company in the UK and Second in the World to Reach Level 4 TMMi Certification
PR Newswire
May 23, 2012 | EAST BRUNSWICK, N.J. and DUBLIN
The Aricent Group, a global innovation and technology services company, announced today at Management World Dublin 2012 that its Managed Testing Services (MTS) offering is the first to achieve a Test Maturity Model Integration (TMMi) Level 4 Certification in the UK. Based on the assessment conducted by TMMi-accredited software quality management firm, Experimentus, the certification process was completed in a record time of six months, underscoring the strength and experience of the Aricent Group in conjunction with Total Testing @ UK Lab.
Read the full article here: http://www.bizjournals.com/prnewswire/press_releases/2012/05/23/SF12315
Prevention rather than cure is key to winning in today’s highly competitive market
Business Management, 7th January 2010
We may well be in a recession, but the markets are still hugely competitive. Efficiency and agility are everything in Financial Services. How quickly can this new and innovative business capability or that new service be launched, scaled up, or brought to full profitability? This speed-to-market remains a key board demand, even more so in the teeth of the recession – when the efficient allocation of costly resources is permanently under the microscope.
Begin System Test Design During the System Design Stage
Requirements Network, 4th May 2009
by Adrian Howes
Beginning the testing process early saves money, time and heartbreak over the lifetime of a project, no matter at what stage.
Read the article in full at www.requirementsnetwork.com or download it from our site here: Begin System Test Design During the System Design Stage (pdf, 199kb)
Ensuring Change Control Procedures are in Place
Requirements Network, 2nd February 2009
by Tim Moore, Senior Consultant
Change is inevitable and constant. After all, it’s what drives us as human beings, evolving and adapting is what we do best as a species. When confronted with change, the human brain can calculate masses of data instantly in order to assess impact, firing new instructions to the parts of our mind and body that need to react or be aware.
It’s surprising then, that so many organisations face problems when changes are made to software under development. With so many human brains and all that raw processing power, one would think that change would come easily, except we all know it doesn’t. We constantly struggle to control and fight against change, even when deep down we know it’s probably for the best. Why?
Read the article in full at www.requirementsnetwork.com or download it from our site here: Ensuring Change Control Procedures are in place (pdf, 146kb)
Experimentus Team Accredited TMMi Assessors – First in the World
Bobsguide, 2nd December 2008
The software quality management consultancy, Experimentus, announces today that four of its senior consultants have been accredited by the TMMi® Foundation to use the Experimentus TMMi assessment method.
Read the full article at Bobsguide.com
Experimentus Team Accredited TMMi Assessors -First in the World
IT Backbones, 5th December 2008
- Four Experimentus Consultants Accredited To Use The Experimentus TMMi Method
- First Software Testing Consultants In The World To Become Accredited
Read the full article at IT Backbones Software News
Experimentus Director Wins 2008 European Testing Excellence
IT Backbones, 19th November 2008
- Geoff Thompson wins 2008 EuroSTAR Award
- Recognition of his leadership and contribution in software testing
Geoff Thompson, Director at Experimentus (www.experimentus.com), the UK’s leading software quality management consultancy has won this year’s European Testing Excellence Award.
Mr Thompson received his award at the European EuroSTAR event held in Holland. The theme of this year’s conference was “The Future of Software Testing” – a topic that Mr Thompson has addressed recently within various industry speeches and articles.
Click here to read more
Focus on well documented Functional Requirements
QA Guild , 27th October 2008
With the credit crunch affecting IT budgets, Experimentus, a leading UK software quality management solutions consultancy, recently highlighted ten ways to reduce software development lifecycle costs within IT departments. Today we look in more depth at the first of these tips, “Focus on well documented Functional Requirements”.
Every software product, no matter what its type or application, has Requirements. A Requirement is literally “that which is required; a thing demanded or obligatory. Every software product created has a purpose – that which it is constructed to achieve – and thus will contain at least one Requirement. After all, if there is no purpose to a product, then it is not constructed – for to do so expends time, money and energy for no return. Therefore, every software product has an aim. From this, it could easily be assumed that success of the product depends entirely upon the product achieving its preconceived aim. However, the real world is a lot more complex. Indeed, when it comes to measuring the success of a software product, there are various ways of doing so – some of which do not directly relate to satisfaction of the initial aim (or Requirement) of the software. This could be for reasons such as the initial aim changing during the course of the product being created – or even cases where the initial aim has not been met, but enough work which is considered to be of value has been achieved that the product can still be released (this can often be the case in incremental, evolutionary-style software projects).
Despite these reasons, most software projects will be viewed as successful only if they achieve what they originally set out to do – if they achieve their Requirement(s). It should follow that, in order to construct a successful software product, the development team has merely to adhere to the defined Requirements. After all, if the software follows the Requirements with a high degree of accuracy, surely success must result. Once again, the real world is significantly more complex than this. (Note: For reasons of simplicity and brevity, this paper specifically excludes “Agile” development methods, where the Requirements management process is significantly different to that described here.)
One example would be where problems occur in misunderstanding the Requirements. Depending upon the roles used within the software project, the person writing down the Requirements may or may not be the eventual user of the product. The development team might develop the product directly from the written Requirements, or – more commonly – an intermediate step of translating the Requirements into a technical specification may be taken. The technical specification step itself might be split into two parts – the “Functional Specification” (and, sometimes, the “Non-Functional Specification” to go with it), and the “Technical Specification”. This division (between the Functional Specification and the Technical Specification) can occur when it is viewed that there is a significant translation to be made between the “Real English” of the original Requirements, and the “Technical English” of the Technical Specification (which is unambiguous and which developers can work with more easily) – and so the extra translation step of the Functional Specification, between the Requirements and the Technical Specification, is inserted. This process can, of course, lead to a game of ‘Chinese Whispers’, especially if different members of the software project are writing each of these documents. The author of the Functional Specification may or may not fully understand the Requirements that he is using as a guide for his document. This should not be a problem if the author knowingly does not understand the Requirements – as in this situation, clarification can be asked for and hopefully received from the relevant people. However, if the author believes that they understand the Requirements but in fact have misunderstood – even in a subtle way – then errors can creep into this documentation trail. Obviously, these errors can then be reproduced (and potentially magnified) at the next documentation step (the Technical Specification), and, if not caught, work their way into the product itself. In an ideal world, the document review cycle should eliminate such errata from being propagated. However, in the real world, it can be the case that the relevant people do not have the time and/or ability to successfully review all documentation sent in their direction. (In these days of “email overload”, receiving several documents in one’s inbox to review whilst attempting to deal with other work will frequently lead to the reviews being passed over for other, higher-priority work.)
Therefore it is certainly true that errors arising on the path from Requirements to Product can survive, grow, and indeed multiply. This can lead to the development team producing software which does not do what the user (or whoever constructed the original Requirements) actually wanted it to do. Naturally, this can often lead to recriminations and a breakdown of the relationship between teams in the project in question! The several documentation steps detailed above mean that even if the authors of the Requirements write down exactly what they want, and the software developers create exactly what the Technical Specification tells them to, then there can still be a mismatch. This illustrates the importance of a successfully-managed review cycle – where reviewers perform their reviews promptly, and check not only pedantic spelling and grammar mistakes (as some do) but also check that the document logically follows that which came beforehand – for example, that the Functional Specification actually complies with the requirements (some don’t), and that nothing ‘extra’ has crept into the Functional Specification which was not even mentioned in the Requirements (which can be a favourite way of Specification authors attempting to get the changes that they want made to the software, whether or not there’s a Requirement to make those changes). Even assuming that the “translators” (from Requirements to Technical Specification, and any intermediate steps if they exist) perform an entirely accurate job (or that the review cycle removes all errors), and also assuming that the developers create the product entirely in line with the Technical Specification (or that the software testing cycle removes all errors), the completed software can still not perform as the users originally envisioned it would. In this case, this can be due to a lack of training and/or ability to write high quality Requirements at the start of a software project.
So, what can happen if the completed software is found to be unsatisfactory to the level of not being fit for purpose? Either the project will be declared a failure as the project board cuts their losses (cue several recent Government IT projects), or some level of development rework will have to take place, leading to potentially major delays and cost overruns (cue several recent Government IT projects). Whichever of these scenarios occurs, it can lead to a breakdown of the relationship between the eventual software users and the development team.
It seems that there is a plethora of ways in which the software development process can fail linked to Requirements. What is required for this process to be a success?
Firstly, Requirements must be clearly defined. This can be achieved having the definition performed by people who are linked to the people who will be using the software when it is completed. Requirements definition processes such as UML could be used. Furthermore, the people defining the Requirements must have had relevant training (for example, IREB Requirement Engineering certifications) – so that all Requirements produced are clear, unambiguous, and represent a true picture of what the completed software needs to achieve. These finalised Requirements must be reviewed and agreed by all relevant stakeholders. Secondly, Requirements must be accurately translated into the Technical Specifications that the development team utilise to actually create the software. This can be achieved through use of skilled Requirements Analysts and Software Designers, as well as a robust and well-used review process. The review process must involve all relevant stakeholders, including representatives from the development team and the test team. Additionally, all specification documents must provide traceability to the original Requirements. Thirdly, the development team must create the software according to the Technical Specification provided. This can be achieved through use of experienced developers and, sometimes, strong management! Additionally, the code should be annotated (where possible) with the Requirement references themselves (which should be available within the Technical Specification). This helps to provide complete traceability. Fourthly, the test and/or quality assurance team must check the produced software against the agreed Technical Specifications, and, if possible, should also check the produced software against the agreed original Requirements. Any issues raised should be linked to the relevant part of the Technical Specification and the relevant Requirement.
Following these steps outlined above will logically lead to a software product which:
- Was discussed and agreed between all relevant parties at the start of the project;
- Fulfils all of the Requirements agreed at the start of the project; and
- Can prove that it fulfils all of the Requirements agreed at the start of the project by complete traceability to those Requirements from the final product.
Such a product would not only be what users wanted, but would also have an easier-to-manage development path. Naturally, time and financial constraints can stymie attempts to completely follow this process, leaving it perhaps as an ideal to aim for, rather than a complete solution. However, this article has hopefully helped to illuminate some of the pitfalls that may occur in the stages from the conception of a software product to its ultimate construction.
Click here to Read the original article on QA Guild
Computing Awards – IT Professional of the Year shortlist
Computing.co.uk, 17th October 2008
Who is the top IT professional in the UK this year?
View the Shortlist in full here
Software Test Outsourcing – the need to be Agile
IT BackBones, 16th October 2008
- Experimentus gives keynote speech at today’s Test2008 industry conference in India
- How to make outsourcing software testing work
- Agility drives success
At today’s Test2008 conference (Test Excellence through Speed and Technology Conference) at The Gandhi Darshan Complex in New Delhi, India, Experimentus (www.experimentus.com) will give a Keynote speech on how to make outsourcing software testing work.
Geoff Thompson, Director at Experimentus, one of the UK’s leading software quality management consultancies, comments:
“My keynote speech will focus on UK outsourcing software testing to India. At Experimentus we have worked on a number of projects where testing is outsourced to India using Captive outsourcing and Pure outsourcing.
“Today, I will highlight the key reasons why numerous worldwide organisations have decided to outsource both their testing and development to ‘onshore’ and ‘offshore’organisations:-
1. Reduced cost
2. Too much work so need additional assistance
3. Moving older maintenance activity that no current employee wants to be involved in
4. The desire to manage the test process and its costs more effectively
5. Company strategy to outsource non core activities
6. The lack of the right calibre staff internally despite economic slowdown
7. Personal choice
” I will be discussing the impact outsourcing has on the outsourced organisation and the outsourcer and also some of the pitfalls that with a lack of agility have ensured that some outsource arrangements were doomed to failure. I will explain how it is possible, with the right focus, to stop the outsource failures, as well as to look to the future to speculate on what will happen to outsourcing over the next few years.”
Testing experts from all around the world will join Experimentus at Test2008 to share strategies, trends and insights into world class testing. Speakers from around 10 countries such as USA, UK, France, Sweden, Italy, Israel and India will participate. The Conference will provide a platform for international and national test professionals to interact and participate.
Mr. Thompson added:
“As cost is one of the drivers to outsource, the immediate impact of the lower cost base in India will be seen to add value for a few years. Innovation is the next big step in Outsourcing. To sustain a long and prosperous relationship outsource organisations must strive to always innovate and thereby continue to add real value to the partnership bringing efficiencies across the board.”
Focus on Well Documented Functional Requirements
The Requirements Networking Group, 13 October 2008
With the Credit Crunch affecting IT budgets, Experimentus, a leading UK software quality management solutions consultancy, recently highlighted ten ways to reduce software development lifecycle costs within IT departments. Today we look in more depth at the first of these tips, “Focus on well documented Functional Requirements”.
Read the article in full here (registration required)
Pure Conference announces TEST2008 (Test Excellence through Speed and Technology), a conference for the Indian software testing industry
Businesswire India, 13 October 2008
Pure Conference announces TEST2008 (Test Excellence through Speed and Technology), a conference for the Indian software testing industry, in Delhi at Gandhi Smriti and Darshan Samiti, Rajghat from Monday, 13th October to Thursday, 16th October. The conference focuses on “Agility in Testing”. The theme will explore and expand on the need for testing teams to remain relevant and resourceful and to adapt to the changing demands of product and quality. The prime objective of the conference is to provide a platform for the Indian Testers to interact with the global names in software testing industry and enhance their own contribution in the global markets.
The five day event will feature tutorials and presentations from invited speakers and from members of the software testing community. The event will witness eminent speakers from over 12 nations across the world and participants from over 30 countries.
The keynote address at the conference will be delivered by Geoff Thompson, Director, Experimentus Ltd, UK.
Click here to read more
Software Testing Remains a Cinderella discipline
FT.com Digital Business, 8 October 2008
Within minutes of the start of trading on the London Stock Exchange on October 27 1986, there was meltdown. The brand new Seaq computerised pricing system – the heart of the City’s “Big Bang” transformation – had failed.
The reason, not uncovered until a few weeks later, was that a series of operations which should have moved chunks of information from one part of the system’s memory to another had collapsed under pressure, leaving some data in the wrong place and leading to a crash.
The fault had not shown up during testing because Seaq had never experienced the demand for pricing information that the Big Bang generated. Testing equipment that was capable of generating such a volume of requests was not available.
….. decades after the first commercial data processing software went live, testing of non-safety-critical systems is still often a hit or miss affair, commissioned by managers who do not necessarily understand the purpose of the exercise and therefore are unable to set clear goals for testers who are often under skilled or unqualified.
Geoff Thompson, chairman of the UK testing board and Consultancy Director of the testing specialist, Experimentus, is critical of managers who employ testers without really understanding why they are doing so.
Copyright The Financial Times Limited 2008
Read the article in full here
To download an archived cutting of the print version of this article, right-click on the following link and select “Save Target As” FT_08_Oct_Experimentus.GIF (.gif, 1.2mb)
Experimentus joins fellow software quality experts at London’s SQC conference
IT Backbones, 30 September 2008
- Highlighting the importance and benefits of software testing certification schemes
- A Round Table concerning test certification
Geoff Thompson, Director at Experimentus, a leading UK software quality management consultancy, joins fellow software quality experts at today’s London SQC Conference to discuss:
- Certification and testing
- The planned future directions of certification
- Test certification bodies
- What certifications outside of testing are recommended for testers
Click here to read more
Software testing standard gets its first approved consultants
Computer Weekly, 19 September 2008
The organisation responsible for the Testing Maturity Model (TMMi) industry-standard software testing, has accredited its first UK consultancy.
The TMMi foundation has awarded Experimentus assessor accreditation. The UK based joins Dutch firm, ImproveQS, as the only companies in the world that can provide accredited consultancy to firms using TMMi.
Click here to read more
Experimentus – First UK Organisation to become Accredited TMMi Assessor
IT Backbones, 18 September 2008
Experimentus (www.experimentus.com), a leading UK software quality management consultancy, today announces that it is the first IT solutions and services provider in the UK to be awarded accreditation by the TMMi® Foundation for its in-house developed TMMi assessment method. This prestigious endorsement confirms that Experimentus’ TMMi assessment method adheres to the highest professional standards in test and quality related process assessment.
Click here to read more
Experimentus grabs TMMi accreditation
Techworld.com, 17 September 2008
Experimentus has become the first software quality consultancy in the UK to be TMMi accredited. It is also one of the first two in the world, the other being ImproveQS in the Netherlands.
Click here to read more
Experimentus first UK TMMi software test firm
Computerworld UK, 17 September 2008
Systematic method to ensure consistent testing.
Experimentus has become the first software quality consultancy in the UK to be TMMi accredited. It was also one of the first two in the world, the other being ImproveQS in the Netherlands.
Click here to read more
Computing Awards – the shortlist is announced
Computing, 15 September 2008
We are pleased to announce the shortlists for the Computing Awards for Excellence 2008.
For the fourth year running we have received a record number of entries, 10 per cent up on the previous high last year. And the quality of the entries across the categories has been outstanding.
All the individuals, teams, companies and projects that have made the shortlist can be proud of their achievements – all of you demonstrate the strength of the UK IT community.
Click here to read more.
The Test Maturity Model Integrated (TMMi®)
Testing Experience Magazine, September 2008
Principal Consultant, Brian Wells, discusses the background behind what has fuelled the need to assess test process capability, the origins of Test Reference Models and, particularly, the emerging TMMi® Reference Model.
Click here to read more
Software Testing – the future?
Testing Experience Magazine, September 2008
Geoff Thompson, Consultancy Director, gives his opinions on what the future has in store for software testing – including qualifications, standards and test models.
Click here to read more
10 Tips to Reduce Software Development Lifecycle Costs
Test Focus Magazine, Vol.9 No.3, August 2008
The future of software testing
ComputerWorld UK, August 21, 2008
Can we learn from software testing failures in today’s world to improve the future of software testing?
Click here to read more
How to cut your software development costs
SME Web, August 18, 2008
Top ten tips to implementing the right strategy.
Click here to read more
Software Testing – The Future
IT Backbones, July 29, 2008
Can we learn from software testing failures in today’s world to improve the future of software testing?
Heathrow’s T5 software testing issues have highlighted the importance of software testing, I hope that lessons have been learnt and that CIO’s across the world will take note in the future.
Click here to read more
Metrics and measurement for IT
ComputerWorld UK, July 23, 2008
The famous quote goes, “You cannot manage what you cannot (or do not) measure”. That is as true for software development as any other IT discipline, but just because you can measure something, doesn’t always mean you should.
Click here to read more
Is it time to get out of the house?
Better Business Magazine, July 1, 2008
Where a business is based is of crucial importance – whether it’s to attract and retain the right people, portray the right image to customers or be in the best place to keep business buoyant. Experimentus Managing Director, Martin Adcock, talks to journalist John Spenser.
Saving Development Costs by the Numbers
SD Times, June 24, 2008
Last week I told you about 10 cost-saving tips from the U.K. and presented the first five. Here are the remaining five. They’re from Martin Adcock, managing director of London-based software quality management solutions consultancy Experimentus.
Click here to read more
Ten Tips to Reduce Development Costs
SD Times, June 17, 2008
The sagging economy, fuelled by rising fuel prices, has hit businesses hard, and everyone’s looking for ways to offset their new top-line cost: energy.
Some advice comes from the U.K., which has been dealing with energy costs higher than those in the U.S. for decades. Martin Adcock, managing director of London-based software quality management solutions consultancy Experimentus, offers 10 ways to reduce software development life cycle costs within IT departments.
Click here to read more
10 Ways to Cut Software Development Costs
Computer Business Review, June 13, 2008
This list of 10 ways to cut cost from the app dev lifecycle comes from Experimentus, a UK-based software management consultancy.
Click here to read more
Ten Tips to Reduce Software Development
Lifecycle Costs
StickyMinds.com, June 11, 2008
With the credit crunch affecting IT budgets, Experimentus, the leading UK software quality management solutions consultancy, highlights ten ways to reduce software development lifecycle costs within IT departments.
Click here to read more
The Value of Software Testing Qualifications
Computerworld UK, June 10, 2008
Qualifications can help but they are only a small part of the knowledge and skills requirement of a good tester.
Click here to read more
HBOS turns to TMM for software testing
Computer Weekly, May 16, 2008
HBOS has rolled out a software testing programme across three of its four major IT departments in a programme designed to reduce the number of errors in thousands of applications it builds every year.
Julian Clarke, Director at Experimentus, said HBOS is one of the first major UK banks to use TMM. “There are a lot using Capability Maturity Model (CMMI®) but it does not go into the required detail for software testing and quality.”
Click here to read more
Outsourcing: Is it for me?
Business Zone, May 9, 2008
The benefits of outsourcing can be huge. It can allow you to concentrate on growing a successful business without distractions, ensure staff focus on their key tasks, free up money to spend on other things and boost efficiency and customer service.
Martin Adcock speaks to Business Zone journalist, Dan Martin.
Click here to read more
Experimentus Highlights The Value Of Testing Qualifications
QA Guild, April 25, 2008
Experimentus presents at leading international SQC conference
Highlighting the importance and benefits of software testing certification schemes
Experimentus promotes industry international standard – ISTQB
Click here to read more
Experimentus Highlights The Value Of Testing Qualifications
ITBackbones.com, April 21, 2008
Geoff Thompson, Director at Experimentus, the UK software quality management consultancy, highlights the value of testing qualifications at today’s SQC Conference. The Software and Systems Quality Conference (‘SQC’), in Dusseldorf, is Europe’s leading international conference on software quality management, testing and process optimisation. The Experimentus specialist presentation will focus on the importance of software testing certification schemes and the role of the International Software Testing Qualifications Board (ISTQB).
Click here to read more
Test Maturity Model makes enterprise inroads
Computer Weekly, October 17, 2007
As test and test-related quality disciplines of IT mature, there is a growing need to assess process maturity quickly and robustly to accepted industry standards. There are many models available, but the Test Maturity Model (TMM) could provide the best way forward as it aligns more easily with industry standard software engineering assessment models than alternative models.
Click here to read more
Compuware’s Testing Round Table
Reg Developer, October 17, 2006
Software Testing is back on the Board’s agenda.
Click here to read more
M&S drives up software quality
Computer Weekly, October 5, 2005
Marks & Spencer has embarked on an ambitious project to ensure its projects are delivered on time, at lower cost, and with fewer coding errors.
Click here to read more
In search of quality
CBR, April, 2005
Testing software is not new, but its role in helping to boost software quality is more vital than ever. CBR reports.
