Home

Автор: Джеймс Бах (James Bach)

Оригинал статьи: http://www.satisfice.com/blog/archives/1669

Перевод: Ольга Алифанова

Статья в Википедии о классах эквивалентности – это отличный пример бедности мышления, обучения и письма, который часто прокатывает за мудрость в кругах тестировщиков. Это узкое, неверно направляющее людей определение, подразумевающее, что тестирование – это такая игра, в которую мы играем с ПО, а не открытое исследование сложного феномена.

(Нет, я не буду редактировать эту статью в википедии. Я не считаю забавным или полезным предлагать свой опыт в обмен на аргументы анонимных любителей. Википедия очень важна, потому что служит всеобщей справкой, если нужно покритиковать популярное знание, но как и само популярное знание, она неисправима. Популярное всегда побеждает, а народ не особо любит размышлять).

В этой статье я прокомментирую одну часть статьи в Википедии. В следующей статье я опишу классы эквивалентности так, как вижу их я, и вы сами сможете решить, чье определение лучше – мое или Википедии.

"Классы эквивалентности – это техника тестирования ПО, которая делит вводимые данные на классы эквивалентных друг другу значений, на базе которых создаются тест-кейсы".

Не совсем. Нет никаких оснований полагать, что классы эквивалентности ограничиваются "вводимыми данными". Мыслительный процесс деления на классы эквивалентности может применяться к выходным данным, версиям продукта, тестовым окружениям, или кейсам как таковым. Классы эквивалентности применимы к чему угодно, где вариативность может повлиять на результат теста.

Автор: Джон Эндрюс (John Andrews)

Оригинал статьи: https://testingfromthehip.wordpress.com/2017/01/11/test-cases-are-evil-or-are-they/

Перевод: Ольга Алифанова

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

Перед тем как вы (и оставшаяся часть сообщества) взорветесь негодованием и гневом, пожалуйста, сядьте, налейте себе чего-нибудь холодненького, откройте свой разум новому. Попытайтесь не осуждать и понять, что контекст у каждого свой, и мы не работаем в некотором утопичном окружении. Если вам повезло и вы попали именно в такое – просто не читайте дальше, продолжайте играть в мяч со своим единорогом и экспериментировать с различными способами применения пыльцы фей.

Ряд недостатков тест-кейсов прекрасно документирован в статьях и блогах. Это обычно что-то вроде подобного списка:

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи: http://www.developsense.com/blog/2017/01/drop-the-crutches/

Перевод: Ольга Алифанова

Эта статья – адаптация моих последних твитов. По ссылкам – ответы на некоторые из ваших вопросов. Как всегда, вопросы и комментарии приветствуются.

Дополнение: в ответ на заданные вопросы, вот что я думаю про "тест-кейсы" в контексте этой статьи: тест-кейсы – это формально структурированные, четкие, процедурные, явные, документированные тест-идеи, направленные на подтверждение известного. Мое беспокойство в этом плане прямо пропорционально уровню серьезности, с которой подходят к этим вещам в определенном кейсе или тест-стратегии

Вчера у меня состоялся забавный разговор с клиентом/коллегой. Он предположил, что тест-кейсы похожи на костыли, и я с ним согласился. И добавил, что костыли регулярно навязываются людям, которые и изначально-то не хромали. Как будто перед началом футбольного матча мы раздали всем игрокам по костылю, чтобы они прихрамывали.

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

Конечно, вопрос "как там тестирование" – важная часть истории тестирования из трех частей, особенно если проблемы продукта не дают нам изучить его глубже. Но, как правило, это не та часть истории, с которой мы хотели бы начинать. По моему опыту как программного менеджера и как тестировщика, вот что волнует менеджера в первую очередь:

Есть ли в продукте проблемы, которые угрожают своевременному успешному завершению проекта?

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

Вы можете узнать о методиках, которые используют в работе более опытные коллеги, посмотрев видеозаписи докладов с конференции QA Fest 2016.

Автор: Клэр Рэклесс (Claire Reckless)

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/the-one-page-test-plan

Перевод: Ольга Алифанова

Загуглите "как написать тест-план" – и утоните в куче шаблонов, обучающих материалов, маст-хэвов и всего такого прочего. Когда дело доходит до создания тест-плана, способов его сделать миллионы, и в уме нужно держать множество вещей – очень легко запутаться. Люди часто вносят в план информацию с целью "лишней не будет" – кажется, что лучше бы ее туда включить. Может, кому-то она нужна, правда? Как только план написан, прошел ревью, исправлен, финализирован и передан всем заинтересованным лицам, часто выясняется, что его никто никогда не читал.

Мы тратим кучу времени, создавая объемную тест-документацию, которую никто не читает и не использует, и это бесит. Проблема тут в том, что у менеджмента нет времени на чтение огромных документов – они хотят знать о важных вещах.

Джеймс Уиттакер писал о Тест-плане за десять минут несколько лет назад, описывая вызов, который он бросил своей команде. Его целью было получить ценность тест-плана как можно быстрее. Давайте рассмотрим этот подход с другой точки зрения, но со схожей целью. Сложность будет не во времени, а в пространстве. Как уложить тест-план в одну страничку?

А зачем его вообще писать?

Выступление Елизаветы Батуриной на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA, весна 2013 года.

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

