ТМ-кейс: скучно писать автотесты

Помидорка - это техника, которая позволяет концентрироваться на одном деле 25 минут. Я уже писала о ней ранее, оставляя отзыв на книгу Нётеберга.

И сегодня очередное восхищение этой техникой!

Поставила я задачу на написание автотестов по типовым правилам. Посмотрела в соседние проекты и расстроилась - накопипастить неоткуда, придется писать самой. Зато потом можно будет использовать не только тут!

Первый набег был самый плодотворный, я накидала основу.

А потом интерес к задаче как-то угас. Масштабы задачи немного пугали, срочность низкая... За последние пару дней результатов у меня почти не было.

В понедельник я занималась другими делами, более важными и срочными (которым была очень рада, надо сказать!), изредка посматривая на задачку и грустно вздыхая.

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

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

Вечером задумалась. Мне казалось, что, собравшись с духом и не отвлекаясь, я могла бы уже закончить эту задачу, еще бы и время осталось! А тратить слишком много времени тоже плохо... Пора закругляться!

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

И вы знаете? Опять сработало! Я просто поражаюсь эффективности этой методики! Конечно, первые 2 тайминга было тяжеловато. Задачу делать не хотелось, а скайп так призывно моргал новыми сообщениями... Но нет, жди перерыва!

Зато потом... Потом я втянулась! И если вчера задача вызывала чуть ли не отвращение и ворклог был однозначно "не интересно", то сегодня это было даже местами увлекательно! А на "нудных" местах, когда я уже определила стратегию ("тебе надо записать по 4 кейса для этого типа, 4 для того и так далее") и осталось только "сесть и сделать", я включала себе тихую песенку и выполняла единообразную работу без усталости и раздражения.

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

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

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

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

The Art of Software Testing. Гленфорд Майерс

Она же "Искусство тестирования программ" в русском переводе.
Ссылка на OZON.

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

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

Мне понравилось то, что в книге есть примеры, иногда простые и понятные, иногда запутанные и сложные, но есть! Мне понравилось то, что в третьем издании книга стала более современной, туда добавились главы о тестировании удобства использования и мобильных приложений, это круто! Поэтому, если и покупать, то только третье издание (или позднее).

Перед тем, как начать читать книгу, автор предлагает пройти простенький тест. Да да, то самое тестирование треугольника, о котором много наговорено! И тем не менее, этот тест не проходят даже люди с опытом работы, что уж говорить о начинающих?

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

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

Еще у него хорошо описан главный вопрос тест-дизайна и проектирования тестов:

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

Вообще глава про проектирование тестов мне очень нравится. Хорошие примеры, важные пометки "на что обратить внимание, где еще может сломаться", хотя бы ради нее могу порекомендовать книгу! Да, это не "вау, must read", но тоже вполне любопытно.

А при анализе ошибки важно понимать ответы на следующие вопросы:

1. Где была допущена ошибка?
2. Кто допустил ошибку?
3. Какова причина ошибки?
4. Как можно было предотвратить ошибку?
5. Почему ошибка не была обнаружена раньше?
6. Каким образом ошибку можно было обнаружить раньше?

Конечно, эти вопросы нужны не для того, чтобы наказать виноватого, а для того, чтобы улучшить процессы, это очень важно!

А еще Майерс хорошо пишет о говнокоде и о самом сложном при разработке и анализе ошибок - об умении думать.

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

PS - Добавила книгу в общий список прочитанных мною книг.

Интервью для Факабы!

А я тут вчера дала интервью Факабе, самому крупному новостному агрегатору и информационному ресурсу о системе менеджмента качества, обеспечении качества и тестировании ПО в Беларуси! 

Почитать его можно, пройдя по ссылке.

 

 

Искусство обучать. Джули Дирксен

Ссылка на OZON.
Отзыв Натальи Руколь.

Чумовая книжка!

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

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

Пожалуй, теперь придется купить специальные стикеры-закладки и обклеить книжку ими... А еще в некоторых местах я просто подскакивала с места, когда меня озаряла ИДЕЯ! Все внутри бурлило и кипело и уже за одно это я благодарна этой книжке и считая, что прочитала ее не зря.

Где начинающим тестировщикам получать опыт?

Все начинающие тестировщики задаются вопросом - где набраться опыта? Где применять полученные знания? А ведь способов то много!

1. Работаем за еду, то есть за опыт

Самый лучший способ получения опыта - устроиться на работу. Но так как это "привет, капитан очевидность", то данный пункт будет явно не в начале списка. На работу ведь не берут как раз из-за отсутствия опыта. Что же делать?

