Об авторе: Эта статья написана членом команды STH Company, в которой он работает QA-менеджером.
Перевод статьи «Software Testing Documentation Guide (Why It’s Important)».
За всю свою карьеру QA инженера я никогда не слышал, чтобы люди часто говорили о том, как важна документация по тестированию программного обеспечения.
Общее мнение о ней таково: каждый, у кого есть свободное время, в состоянии написать такую документацию, как тест-кейсы, план тестирования, отчет о состоянии процесса тестирования, баг-репорт и т.д. В этом нет ничего сложного. Разберемся, действительно ли это так.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Содержание:
Важность документации по тестированию ПО
Что такое тестовая документация?
10 советов для достижения целей в области тестовой документации
Важные документы по тестированию ПО
Важность документации по тестированию ПО
Мой опыт
Хочу поделиться с вами примером из своей практики.
Мы сдали проект с неизвестной проблемой в нем одному из наших клиентов, который был очень недоволен. Проблема была обнаружена на его стороне, и это была не самая приятная для нас ситуация. Как обычно, вся вина была возложена на QA отдел.
Проблема заключалась в совместимости одного веб-сайта. Когда дело дошло до меня, у меня на руках было доказательство отсутствия документа с требованиями, в котором четко прописана необходимость проверки совместимости этого сайта. К счастью, я был в безопасности.
Это был хороший урок для меня, я понял важность документации. С того дня я начал больше работать с артефактами и создавать такие тестовые документы, как план тестирования, тестовые случаи, контрольный список тестирования на вменяемость, баг-репорты и многое другое.
Что такое тестовая документация?
Все мы читаем различные статьи о технологиях и методах тестирования, но как часто нам попадались статьи о документации? Несомненно, редко, но разве дело в том, что документы не важны? Нет, причина заключается в том, что мы еще не осознали важность тестовой документации.
При этом нельзя не упомянуть тот факт, что проекты, в которых присутствуют все документы, имеют высокий уровень готовности.
Большинство компаний не придают документации даже малой доли того значения, которое они придают процессу разработки программного обеспечения. В Интернете мы можем найти множество шаблонов по созданию различных типов документов. Но сколько из них действительно используются организациями или отдельными лицами?
Хотя тщательное документирование может сэкономить время, усилия и деньги организации!
При прохождении любого вида сертификации особое внимание уделяется документации. Это показывает важность клиента и процессов для человека и организации в целом. Если вы не сможете подготовить удобный для пользователя документ, никто его не примет, независимо от того, насколько хорошо создано ваше ПО, .
В моей практике была один продукт, в котором имелась немного запутанная функциональность.
Когда я начал работать над ним, я попросил у менеджера QA отдела передать мне на ознакомление справочные документы, на что получил ответ: “Нет, у нас нет никаких документов”. Тогда я поднял этот вопрос перед руководством, потому что как QA инженер я знал, что никто не сможет понять, как использовать продукт без справочной или обучающей документации.
Если пользователь не удовлетворен, то как мы собираемся зарабатывать деньги на этом продукте?
То же самое относится и к руководствам пользователя. Возьмем пример Microsoft. Эта компания выпускает каждый продукт с соответствующей документацией. Даже для Microsoft Office 2007 у нас есть документы, очень подробные и понятные любому пользователю. Это одна из причин успеха всей продукции компании.
В небольших компаниях мы часто можем услышать: “Проект отклоняется на этапе предложения или на начальном этапе”. Это происходит потому, что в документации предложения не хватает краткости и выразительности, чтобы показать возможности организации.
Дело не в том, что небольшие компании не могут выполнять высококачественные проекты, а в их неспособности выразить свои возможности. (Я тоже работаю в небольшой организации с 80 сотрудниками, и я слышал это много раз).
Лично я считаю, что отдел обеспечения качества – единственный отдел, который может сделать это возможным. Мы – единственный отдел, который обеспечить успешное будущее для наших организаций.
Давайте упорядочим все обсуждения в нескольких пунктах с точки зрения обеспечения качества:
- Уточнить цель и методы качества.
- Обеспечить ясность задач и последовательность их выполнения.
- Обеспечить внутреннюю координацию работы с клиентами.
- Предоставить обратную связь по превентивным действиям.
- Предоставить обратную связь по циклу планирования.
- Создать объективные доказательства эффективности вашей системы менеджмента качества.
10 советов для достижения целей в области тестовой документации
Как я говорил выше, по мнению большинства документацию по тестированию программного обеспечения может написать любой человек, у которого есть свободное время. В первую очередь необходимо изменить это мнение, и только тогда мы сможем полноценно использовать силу документации в наших проектах.
Дело не в том, что мы не знаем, как правильно оформлять документацию. Мы просто не считаем это столь важным.
У всех должны быть стандартные шаблоны для всех видов документации, начиная со стратегии тестирования, плана тестирования, тестовых случаев и тестовых данных для баг-репортов.
Это просто формальное следование некоторым стандартам (CMMI, ISO и т. д.), но когда дело доходит до фактической реализации, сколько из этих документов мы действительно используем? Нам просто нужно синхронизировать наш процесс обеспечения качества со стандартами документации и другими процессами в организации.
Самый простой способ следить за всеми видами документации – это вовлечь на начальной стадии в проект человека, который понимает его динамику, область, цель и технологию. Кто может сделать это лучше, чем QA-специалист (конечно, для этого существуют технические писатели – но мы рассмотрим общий сценарий для небольших компаний, где технических писателей нет).
Я считаю, что для достижения этой цели тестирования и документирования нам необходимо сосредоточиться на некоторых моментах, указанных ниже.
10 лучших советов, которые помогут вам достичь целей в области тестовой документации:
1. QA инженера следует привлекать на самой ранней стадии проекта, чтобы он и документация работали рука об руку.
2. Процесс, определенный QA инженером, должен выполняться техническими специалистами, это помогает устранить большинство дефектов на самом начальном этапе.
3. Просто создать и поддерживать шаблоны тестирования программного обеспечения недостаточно, важно, чтобы люди применяли их в работе.
4. Нельзя просто создавать и оставлять документ, его нужно обновлять по мере необходимости.
5. Требования к изменениям – важный этап проекта, не забудьте добавить их в список.
6. Используйте систему контроля версий. Это поможет вам легко управлять документами и отслеживать их изменения.
7. Облегчите процесс устранения дефектов, документируя каждый найденный баг. Обязательно включайте четкое описание дефекта, шаги по воспроизведению, затронутую область и подробную информацию об авторе.
8. Постарайтесь задокументировать все, что вам необходимо для понимания вашей работы, и что вам нужно будет предоставить заинтересованным сторонам, когда это потребуется.
9. Используйте стандартный шаблон для документации (например, лист excel или файл doc), и придерживайтесь его для всех ваших потребностей в документах.
10. Размещайте документы по проекту в одном месте, которое доступно всем членам команды для ознакомления, а также для обновления в случае необходимости.
Я не гарантирую, что, применяя эти шаги, вы получите неожиданные результаты. Изменения не произойдут за день или два. Но нужно начать делать хоть что-то, чтобы эти изменения происходили постепенно.
Существуют сотни документов, используемых в жизненном цикле разработки и тестирования программного обеспечения.
В конце концов, “документация нуждается в документации”. Разве не так?
Важная документация по тестированию ПО
Ниже перечислен перечень важных документов по тестированию программного обеспечения, которые необходимо регулярно использовать и поддерживать:
- План тестирования.
- Тестовый дизайн и спецификация тестовых случаев.
- Стратегия тестирования.
- Сводные отчеты о тестировании.
- Еженедельный отчет о состоянии.
- Документы / руководства пользователя.
- Отчет о приемке пользователя.
- Оценка рисков.
- Журнал тестирования.
- Отчеты об ошибках.
- Данные тестирования.
- Анализ тестирования.
Тестировщикам программного обеспечения также регулярно приходится обращаться к следующим документам:
1) Спецификации требований к программному обеспечению.
2) Функциональные документы.
Заключение
Документы по тестированию программного обеспечения всегда играют важную роль на этапе разработки/тестирования проекта. Поэтому всегда документируйте все, когда это возможно. Не полагайтесь только на слова. Всегда постарайтесь обезопасить себя от неожиданностей.
Документация не только спасет вас в непредвиденных ситуациях, но и поможет организации в долгосрочной перспективе, сэкономив средства на обучении и, самое главное, на устранении проблем, возникших из-за отсутствия документов по разработке и тестированию.