Как быть тестировщику, если на проекте нет аналитика и спецификации? Маша Кузнецова, младший QA-инженер red_mad_robot, рассказывает о трёх возможных вариантах действия — осторожном, умеренно рискованном и максимально упоротом. Будет особенно полезно QA начального и среднего уровня — чтобы не растеряться, попав в похожую ситуацию.
Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.
Это та причина, по которой многие подрядчики стараются избегать таких требований, как огня, что перекладывает риски во времени на более поздние этапы и на заказчика.
Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.
Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.
При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?
С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».
Пока что умение специалистов и команд выявлять и формулировать такие ограничения представляет собой скорее искусство, а не ремесло, и не инженерию.
Автор: Виктор Амосов, аналитик компании Индиго Байт, которая разрабатывает программу для управления технической документацией.
В наше время тестировщика часто заставляют писать техническую документацию к продукту. И на это есть ряд очевидных причин. Тестировщик как никто другой знаком с функционалом ПО, знает все его тонкости, знаком со всеми проблемами и ошибками. Но тестировщик - не писатель, а документация, которую будет читать пользователь, должна быть понятна и легко читаема. Так как же написать качественную документацию, которая будет отвечать всем запросам пользователей?
Данная статья предлагает правила написания и проверки технической документации, а также инструменты, для упрощения работы "технического писателя".
Автор: Джефф Найман (Jeff Nyman) Оригинал статьи Перевод: Ольга Алифанова
Применение современных методик позволяет командам разработки раньше принимать верные решения, обращаясь с требованиями как с тестами – то есть создавая спецификации фич. Об этом и поговорим.
Возможно ли тестировать без требований? Нет! Потому что именно они определяют, что должен представлять собой тот или иной продукт, и без них он фактически не может быть создан.
Распространенные возражения, как правило, сводятся к двум пунктам:
У нас нет ТЗ, но проект-то есть, и тестирование ведется.
Мы работаем по agile — функциональный продукт важнее документации, которая бы описывала его исчерпывающим образом.
Однако в любом случае необходимо понимать, кто будет пользоваться продуктом, как он должен выглядеть, из чего состоять и какими обладать функциями. Несмотря на то что эта информация не содержится в спецификациях, в ней как раз и заключены требования к ПО. Их источником служат не составленные по всей форме документы, а знания вашей команды, имеющиеся у заказчика представления, короткие разговоры за обедом, общепринятая практика, нормативно-правовые акты, то есть всё то, что порождает так называемые неявные требования.
Можно ли протестировать техническое задание за полчаса?
Вы уже 18-й день готовите тест-кейсы на новый модуль системы. Написана не одна сотня сценариев. Вдруг обнаруживаете, что один из отчетов накладывает ограничение, которое не было нигде задокументировано. Действительно, аналитик забыл ограничить множество значений, а вам теперь переделывать 30% тестовой документации. Естественно, без возможности увеличить сроки своей работы. И как же теперь быть? Сроки поджимают, заказчик ждет результатов, нехватка времени давит со всех сторон, все злятся друг на друга. Можно ли было этого избежать? Определенно да, если уделить немного времени тестированию технической документации.
Как правило, на тестирование требований не выделяют время проекта. Но есть методы экспресс-оценки, которые позволят без больших трудозатрат выявить большую часть ошибок в требованиях — мы рассмотрим их в порядке увеличения затрачиваемого времени.
В качестве второй части ретроспективных уроков исследования я бы хотел сконцентрироваться на теме, которая редко обсуждается. Однако, с моей точки зрения, жизненно необходимо расширить свои горизонты в этой области, чтобы улучшить свой исследовательский подход.
Зачастую, когда я спрашиваю студентов, как бы они тестировали приложение, я получаю ответы вроде "Я сравню продукт с документацией или спецификацией". Логичным образом я задаю следующий вопрос – что, если спецификации нет, или продукт еще не создан?
В этой части цикла мы поразмышляем об исследовании артефактов, приносящем пользу тестированию, и разберемся, как построить тест-стратегию, имея или не имея документации, а также о том, как найти в ней баги. Иными словами, мы научимся мыслить вне рамок документации.
