Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Тест-анализ и тест-дизайн
Как писать план тестирования: что важно не забыть, и с чего начать?
07.12.2018 00:00

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

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

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

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

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

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

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

Подробнее...
 
Какие тест-кейсы стоит автоматизировать?
04.12.2018 11:22

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

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

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

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

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

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

Подробнее...
 
Подсчет тест-кейсов
19.11.2018 12:06

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

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

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

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

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

Подробнее...
 
Тест-план в одну страничку
19.10.2018 11:03

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

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

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

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

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

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

Подробнее...
 
Проектируя тесты: в чем разница между хорошим и плохим тестом?
31.07.2018 12:04

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

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

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

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

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

Подробнее...
 
Расширяем тестирование граничных значений
05.12.2017 10:52

Автор: Юлия Миронова, ведущий специалист компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/extend-testing-of-boundary-values/

Самый первый метод тест-анализа, который каждый начинающий тестировщик постигает инстинктивно, – это метод граничных значений. Но так ли он прост, как это кажется на первый взгляд? Давайте разберемся!

Для сравнения разных подходов возьмем конкретный пример. Пусть у нас на сайте есть форма предварительного расчета стоимости страховки жизни, базирующаяся на очень простой формуле. Клиент вводит возраст и сумму в рублях, на которую он хочет застраховать свою жизнь. Если клиент моложе 18 лет или старше 60, выводится сообщение: «К сожалению, на данный момент у нас нет для вас подходящих предложений». Во всех остальных случаях мы просто считаем процент от введенной суммы; этот процент равен возрасту клиента. Да, я знаю, что в реальности расчет будет гораздо сложнее, но для наших целей такая модель подойдет.

Подробнее...
 
Мнемоника БМВ и ее применение: доклад Ольги Назиной на SQA Days 21
27.10.2017 11:20
Мнемоники помогают взглянуть на свой проект под новым углом или не забыть важные проверки.

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

Запись выступления Ольги Назиной на SQA Days 21 с докладом Мнемоника БМВ и ее применение
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения- SQA Days-22, Санкт-Петербург, ноябрь.

Как обычно для читателей нашего портала действует промокод на получение 10% скидки.

Промокод для получения 10% скидки - s-t.ru

Обсудить в форуме
 
Тест-аналитики – кто это?
17.07.2017 17:44

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

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

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

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

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

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

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

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

Подробнее...
 
Кто такие тест-дизайнеры и зачем они нужны
07.04.2017 08:21

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

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

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

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

Подробнее...
 
Переосмысление классов эквивалентности, часть 1
01.03.2017 11:31

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

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

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

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

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

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

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

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

Подробнее...
 



Страница 1 из 5