QA, Marketing & Sales cooperation leads to a better testing offering
#testing, # testing packages, #QA, #Sales, #Marketing, #make_choices_easier
There have been many elaborations and proofs on the topic of deliverables testing in IT development projects. There have been known cases of major embedded systems failures like:
- The Therac-25 radiation therapy machine: A software defect caused the machine to deliver lethal doses of radiation to patients.
- The Ariane 5 rocket explosion: A software error caused the rocket to veer off course and explode shortly after launch.
- The Mars Climate Orbiter: A failure to convert units from English to metric caused the spacecraft to crash into Mars.
- The Patriot Missile Failure.
You might want to read our Testing Manifesto article, where we explain what our testing methodologies are based on.
With this article we do not want to prove yet again that testing is a must or that you pay more for non-testing later on in the project, but we would like to concentrate on the idea of selling embedded systems testing service to less aware clients.
How to explain what type of testing is needed? How to convince the client which path needs to be taken? How to make the choice easier? When does warranty come into play for the created deliverables?
Problem identification
We are sure we are not the first to figure this out, but we believe that our observations and solutions can benefit those who try to convince their clients that testing gives benefits and those who try to cross-sell embedded testing services.
So what is the problem?
The problem is that: less aware clients, even if they know that testing is important, may not be aware of the choices they have nor their consequences.
QAs, testers and developers think and talk like engineers and might have a problem convincing clients that their work is vital for delivery of high level quality solutions and worth paying for. Their language does not make client’s choices easier. And this is where marketing and sales can join forces with engineers to help clients make the right decisions.
The Solution
We have gathered a dedicated group of people (QA, marketing, sales, CTO) to find a solution that will be better understood by our clients and by our team. And making things easier for the clients is one of the important methods of increasing your conversion rate.
We have decided to group the testing process stages, depending on the needs of our clients and offer them as packages. We also explain what the benefits are and consequences of selecting or not selecting a specific package.
Testing packages
Below we present a table where our 4 main packages are presented with the explanation of what is included and what are the benefits of each of them. These packages are implemented in our Quality Assurance process and presented during a pre-sale phase.
Packages executive summary:
- Package A – UAT- based – blackbox testing – obligatory – no warranty given.
- Package B – functional testing – based on detailed project requirements – 2-3 months of warranty + other benefits.
- Package C (must be chosen with package B) – functional extended (exploratory) – corner cases etc.
- Package D (must be chosen with package B) – pre-certification testing – necessary when certification is considered.
Package selection
The presented packages are related to each other. Below we present the graph supporting decision making. Package A is an obligatory choice if a BASIC route of quality assurance is chosen. Package B opens the PROFESSIONAL route to quality assurance and covers functional testing. B can be extended both with Package C and/or Package D.
Summary
Every improvement or adding clarity to the process brings benefits to clients and to the Embevity team. It is easier now to explain to our clients which parts of the QA process should be implemented, what are their benefits and drawbacks.
