Поздравляем Ольгу с окончанием испытательного срока!

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

****************************************************************

У меня официально закончился испытательный срок! (Ждала этой даты, чтобы не накаркать). IT-отдел из 10 человек внутри большой компании. Я – единственный тестировщик в фирме. Так что “Мне только спросить!” или “А как это делали у вас раньше?”, всё самой-самой.

Сначала фактический результат в баге, потом ожидаемый

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

Шаги
Делаем то, делаем се 

Ожидаемый результат
Все работает круто!    ---  о_О 

Фактический результат
Все плохо :(

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

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

Как ввести в контекст вопроса

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

Просто если вы общались недавно, введение будет кратким:

— Так, насчет логов по задаче TEST-8…

Все, собеседник уже понял, что речь пойдет про задачу TEST-8 и логи в ней. А так как вы недавно ровно это и обсуждали, то он быстро понял, о чем речь и смог поддержать разговор.
А вот если вы вбежали в комнату и продолжили свою мысль:

— Что мне делать с NPE?

То разработчик посмотрит на вас вот так: о_О

CamelCase, snake_case и другие регистры

CamelCase (с англ. — «ВерблюжийРегистр») — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово внутри фразы пишется с прописной буквы. Стиль получил название CamelCase, поскольку прописные буквы внутри слова напоминают горбы верблюда.

Обычно используется внутри кода для названия переменных.

snake_case (с англ. — змеиный_регистр) — стиль написания составных слов, при котором несколько слов разделяются символом подчеркивания (_), и не имеют пробелов в записи, причём каждое слово обычно пишется с маленькой буквы — «foo_bar», «hello_world» и т. д.

Заполняем версию в баге

Это может быть одно поле, может быть несколько:

• Проявилось в версии;
• Исправить в версии;

Проявилось в версии

Вы каждые N недель выпускаете новую версию продукта: версия 1, 2, 3, 4, 5... Каждая версия чем-то отличается от прошлой (а иначе зачем она нужна?). Добавлен новый функционал, исправлены ошибки...

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

Как нарисовать карту приложения (mind map)

Мы (тестировщики) рисуем карты для того, чтобы показать их коллегам. Чтобы новичков по ним знакомить с проектом. Или чтобы показать аналитику для уточняющих вопросов «а я правильно понял, что...»?

Давайте разберемся, как нарисовать Mind Map по проекту. И как сделать карту простой и понятной. А, главное — нужной!

1. Изучите ваше приложение

Прочитайте ТЗ. Задайте вопросы аналитику. Да просто потыкайте систему и посмотрите, что она умеет. 

Статьи в помощь:

• Зачем вообще нужны программы
• Сколько вопросов задавать по ТЗ
• Открытые и закрытые вопросы

2. Выделите основные функции 

Задайте себе вопросы:

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

Мы начинаем рисовать с основных сценариев. А потом детализируем их, и дополняем карту второстепенными сценариями. 

Поздравляем Олесю с первой работой!

У нас в чатике одной из школ появилась новая success-story от Олеси!

******************************************************************

После курсов сразу стала отправлять резюме на должность junior qa. Как и советовали смотрела не только вакансии где ищут без опыта, но отправляла и туда, где опыт 1-3 года.

Отправила резюме примерно в 5 фирм (с сопроводительным письмом). Ответили мне 3. С одной вели переписку по почте, но они почти сразу сказали, что не готовы брать тестировщика без опыта. В двух других прошла собеседования с  HR, сделала тестовые задания (это были задания написать тест кейсы и чек листы), потом тех. собеседование.