Home

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

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5

В прошлый раз мы остановились на вопросе "Как сфокусировать работу тестировщика, который уже что-то знает о продукте, не переусердствовав в этом?"

В четвертой части этой серии статей я уже предлагал ряд примеров. Вот еще один: сценарное тестирование. Примеры, приведенные здесь, основаны на работе, проделанной несколько лет назад Джеймсом Бахом и Джорди Киттом (позднее я помогал ряду других организаций внедрять этот подход, но они не согласились делиться деталями).

Идея тут в использовании сценариев, направляющих тестировщика на пути исследования, экспериментирования и получения опыта на продукте. Все это должно давать ему идеи о реальном использовании и о том, как продукт можно использовать неправильно. Приятно верить, что тщательно проработанный дизайн, юнит-тесты, BDD и автоматические проверки предотвратят баги продукта – и они, безусловно, помогают в этом деле – но, перефразируя Гертруду Штайн, опыт учит опыт учит опыт. Простите за выражение, но если вы хотите найти проблемы, с которыми люди могут столкнуться при использовании продукта, то использование этого чертова продукта может, знаете ли, помочь!

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Тестируя вывод, нужно думать о трех основных моментах:

Как отображается результат?

Отличным примером результата, внешний вид которого стоит проверить – это телефонный номер. Когда пользователь добавляет телефонный номер в базу данных вашего приложения, то этот номер (я надеюсь) сохраняется без любых скобок, точек и дефисов. Однако при отображении телефона для пользователя вы, возможно, не захотите выводить его как 8008675309 – это тяжело читается. Вы предпочтете, чтобы номер форматировался так, как этого ожидает пользователь. Для пользователей из США номер будет отображаться как 800-867-5309 или (800) 867-5309.

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

Часть 1
Часть 2
Часть 3
Часть 4

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

В курсе Rapid Software Testing мы говорим, что тестирование – это оценка продукта путем его изучения через эксперименты и исследования, включая вопросы, моделирование, обучение, манипуляции, вмешательства, и т. д. Обучение – неотъемлемая часть тестирования. Тестировщики могут взаимодействовать с множеством артефактов и людей, чтобы начать изучать продукт, и это мы уже обсуждали. Давайте разберемся, почему идея заставить тестировщика работать посредством тест-кейсов не так уж хороша.

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

В конце этой статьи я попробую подобрать интересные и полезные ссылки про эвристики.

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

Часть 1
Часть 2
Часть 3

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

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

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

Часть 1
Часть 2
В прошлый раз "Фрида", моя клиентка на тренинге, спросила про разработку тест-кейсов для аудиторов и контролирующих органов. В курсе Rapid Software Testing мы считаем полезным называть это формализованным тестированием.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Что, если они захотят, чтобы другой человек прогнал мои тесты, если я недоступна?

- Ваши тесты, или ваше тестирование? – спросил я.

- Насколько я понимаю, мои тесты. Я несогласна с этим, но пытаюсь посмотреть на вопрос с их точки зрения, - ответила Фрида.

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

Недавно на моем тренинге тестировщица никак не могла разобраться в одном вопросе. Вот о чем она спросила:

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

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи: http://www.developsense.com/blog/2018/06/test-cases-and-coverage/
Перевод: Ольга Алифанова.

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

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

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