If your company develops small mobile apps or games, then probably the most important thing for you is a working code and beautiful user interface. And that is perfectly correct. Unfortunately, it is pretty difficult to make a lot of money delivering relatively simple applications. The biggest software companies usually sell large and complex systems, and are moving forward to extend their offer to even bigger things – complete solutions built based on these complicated systems.
Take a look at The Top 100 European Software Vendors from 2013. This ranking is very interesting itself, but let’s focus only on the top three companies – SAP, Dassault Systemes and Sage. I bet you heard about them; they build pretty complicated products, don’t they? And companies from America like Microsoft, Oracle, HP and many others do it, too.
OK, big companies are doing big systems (surprise, surprise), but what does it mean in practice? And what does it mean for us – testers?
A complicated system cannot be just installed and started to being used. End users need to learn how to use them first. They learn it from documentation and during trainings. Actually, code quality is responsible only for a small part of end user interaction and perception. For big software products like ERP, ERM, MES, Databases, BI, etc. the first contact with the solution is very often training and documentation.
It means that we need to develop documentation and training materials to be released together with well-tested (of course) code. And this is what big companies do.
How is it usually organized?
In the case of most software vendors, the work required to deliver a COMPLETE solution is organized in the following way:
– Trainings are developed and delivered by trainers, usually working within separate Training Department.
– Documentation is developed and delivered by technical writers, usually working within separate Documentation Department (sometimes technical writers and trainers are part of the same team).
– Testers work within QA department and are responsible for testing the code, sometimes working closely with developers, from time to time checking the documentation quality as well, rarely being aware of what happens in the training area.
– Developers write the code and don’t care about the rest ;).
As a result…
– Technical writers get complaints from end users – documentation is (ekhm…) not really useful – does it look familiar?
– Trainers get complaints from trainees – training environment is (ekhm…) working differently than expected:
– Testers get complaints from trainers – see above.
– Developers write the code (next version) and don’t care about the rest ;).
It’s a little bit crazy, taking into consideration we all work in the same company, isn’t it? And yes, I meant developers too.
But if we remove the boundaries between testers’, trainers’ and technical writers’ worlds, and let them work together, they can achieve much more than when working separately. As a result we will improve the overall quality of the complete solution delivered to customers at the end. BTW: this is called a synergistic effect.
In most cases you don’t have to change much – reorganize reporting structure a little bit, change the sequence of existing activities and switch to more appropriate tools. The goal here is to:
- Use training materials and environments as a test data – for instance for upgrade tests.
- Use training materials (labs and exercises) as a test scenarios – usually they are much more real-life than your artificial tests.
- Use technical writers and trainers as testers and beta-testers – they will like this approach.
- Use testers input to improve documentation and training materials – they will like this approach even more.
- Use documentation and training to improve testers’ knowledge of the product and user needs.
- Use test scenarios as a training materials for technical writers and trainers.
Looks simple and obvious, but still many companies (even big ones) don’t do it this way. Please let me know if you are interested in seeing in details how these ideas can be implemented in practice – either be leaving the comment here, or via e-mail: dd(at)dredar.com.
About the Author
Dariusz Drezno (head and founder of DREDAR) is a seasoned QA Manager with more than 10 years of experience in leading test, technical documentation and training teams in various global companies. His background covers telecommunication, embedded systems, manufacturing execution and global distribution systems. He works also as an independent trainer and consultant helping customers to establish, lead and improve their testing, technical communication, trainings and quality management systems.
