Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой статье я хочу ответить на вопрос, заданный мне в LinkedIn Полом Сименом (Paul Seaman). Он спросил, что я думаю о документировании автоматизированных тест-кейсов как способе продемонстрировать, что автоматизация вообще делает.

Краткий ответ: я не определился.

Это, конечно, не очень-то полезный ответ, да и статья вышла бы странно короткой – постараюсь развить свою мысль.

Автор: Зубов Вадим QA специалист IT компании Intelsy

С техническим заданием, и в частности с требованиями, лично я имею дело постоянно, поэтому собрал полезную для начинающих и продолжающих специалистов информацию по требованиям к IT-продукту,  их видам, техникам и метрикам тестирования требований. На эту инфу стоит ориентироваться не только аналитикам и тестировщикам, но и остальным членам команды.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Одна из причин глобальных проблем разработки и тестирования в том, что люди небрежно обращаются со словами.

Джерри Вайнберг очень любил подчеркивать, что «плавающая точка» - это математика, где точка остается на месте, а «фиксированная точка» - ситуация, когда точка двигается. Люди говорят о «внесерверной обработке данных», на самом деле подразумевая «обработку данных на чьих-то еще серверах». «Бескодовые инструменты тестирования»… ну, код есть всегда; просто это код, который писали не вы.

Вот еще термин, над которым никто не задумывается: нефункциональные требования.

Автор оригинала: Paul Gerrard
Перевод: ProQuality Community, телеграмм

Добро пожаловать в серию статей "Лидерство в тестировании" от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы — особенно в гибких командах — преуспеть в своих ролях руководителя тестирования и менеджера по управлению. 

Независимо от того, какой это проект, организация или подход, всегда найдется место для документации. Хорошая документация — это находка, предоставляющая полезную информацию о подходах, масштабах, планах, конструкциях и результатах анализа, разработки и тестирования.  

В этой статье я расскажу о: 

• Ценности документации 

• Опасности шаблонов и вырезания/вставки готовых шаблонов 

• Типы тестовой документации 

• Консультации по проектной документации   

Оригинальная публикация

Как быть тестировщику, если на проекте нет аналитика и спецификации? Маша Кузнецова, младший QA-инженер red_mad_robot, рассказывает о трёх возможных вариантах действия — осторожном, умеренно рискованном и максимально упоротом. Будет особенно полезно QA начального и среднего уровня — чтобы не растеряться, попав в похожую ситуацию.

Автор: Денис Бесков

Введение

Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.

Это та причина, по которой многие подрядчики стараются избегать таких требований, как огня, что перекладывает риски во времени на более поздние этапы и на заказчика.

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

Пока что умение специалистов и команд выявлять и формулировать такие ограничения представляет собой скорее искусство, а не ремесло, и не инженерию.

Давайте попробуем сделать это хотя бы ремеслом.

Автор: Виктор Амосов, аналитик компании Индиго Байт, которая разрабатывает программу для управления технической документацией.

В наше время тестировщика часто заставляют писать техническую документацию к продукту. И на это есть ряд очевидных причин. Тестировщик как никто другой знаком с функционалом ПО, знает все его тонкости, знаком со всеми проблемами и ошибками. Но тестировщик - не писатель, а документация, которую будет читать пользователь, должна быть понятна и легко читаема. Так как же написать качественную документацию, которая будет отвечать всем запросам пользователей? 

Данная статья предлагает правила написания и проверки технической документации, а также инструменты, для упрощения работы "технического писателя".

Автор: Мария Кедемо (Maria Kedemo)
Оригинал статьи
Перевод: Ольга Алифанова

Я часто слышу, что люди говорят о тестировании, как о валидации и верификации требований. Но тестирование – это намного более широкое понятие.

Фокусируясь на верификации и валидации, мы, скорее всего, будем искать и найдем только то, что мы ищем. Это встроено в само определение этих слов.

Согласно Оксфордскому словарю,

Верификация – это "Убедиться или продемонстрировать, что (нечто) верно, точно или оправдано".

Валидация – это "проверить или доказать валидность или точность чего-то".

Автор: Джефф Найман (Jeff Nyman)
Оригинал статьи
Перевод: Ольга Алифанова

Применение современных методик позволяет командам разработки раньше принимать верные решения, обращаясь с требованиями как с тестами – то есть создавая спецификации фич. Об этом и поговорим.

Автор: Виктория Соковикова, тренер курса «Тестирование без требований: выявление и восстановление информации о продукте»

Возможно ли тестировать без требований? Нет! Потому что именно они определяют, что должен представлять собой тот или иной продукт, и без них он фактически не может быть создан.

Распространенные возражения, как правило, сводятся к двум пунктам:

• У нас нет ТЗ, но проект-то есть, и тестирование ведется.
• Мы работаем по agile — функциональный продукт важнее документации, которая бы описывала его исчерпывающим образом.

Однако в любом случае необходимо понимать, кто будет пользоваться продуктом, как он должен выглядеть, из чего состоять и какими обладать функциями. Несмотря на то что эта информация не содержится в спецификациях, в ней как раз и заключены требования к ПО. Их источником служат не составленные по всей форме документы, а знания вашей команды, имеющиеся у заказчика представления, короткие разговоры за обедом, общепринятая практика, нормативно-правовые акты, то есть всё то, что порождает так называемые неявные требования.