Можно работать бесплатно, получая опыт и проходя обучение на реальном проекте. Такие проекты, как правило, open source и времени просят всего по 6+ часов в неделю. Можно совмещать с основной работой, получая драгоценный опыт и не теряя свой заработок.

Open source проект, которому нужны тестировщики - полезная ссылка.
Хомячки — проект, направленный специально на получение опыта начинающими.

Бесплатная практика в тестировании — тема на форуме, которая пополняется ссылками, там сейчас как раз open-source проект и «Хомячки».
Теория и практика для студентов — бесплатная школа в Питере, очная.

А еще можно написать в телеграмм Галине @qait007. Она работает как фрилансер и у нее бывают задачи для стажеров вида «проверить на таком-то телефоне». Вы тестируете, получаете фидбек и опыт. Ну а если хорошо себя покажете, то есть шанс самому начать зарабатывать на фрилансе =)

Регистрация по EMAIL

Нерушимое правило

Тестировщикам, особенно начинающим, важно всегда помнить следующий принцип:

Никогда не используйте "левые" email'ы для тестирования.

Не должно быть вымышленных email'ов или email'ов, которые не принадлежат вам, если система рассылает по ним почту. Потому что вы один раз зарегистрировались, а система будет слать туда письма.

Допустим, форма регистрации следующая:

Чтобы ее протестировать, надо ввести N уникальных значений почты:

• Можно ли оставить имя пустым?
• Можно ли ввести "Ольга"?
• А "Олечка"?
• А "Olga"?
• А "Киселева-Иванова Раисия Ивановна"?
• А "%:;*Ц;(*;?%"?
• А можно ли создать пароль в 1 символ?
• А можно ли ... ?

Статья не о принципах тест-дизайна, поэтому остановимся на данном списке. Но понятно, что он будет больше раз в 10. И каждый раз регистрировать новый email? Да ну-у-у-у... Если формат эл. почты не проверяется, можно и "123" туда записывать, пока тестируются другие поля. А если проверяется, то "123@mail.ru".

Чем это плохо?

1. Система на каждый такой "левый" адрес высылает почту, то есть фактически спамит mail.ru по несуществующим адресам. Mail.ru банит такого отправителя как злостного спамера. А менеджер проекта уже отрывает руки тому вредителю, благодаря которому их занесли в черные списки. Вы же не хотите быть таким вредителем, правда? 
2. Тексты писем, которые отправляются пользователям, тоже надо тестировать. Если все время вбивать в поле всякую фигню, почту мы в итоге не получим и не сможем ее проверить.

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

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

Но, если вы не знаете точно, есть такое или нет - следуйте правилу, не указывайте "левые" email`ы!

А что же тогда делать?

Страдать!

На самом деле не надо страдать, есть выход 

И даже не надо каждый раз заводить новую почту!

У gmail есть хинт - берете свою почту и добавляете к ней часть с плюсиком.

Например, myMail@gmail.com - это моя почта, так вот

• myMail+1@gmail.com
• myMail+2@gmail.com
• myMail+10@gmail.com
• maMail+test@gmail.com

будет приходит на myMail@gmail.com.

Пользуйтесь на здоровье и берегите нервы своих менеджеров! 

PS - Уже скоро стартует мой курс "Онлайн-интенсив для начинающих тестировщиков", в котором мы будем злыми менеджерами, отрывающими головы за невыполнение этого правила  Записаться на курс 1-7 сентября.

Что такое тест-кейс и как его писать

Тест-кейс — это проверка. "Выполни тест-кейс по вводу отрицательных значений" = проведи проверку такую-то и проверь, что результат будет такой-то.

См также: Тест-кейс проверяет, а не доверяет!

Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.

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

Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план —  это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)


Стандартные атрибуты тест-кейса

1. Номер —  уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
2. Название — краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко.
3. Предварительные шаги —  описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется.
4. Шаги — описание действий, необходимых для проверки (например, создание элемента).
5. Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов ("Элемент создан").

См также:
Правила написания предварительных шагов в тест-кейсах — подробнее про пред шаги

Вложил в тест-кейс аттач? Поясни его! — и про вложения

Пример оформления (один ожидаемый результат)


Есть внутренний сайт компании, которая проводит интернет "Самый_лучший_в_своем_роде" — www.test.ru. Тестовый стенд, на котором проверяются доработки перед выкладкой в PROD (он же production, окружение для пользователей) находится по другому адресу — www.dev_test.ru.
Примечание: www.test.ru — абстрактное обозначение некоего сайта, не надо туда заходить и искать эту систему . Приводится здесь, чтобы показать ошибки в написании тест-кейсов.