Home

Автор: Специалист по тестированию компании "Лаборатория качества" Антон Алексеев

Оригинальная публикация: http://quality-lab.ru/test-analysts-who-is-this/

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

Я предлагаю читателю составить мне компанию и посмотреть, чем в течение дня занимается тест-аналитик (в мои обязанности входит работа не только тестировщиком, но и тест-аналитиком). Итак, добро пожаловать в мир аналитики!

Как выглядит мой обычный день в роли тест-аналитика

Утром мне на почту приходит письмо от заказчика с данными для получения дистрибутива продукта и формальными требованиями к нему. Плохие новости – технического задания как такового у нас нет. Хорошие новости – представитель заказчика оказался открытым к общению молодым человеком.

Что же нам за сегодня предстоит сделать? Исходя из определения, тест-аналитик – это член команды тестирования, основная задача которого определить «ЧТО тестировать?» Для этого мне необходимо выполнить следующие действия:

• исследовать продукт;
• составить логическую карту продукта;
• разбить программный продукт на составные части;
• расставить приоритеты тестирования.

Автор: Антон Алексеев

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

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

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

Автор: Джеймс Бах (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 человек приняли участие в опросе и сейчас мы подводим итоги.

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