The key difficulty for modern software testing is how to provide accurate and full data to help management’s decisions on product launch. Testing companies usually lack accurate knowledge of the risks and challenges that are crucial to the management team. This may result in poor decisions being made, or at the very least, decisions being made without being fully aware of the consequences. In order to produce accurate reports on project progress, it is our obligation as testers to collect genuine data and determine what accurate data is required. Our capacity to do this correctly will determine the direction of software testing. The future of software testing depends on our ability to get this right. In this article, we’ll explore the critical role of testing in decision making and why it’s essential to provide complete data to ensure the success of product launches.
Too often today, the test team arrives and sits in its cocoon, appearing only at the end of a test cycle to announce that they are not done yet, but have nothing useful to say, except perhaps statements like: “You can’t start because…”, “We have 120 more tests to run”, “We are still finding bugs”, “I wouldn’t go on the air just yet.”
None of them gives even the slightest hint of a launch impact! How critical are the remaining 120 tests? What’s wrong with profile search? Why is testing still finding bugs? These are just some of the questions that these claims raise, but which they cannot answer. If testing fails to provide correct information, I suggest that perhaps the situation many QA companies find themselves in today is more deplorable than it first appears.
Data requirements are never static, so testers also need to be aware of changing information needs as the project evolves. To ensure the future of software testing, should everyone involved in testing influence how people manage testing and provide information? Is it a qualification or maybe standards, are there test models and what role do tools play in this area?
Software Testing Qualifications
There does seem to be some polarization in the industry as to the value of different types of qualification, some calling for them to be banned, others suggesting that having got them you are able to sell yourself as a competent tester.
The reality is that a good tester or test manager needs many components of skills and knowledge combined to make them successful. In my view the qualifications account for about 10% to 15% of the knowledge required for the practical application in the Workplace.
So I believe qualifications have a very important part to play in the education and verification of software testers and test managers. A competent outsourcing testing partner https://testfort.com/qa-outsourcing plays a huge role in the formation and growth of any company.
But the reality is that the exam candidates leave with an understanding of the basic vocabulary and approach to testing, but in most cases no real practical capability, and certainly no understanding of how to communicate outside of the test team.
Standards
There are a few out there, for example BS7925 – 1&2 (the British standard for Component Testing), IEEE829 (the Test Documentation standard) etc.
In their favor Standards are developed by a very wide working group who build and review the content. In most cases involvement comes from right around the globe. However, by necessity they are generic and some concessions have to be made to gain global agreement and provide one solution for everyone, so they are useful but they can’t provide the whole answer.
Standards don’t, in any example I have seen, indicate how to provide and what information is needed to communicate effectively with the programme, although they can help.
They are, however, excellent process models that provide guidance on how to establish your test project.
Test Models
There are many models available for testers to review against. Most consultancies will have a Test Maturity Model of their own.
The new TMMi Model is most likely the best model now on the market for assisting in ensuring effective processes are used throughout test projects. The Evolution of Testing Model by Gelperin and Hetzel, that explains the development of the testing process more than a 45-year period, the Beizer’s Testing Model, which describes the evolution of the individual tester’s thinking, and international testing standards are just a few of the sources that the TMMi model draws on for information. The ISTQB Standard Dictionary of words used in Software Testing is where the TMMi’s testing jargon originates.
The model is structured much like CMMi with 5 levels of maturity. At level 2 of the model projects begin to be assessed on their capability to measure progress through testing.
Tools
Tools can be excellent providers of data, but that data is only as good as the way it is collected. A common problem, for example, with Test Management tools is that the tool is implemented straight out of the box, with no configuration. Testers then load test cases into the tool with no views on how progress will be tracked, so they load the minimum data to allow them to do their job. Then they try to track progress, but realize that the data needed to do this hasn’t been loaded, so they can track certain elements, so unfortunately in my experience the reporting in these situations is very poor.
So with some real thought up front as to what information/data is required the tools can be configured to ensure that data is a by-product of the process (e.g. does not become time consuming to collect and report).
So having identified the data, the key is how it is presented back as information in the right format at the right time.
This particular issue does seem to reside in the Test Managers camp, so I would like to focus there for now.
Is there any future for software testing ?
I believe that the future of testing depends on the following:
- Accurate information provision, in the language of the recipient
- Building quality in, rather than testing it out, prevention rather than detection
- Ensuring that quality is considered and not seen as a burden, alongside time and cost.
As it has been said already the great thing about Qualifications is that they have established some common terminology amongst testers, but that terminology is still not translatable across the lifecycle. So we have four languages as a minimum being spoken in projects today, we have the Business (client), the designers, the developers and the testers, and in an IT Infrastructure Library organization is possibly a fifth.
We have projects that sit together but don’t talk to each other. We also have so called Agile projects starting to show how greater collaboration brings big benefits, is this the way forward?
I think the way forward for information provision is actually to learn something from the Agile world and start to talk to each other, and not to work in silos. Everyone’s requirement for information is different and so the closer projects work together and people mix the more we can understand what our requirements are.
Lots of organizations seem to think that by putting people in buildings in different countries and arming them just with a process they will get great results. This ignores the need to work as a team and communicate, and so in most instances is a strategy doomed to failure.
In a world of increased outsourcing or offshoring this becomes increasingly harder to achieve. This is especially relevant when the test resources, or development resources, work across the other side of the world in a different time zone. It is as important, if not more important, that in these situations proper and regular communications are established. It’s not easy but if success is expected then effort needs to be put in to ensure that each party is aware of their goals and provides the right information to enable measurement of progress to be tracked and understood.
