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