пятница, 15 августа 2014 г.

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

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

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




вторник, 12 августа 2014 г.

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

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

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

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

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


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

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

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


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


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

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

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

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

понедельник, 11 августа 2014 г.

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


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

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

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

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

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


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

  • Можно ли оставить имя пустым?
  • Можно ли ввести "Ольга"?
  • А "Олечка"?
  • А "Olga"?
  • А "Киселева-Иванова Раисия Ивановна"?
  • А "%:;*Ц;(*;?%"?
  • А можно ли создать пароль в 1 символ?
  • А можно ли ... ?
Статья не о принципах тест-дизайна, поэтому остановимся на данном списке. Но понятно, что он будет больше раз в 10. И каждый раз регистрировать новый email? Да ну-у-у-у... Если формат эл. почты не проверяется, можно и "123" туда записывать, пока тестируются другие поля. А если проверяется, то "123@mail.ru".

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

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

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

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

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

Страдать!


На самом деле не надо страдать, есть выход Smile :)
И даже не надо каждый раз заводить новую почту!


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

Например, myMail@gmail.com - это моя почта, так вот
  • myMail+1@gmail.com
  • myMail+2@gmail.com
  • myMail+10@gmail.com
  • maMail+test@gmail.com
будет приходит на myMail@gmail.com.

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

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

четверг, 7 августа 2014 г.

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

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

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

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

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