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

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

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

 

 

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

Ссылка на 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 — абстрактное обозначение некоего сайта, не надо туда заходить и искать эту систему . Приводится здесь, чтобы показать ошибки в написании тест-кейсов.