Зачем тестировать документацию к проекту? WHY TESTING THE PROJECT DOCUMENTATION?

Наверное, у каждого среди коллег, руководства или у заказчиков был такой вопрос:«Зачем тестировать документацию к проекту?» Зачем тратить на это время и деньги? И, скорее всего, вслед за этим следовал скептический ответ наподобие: "Все равно документация правится в ходе работ,и ошибки в проекте будут, и никакое тестирование технического задания (ТЗ) не поможет от них избавиться". Да, я соглашусь. Документация будет правиться в большинстве случаев, и ошибки обязательно будут, даже после тестирования документации. Probably everyone was asked the question "Why testing the project documentation?" by colleagues, management, or clients. Why spend time and money on it? Most likely it was followed by a sceptical answer like: Anyway, the documentation will be changed on the way and there will be errors in the project and not specifications testing can help to avoid them. Yes, I do agree. The documentation will most likely be changed, there will be errors even after the documentation is tested.

В качестве примера, рассмотрим ситуацию: при тестировании, уже реализованного проекта, присутствует противоречие в документации. Макеты и описание в документе, предоставленном заказчиком, противоречат друг другу. Разработчик сделал так, как нарисовано в макете или описано в документации. В результате тестирования у специалиста возникают сомнения: является ли найденный дефект ошибкой и как в конечном счете должно быть. Тестировщик поднимает вопрос, чему необходимо следовать, макету или документации и обсуждает его с аналитиком и руководителем проекта. Аналитик, вполне вероятно, уже забыл какая именно обсуждалась реализация, т.к. документ составляли задолго до этапа разработки, поэтому он обращается к заказчику и т.д. Сколько времени уйдет на выяснение и разрешение таких ситуаций? Тестирование документации не выявит все ошибки, но снизит риски их появления, а главное, сэкономит время в ходе проекта и сроки на сдачу проекта. Так разработчик и тестировщик не будут спорить и выяснять,правильную реализацию задачи. Let us consider an example: a contradiction in the documentation was found when testing the already implemented project. The models and description in the document provided by the customer contradict each other. The developer implemented what was drawn in the model or described in the documentation. After the testing, the expert has some doubts: if the defect an error and what should the result be? The tester raises the question, what should be followed, the model or the documentation and discusses it with the analyst and the head of the project. The analyst has probably already forgotten what was to be implemented as the document was drafted long before the development, therefore she addresses the customer etc. How long will solving these issues take? Documentation testing will not reveal all errors but will decrease the risks of them arising and, most importantly, save the time in the course of the project and delivery time of the project. Thus the developer and the tester will not have to argue and find out the proper implementation of the task.

При этом ситуация с заказчиком выглядит следующим образом. Когда на стадии подписания документации обе стороны (заказчик и исполнитель) довольны и видят, как им кажется "одну картину", при сдаче проекта тот же самый документ, те же самые люди могут видеть по-разному. И в этом случае, они точно будут недовольны друг другом. The situation with the customer looks the following way. When at the stage of signing the documentation both parties (the customer and the contractor) are satisfied and see, as they think, "the same picture", when the project is delivered the same people may see the very same document differently. In this case they will definitely not be happy with each other.

Таких примеров можно привести большое множество. Но как известно клиент всегда прав. В итоге будет много выяснений, как правильно и как быть. Команды могут потерять время, и деньги, сроки могут затянуться. Но самое главное, в таких ситуацияхможно испортить свою репутацию. There are many examples of this sort. However, the client is always right. Finally, there will be many discussions about what is right and what to do. The teams may lose the time and time, the time frame may expand. What is the most important, these situations can spoil your reputation.

Вывод: тестировать документацию просто необходимо. Найдите весомые доводы и факты, например, приведите реальные примеры с прошлых проектов, и убедите руководство и свою команду в необходимости тестирования документации к проекту. Даже если ваше руководство упорно не желает внедрять тестирование документации и не принимает прошлых примеров, попробуйте договориться внедрить этот процесс на любом (или недорогом) проекте в вашей компании в виде эксперимента. Далее, все найденные ошибки в документации распишите, сколько эта ошибка будет стоить на каждом этапе. Conclusion: documentation testing is a must. Find strong facts and arguments, for example, provide real examples of past projects, and convince the management and your team in the need to test the project documentation. Even if your boss does not want to introduce documentation testing and does not accept the past examples, try to negotiate introducing this process in any (or cheap) project of your company as an experiment. Further, price all the errors found in the documents at every stage.

Например, For example,

Ошибка 1. Часы на исправление ошибки: Error 1. Number of hours to fix:

1) исправить ошибку на этапе анализе – 1ч аналитик; 1) fix the error at the analysis stage - 1h, analyst;

2) исправить ошибку в начале этапа разработки – 1ч разработчика, 1ч аналитика; 2) Fix the error at the early stage of development 1h developer, 1 h analyst;

3) исправить ошибку в конце этапа разработки – по 2ч трех разработчиков, и 1ч аналитика и т.д. 3) Fix the error in the end of the development - 2h three developer each and 1h analyst etc.

Я уверена, что такие фактические цифры будут намного более убедительны и неоспоримы. Если вы сможете убедить ваше руководство внедрить в компании тестирование документации, в дальнейшем руководители проектов и аккаунт менеджеры смогут найти убедительные доводы для заказчиков в том, что данный процесс на проекте необходим. I am confident that these real numbers will be more convincing. If you will convince your management in the need to test the documents, the project managers and account managers will find the most convincing arguments to convince the clients that this process is essential for the project.

2017-05-19

Зачем тестировать документацию к проекту? WHY TESTING THE PROJECT DOCUMENTATION?

Напишите намSend us an E-mail

Обратная связьCONTACT US

Ваше письмо отправлено!Your letter has been sent!