Кейс, с одной стороны, помогает понять, что должна делать Система, т.е., что ожидается. А с другой стороны, показывает что может сломаться в данной ситуации и как это выявить.

Основная проблема, с которой сталкиваются начинающие тестировщики: они не понимают зачем вообще нужны тест- кейсы, как правильно написать кейс и какие элементы кейса являются обязательными. Надо ли использовать определенную методологию или нет? Какой стандарт брать за основу? Как быстро и наглядно убедить заказчика, что действительно все основные сценарии проверены?

Тестирование, основанное на кейсах, является более объективным, чем исследовательское тестирование. Вторым достоинством является четкое понимание времени, которое надо на проведение тестирования.

С помощью кейсов нельзя выявить все-все ошибки, допущенные при разработке, но можно сократить их количество. В своем докладе я буду рассказывать о том, что дает использование кейсов, как можно использовать кейсы, из чего они должны состоять, как минимизировать затраты на написание кейсов и проведение проверок.

На прошлой неделе был опрос про использование инструментария для работы с тест-кейсами.

Более 150 человек приняли участие в опросе и сейчас мы подводим итоги.

Сначала диаграмма на которой представлены инструменты для работы с тест-кейсами, набравшие два и больше голосов. Все инструменты в порядке убывания голосов представлены в конце статьи.

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2016/05/30/how-much-detail-is-too-much/

Перевод: Ольга Алифанова

Примечание переводчика: автор статьи, по сути, описывает высокоуровневые чек-листы, и на сердце руку положа, в системах управления кейсами вроде TestRail они обычно так и выглядят. При этом, говоря о достоинствах подробных кейсов, он как-то совершенно упускает регрессионное тестирование. А ведь именно его часто дают новичкам, именно по нему новые люди знакомятся с продуктом, и это довольно сложно исполнить, когда кейс звучит как "пойди туда, не знаю куда" для свежего взгляда. Передаю слово автору.

В ручном тестировании очень важно контролировать, что уже проверено, а что еще нет.

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

Я видел разные форматы кейсов:

• Общие описания, как должно работать,
• Пошаговые инструкции,
• Ad-hoc тесты без инструкций.

Аргументация у этих подходов тоже различается:

• Концентрироваться надо на функциональности, а не на специфических шагах тестирования.
• Тесты должны быть просты и понятны даже уборщице Маше.
• Исследовательское тестирование лучше всего находит баги, и не надо ограничивать себя тест-кейсами.

Три этих подхода различаются уровнями детализированности. Насколько детальными должны быть наши ручные кейсы?

Автор: Джорис Меертц (https://patternsofproof.wordpress.com/)

Оригинал статьи: https://patternsofproof.wordpress.com/2015/06/02/on-the-value-of-test-cases/

Перевод: Ольга Алифанова

Подгнило что-то в Датском королевстве...

Уильям Шекспир - Гамлет

Я несколько недель наблюдал за использованием тест-кейсов в проекте по разработке ПО. Команда приступила к созданию кейсов, когда функциональные спецификации были объявлены достаточно проработанными. Кейсы были разбиты на отдельные шаги и заведены в систему управления тестами (в данном случае - в HP Quality Center). Они были проанализированы, и команда планировала приступить к их выполнению, как только продукт будет передан в тестирование.

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

Легко догадаться, что произошло потом. Когда программа была передана в тестирование, оказалось, что техническое воплощение было не таким, как предполагали тестировщики, а спецификация, приоритеты проекта и его основные задачи изменились из-за новых требований клиента. Тестировщики готовились обороняться от вооруженной копьями пехоты - а столкнулись с гаубицами. Конечно, им пришлось отступить.

В своей новой статье Наталья Руколь, автор и ведущая Школы Тест-Аналитика, рассказывает о самой сложной части тест-анализа: отказа от тестов по причине нехватки времени. Как, когда, какие?

Тяжкая миссия тестировщика

Какая самая главная задача тестировщика? Какой навык является наиболее ценным для хорошего тестирования?

Начинающие тестировщики обычно считают, что их главная задача - придумать как можно больше тестов:

• Что может влиять на выполнение той или иной операции?

• При каких значениях всё может сломаться?

• Как “положить” систему?

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

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

• чёткое разбиение на классы эквивалентности и доменный анализ,

• комбинаторику значений параметров действия,

• pairwise и triplewise

• и т..д.

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

И именно здесь - ступень для перехода на следующий уровень экспертизы и мастерства. В дело вступает реальность: в большинстве случаев провести достаточное количество тестов невозможно. “Спасибо, что вы столько тестов придумали, но продукт мы отдаём в тестирование сегодня вечером, а релиз должен состояться завтра”.

У некоторых тестировщиков такая ситуация вызывает постепенную демотивацию: мы не можем протестировать всё! Но просветлённые тестировщики смотрят на ту же проблему под другим углом: “отлично! вот это challenge! мне надо придумать, как протестировать это всё действительно быстро!”. А чтобы протестировать в сжатые сроки, от каких-то тестов придётся отказаться. Каждый из них может найти потенциальный дефект, и получается, что, отказываясь от проведения того или иного теста, мы повышаем вероятность пропуска дефекта. Насколько критичного? Зависит от теста, которому мы говорим “прости и прощай, но не в этот раз”. И получается, что главная задача тестировщика в этом случае - выбрать, какие тесты мы не будем проводить. Не будем тестировать, Карл!