Какой была ваша первая зарплата в QA и как вы искали первую работу? Мега-обсуждение в нашем телеграм-канале.
- Что такое тестовая документация
- В чем ее важность
- Какую тестовую документацию используют QA-команды
- Тест-план
- Чеклист
- Тест-кейс
- Сценарий использования
- Баг-репорт
- Требования
- Как все это работает
Как и в любом другом процессе, документация в QA помогает командам организовать свою работу. С ее помощью мы можем стандартизировать процесс, дать определение терминам, установить основные этапы тестирования и держать всех членов команды в курсе дел.
Что такое тестовая документация?
Тестовая документация — это набор документов, создаваемых перед началом процесса тестирования и непосредственно в процессе. Эти документы описывают покрытие тестами и процесс выполнения тестов, в них указываются необходимые для тестирования вещи, приводится основная терминология и т. д.
Как собеседоваться? Хитрые вопросы на собеседовании. Моральные установки. Встреча подписчиков №1
В тестовой документации любой член команды может найти полную информацию обо всех действиях, связанных с тестированием (и об уже выполненных, и о запланированных).
В чем важность тестовой документации?
Если тестирование не документируется, это мешает увидеть полную картину проекта. Без четких целей, пошагового плана по их достижению и указания всех важных условий ожидаемый результат будет неясен. В таких условиях у всех может быть разное понимание общей цели и конечного продукта.
Тестовая документация определяет, что для нас важно и почему, какие действия мы должны выполнить и сколько времени у нас есть. Наконец, в документации обозначено, чего должна достичь команда и что сигнализирует об окончании процесса.
И QA-инженеры, и клиенты могут хотеть получить на выходе приложение, вообще не имеющее багов. Но это не достижимая цель, а мечты. Поэтому имеет смысл обсудить, что будет определять конец фазы QA.
Например, мы можем протестировать весь функционал один раз. Или тестировать приложение до тех пор, пока в продакшене не останется критических ошибок. Или быстро проверить критически важные для бизнеса функции, что позволит успеть к дедлайну.
Как правило, попытки оговорить все это в переписке или телефонных переговорах неэффективны. Все дело в человеческом факторе. У кого-то просто слишком много информации, которую нужно обработать и запомнить. Кто-то может неправильно понять договоренности. В результате у каждого появляется своя интерпретация требований и целей.
Отсутствие документации может серьезно повлиять на работу тестировщиков. Это особенно верно при работе со сложными продуктами или при часто меняющихся требованиях.
Непонимание того, как и почему должна вести себя та или иная функция, приводит к большему количеству ошибок. Неправильная расстановка приоритетов может привести к пропуску багов и предоставлению неполных отчетов. Примеры можно продолжать и продолжать.
Какую тестовую документацию используют QA-команды?
Наиболее часто используемые документы — это планы тестирования, чеклисты, тест-кейсы, сценарии использования, баг-репорты и спецификации требований.
Как построить процесс тестирования с нуля?
План тестирования (test plan)
План тестирования описывает все действия по тестированию в рамках одного проекта. Здесь вы можете найти информацию обо всем, что нужно сделать тестировщику или команде QA в ходе проекта.
В каждом плане тестирования указывается объект тестирования, график работы, критерии начала и окончания тестирования, стратегия, риски и список выполненных работ.
Чеклист (checklist)
Чеклист — это документ, содержащий краткое описание функций, которые должен проверить тестировщик.
Выглядит чеклист как список функций с указанием статуса — результата проверки.
Чеклисты могут использоваться вместо тест-кейсов, поскольку их легче подготовить. Но если вам нужно более конкретное описание процедуры, без тест-кейсов не обойтись.
Тест-кейс (test case)
В тест-кейсе содержатся:
- подробное описание шагов и действий, которые тестировщик должен выполнить для тестирования какой-то одной части функционала,
- критерии прохождения тестов.
Компании могут использовать разные форматы тест-кейсов, но информация в них всегда очень подробная и конкретная.
Сценарий использования (use case)
Use case — это более простой и менее официальный документ. Он описывает сценарий взаимодействия с программным обеспечением.
Каждый юзкейс основан на предположении о том, что пользователь программы будет делать и где он будет кликать. Это позволяет тестировщикам протестировать предполагаемые пути пользователя.
При создании юзкейсов тестировщики учитывают требования и бизнес-цели.
Баг-репорт
Баг-репорт предоставляет полную информацию о баге (его описание, серьезность, приоритет и т. д.) и документирует шаги и условия для воспроизведения этого бага.
Подробный и эффективный баг-репорт значительно увеличивает шансы быстро исправить баг.
Требования (requirements specification)
Спецификация требований или просто требования — это полное описание разрабатываемого программного обеспечения.
В требованиях указываются свойства, качества и особенности разрабатываемой программы. Используя эту информацию, команды могут избежать недоразумений и разногласий.
Как все это работает?
Документы бывают высоко- и низкоуровневые. Все тестировщики могут составлять чеклисты, тест-кейсы и баг-репорты. Это часть их повседневных обязанностей.
А вот подготовка плана тестирования требует дополнительных навыков и опыта. Это задача для опытного специалиста или QA Lead.
Чем крупнее проект, тем больше документации нужно.
Если команда использует для сложного продукта только чеклисты, есть риск неправильного понимания приоритетов и проведения неэффективных тестов. Причина кроется в отсутствии деталей. Чеклист только называет функцию, и каждый тестировщик может интерпретировать объект тестирования и результаты по-своему.
Тестовая документация динамична. Она эффективна только в том случае, если команда QA регулярно ее обновляет.
Если документацию заводят только «чтобы было», никакого смысла в ней нет. В ходе тестирования могут меняться требования и приоритеты. Это влияет на покрытие тестами, необходимые ресурсы и т. д. Если команда не записывает изменения, в результате получаются неэффективные документы и непоследовательность в работе.
Аналогично, со временем устаревают и теряют свою актуальность тест-кейсы и сценарии использования. Может появиться новый функционал, который тоже нужно покрыть тестами. И если вы не будете все тщательно записывать, вы рискуете получить бесполезную документацию.
В заключение
Каждая компания сама определяет, стоит ли создавать тестовую документацию. QA-специалисты могут рекомендовать клиентам это сделать, но последнее слово остается за клиентами.
Что касается преимуществ документирования рабочего процесса, то они вполне очевидны. Описанные нами документы помогают упорядочить имеющуюся информацию. Благодаря этому даже новичок в команде сможет легко разобраться, что к чему. И хотя создание документации требует дополнительного времени, ее отсутствие приведет к куда большим временным затратам.
Источник: testengineer.ru
Тестирование документации программного обеспечения
В современном российском мире ИТ можно выделить 2 основных подхода к разработке документации программного обеспечения:
- Разработка документации в соответствии государственными стандартами Российской Федерации. В данную категорию попадают все ИТ-проекты для учреждений госсектора и предприятий, взаимодействующих с данными учреждениями. Разработка документации выполняется строго в соответствии с ГОСТ 2, 19 и 34 серии.
- Разработка документации в соответствии с внутренними стандартами Заказчика. В данном случае разработка документации регламентируется внутренними правилами Заказчика, которые могут быть построены на базе ГОСТ, ISO/IEC или собственной методологии.
Каждый из указанных выше подходов подразумевает, что для успешной сдачи ИТ-проекта Заказчику, Исполнитель должен предоставить, в том числе, комплект технической документации, однако зачастую понятие «Качественная документация» в ИТ-проектах явным образом не определено.
Так что же такое «Качество документации»? Качественная документация должна соответствовать своему целевому назначению, а также набору критериев качества, например: полнота описания, непротиворечивость положений внутри одного документа, а также в комплекте документов, отсутствие логических и грамматических ошибок и т.д.
Комплекс мероприятий по контролю качества документации называется «Тестирование документации». Тестирование документации выполняется с целью:
- Минимизации рисков несоответствия фактически реализованной функциональности информационной системы (ИС) и функциональности, описанной в документации. Наличие таких дефектов в документации повышает вероятность провала приемочных испытаний ИС, либо приводит к значительному увеличению трудоёмкости и длительность приёмки ИС.
- Минимизации рисков приемки в эксплуатацию ИС с некачественной документацией. Нередко документацию в ИТ-проектах разрабатывают лишь с одной целью – успешно пройти приемочные испытания, не задумываясь о потребностях конечных пользователей документации: аналитиков, пользователей ИС, технических писателей, руководителей проектов, специалистов технической поддержки, тестировщиков.
Примеры типичных дефектов, снижающих качество и ценность документации:
- требования Технического задания недостаточно детализированы, возможно их неоднозначное толкование;
- отсутствие определений для применяемых в документации терминов и сокращений;
- противоречие положений документа друг другу и положениям других документов;
- несоответствие требованиям ГОСТ в области оформления технической документации (ГОСТ 2.601-2013).
Если Заказчик оплачивает разработку ИС, то в итоговую стоимость уже включена разработка документации, поэтому вполне логично, что Заказчик должен требовать качественного результата и иметь возможность его проконтролировать, ведь помимо успешного приема ИС в эксплуатацию качественная документация может обеспечить достижение следующих бизнес-целей:
- снижение трудозатрат на техническую поддержку: снижается общее количество обращений пользователей, а также снижаются сроки поиска администраторами ответов в документации
- сокращение сроков обучения новых пользователей;
- функциональное тестирование ИС: чем подробнее функциональность описана в документации, тем проще её потом будет протестировать в полном объёме;
- сокращение операционных затрат на разработку новой функциональности ИС за счет сокращения сроков сбора информации о текущей функциональности и минимизации накладных расходов, возникающих из-за некачественного описания требований в документации.
Рассмотрим примеры ситуации, в которых тестирование документации наиболее актуально:
- заказчик выполняет приемку результатов контракта на разработку ис, заключенного с подрядчиком, в том числе техническую документацию. необходимо выполнить независимую экспертизу документации, разработанной подрядчиком: оценить пригодность документации для проведения приемки ИС, а также качество документации в целом.
- Заказчик регулярно принимает в эксплуатацию новые релизы ИС, необходимо проконтролировать качество документации для каждого нового релиза.
- заказчик регулярно проводит конкурсы по закупке услуг по разработке ИС. ввиду необходимости подготовки большого объёма закупочных документов и отсутствия у заказчика специалистов нужной квалификации в достаточном количестве, для выполнения работ привлечен подрядчик – специализированная организация. заказчику необходимо проконтролировать качество разработанной подрядчиком документации: пригодность документации для проведения конкурса в соответствии с целями и задачами Заказчика.
Тестирование документации – непростая работа, для проведения тестирования должны быть привлечены специалисты с особыми компетенциями: аналитики и технические писатели, и зачастую в штате Заказчика либо нет таких специалистов в нужном количестве, либо они заняты на других проектах, таким образом, приобретает актуальность передача тестирования документации на аутсорсинг.
Сильной стороной компании «Перфоманс Лаб» как поставщика услуг по тестированию документации является наличие Единой методики контроля качества документации. Данная Методика – не просто формально разработанный документ, это унифицированный механизм, позволяющий в сжатые сроки наиболее полно проверить документ на соответствие разнообразным критериям качества. По сути Методика является максимально формализованным чеклистом, содержащим набор проверок (набор правил, которым документ должен соответствовать). Выполняя проверку посредством такого чеклиста значительно снижается вероятность пропустить ошибку, повышается качество тестирования документации, а именно:
- Все правила в Методике максимально детализированы и дифференцированы, что исключает их некорректную трактовку сотрудниками, проводящими тестирование документации.
- Имеются наборы правил, адаптированных под документы различного типа и комплекты документов, что позволяет оптимизировать процесс и снизить сроки тестирования, облегчает передачу знаний на проекте.
- Все правила ссылаются на нормативный документ, таким образом, результат проверки выглядит более понятным для Заказчика.
- формат оформления правил проверки в методике предполагает минимум действий по заполнению: нужно только указать соблюдаются ли в документе требования правила (да/нет) и если обнаружены несоответствия – указать номер страницы. Таким образом, снижается трудоемкость оформления отчётной документации – выполняем проверку по всем правилам из Методики и получаем готовый отчёт.
Об авторе
Алексей Характеров – ИТ-специалист со стажем более 5 лет. Алексей является техническим писателем компании Перфоманс Лаб — глобальной компании, специализирующейся на тестировании и обеспечении качества ПО. Основное направление деятельности — технический пресейл.
Источник: www.performance-lab.ru