Ousourcing Testing Problems. Our experience
February 18, 2014
Software testing as IT industry sector develops rapidly. Nowadays our company has a strong team of testers. And today we want to share our experience. There are different projects and customers. Once we had a project with a foreign client. The collaboration was quite tough. All the outsourcing problems we run into are described below.
We were set a trivial task to write auto-tests for web interface using Selenium Webdriver and upload them to TeamCity. The auto-tests had to cover all the main functionality. But…we faced some problems.
The main testing problems are:
1. Lack of understanding.
The customer misunderstood why and what for to cover the functionality with automated tests. When we saw the half-baked functionality, the first thing we said to the customer were the words from automation textbooks: ”There is no sense to automate the unfinished software product. It will lead to costs, in time, energy and money. It is better to implement the product firstly, and then to start automation”. Our words were ignored and the customer insisted on establishment. We lost time supporting and editing scripts after functionality changes. As a result, the customer was dissatisfied.
2. Lack of documentation.
There were no documents describing the functionality and business logic of application. The customer commented it that way: “A small amount of people is engaged in the project. Everybody knows perfectly how the functionality works”. We had to write all documentation according to developers’ words. It turned out they did not understand the logic of application as well. We wasted time again. As a result, the customer was dissatisfied.
Manual testing was held very rare and by developers only. Later on we took on this function. Frequent changes of one and the same functionality, up to a complete change of certain features, all these factors made us spent more time for manual testing, not for writing the scripts.
4. Poor communication.
Lack of communication was between us and the customer, the customer and his developers. As a result, the development process can be described this way: developers make changes but do not inform testers about it. The team of testers, it means us, had another problem. Almost all the autotests fell and we had to test the functionality manually, to make changes to test cases and to edit (sometimes completely rewrite) the scripts. Periodically changes were made by the customer and even the developers didn’t know about it. Some part of scripts ceased to work again. We asked questions concerning the changes, but the developers just shrugged their shoulders…
This project gave us a great experience. And here are some tips for those who are planning to be engaged in testing and working with foreign customers:
- Think twice before accepting the project. It turns out the work to be done is much more difficult than it is described by customers.
- Require documentation. Any project information which the customer or developers can give is very useful. It is desirable in writing.
- Ask questions. Don’t hesitate to call developers, managers and to ask to explain or simply to specify the issues you need.
- Retain correspondence. Keep all the information that managers and developers give you. In case some conflicts arise, you will have arguments to explain your actions.