Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Ричард Патерсон (Richard Paterson)

Оригинал статьи

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

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

Писать тест-план или не писать – вот в чем вопрос! Этот вопрос регулярно поднимается в обсуждениях на Software Testing Clinic. Положительный ответ на этот вопрос, в свою очередь, породит множество новых вопросов. Вот некоторые из них, которые стоит задать себе или команде:

• В какой форме тест-план должен быть?
• Какую информацию он должен включать?
• Для кого он предназначен?

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

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

Оригинал статьи

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

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

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

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

Автор: Маарет Пиаярви (Maaret Pyhäjärvi).

Оригинал статьи

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

Сознаюсь в страшном: я считаю тест-кейсы. Прежде чем возмущаться, читайте дальше. Я считаю кейсы с целью понять, сколько у нас чего где в наличии. Вот пример таких подсчетов – "30 тест-кейсов автоматизированы", чтобы понимать, сколько концептуальных программных частей у нас есть, или "добавлено 100 строк функциональности, а количество юнит-тестов не изменилось". Подсчеты довольно полезны, но ими дело не ограничивается.

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

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

Оригинал статьи

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

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

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

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

Автор: Марк Уинтерингэм (Mark Winteringham)

Оригинал статьи: http://dojo.ministryoftesting.com/lessons/designing-tests-what-s-the-difference-between-a-good-test-and-a-bad-test

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

Вопрос «Что именно делает тест хорошим или плохим» задавался недавно не только в Software Testing Clinic, но и на моих личных воркшопах. Я не думаю, что «хорошие» или «плохие» тесты в принципе существуют. Если я прогоняю простейший поверхностный тест и он находит баг, помогает мне сформулировать новую идею или вскрывает новую полезную для меня информацию – это хороший тест. При этом это не означает, что я могу полагаться исключительно на простые или поверхностные тесты.

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