Я начинающий тестировщик. Сейчас устраиваюсь на работу. В ответ на резюме, отправленное в одну из компаний, мне пришло предложение выполнить тестовое задание, которое заключается в том, чтобы найти как можно больше issues на бета-версии сайта. В ответ от меня ожидается issue document. Погуглив, я обнаружил несколько template’ов issue document, однако мне не совсем понятно, что с ними делать (а точнее, практически, совсем не понятно) 🙂

Пожалуйста, подскажите, как лучше составить этот самый issue document(я имею в виду в основном оформление, есть ли какие-то стандарты?), чтобы произвести хорошее впечатление на HR отдел компании. Да, чуть не забыл. На все про все у меня всего пару дней. Очень прошу, не медлите с ответами.

Ну, прям, не медлить…

Тут есть о чем помедлитировать.

Налейте мне еще коньяку «Chisinau», бо я сегодня разочаровался в Johnny Walker Red Label, и мне нужна реабилитация.

Если нет «Chisinau» — достаньте его где угодно, не грузите меня подобными мелочами.

Проблема только в том, что меня не спрашивали.

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

Уважаемый сэр молодой тестировщик,

ежели вы так хотите произвести впечатление на HR (она после этого потребует взять ее замуж, вы к этому готовы?), тогда вам следует знать, что слово «Issue» на языке Вильяма сукина сына Шекспира означает «вопрос, который надо обсудить«. Односложно на русский язык это слово перевести сложно, поэтому большинство произносит его как «ишшу».

Например, в рулезнейшем баг-трекере Mantis каждая запись называется issue. Баг там записан, или задача, или вопрос — это все issues.

Они вам предложили просто, весело, задорно и бесплатно протестировать их приложение, и предоставить им максимально большой список багов.

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

Шаблон такой:

1. Сделать это.

2. Сделать то.

3. Сделать то-то.

[…] сделать то-то и это-то.

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ

Такой-то.

ПРОБЛЕМА

Происходит то-то и сё-то.

Скриншот прилагается.

Запомните как гамму до минор на контрабасе: баг без скриншота — что фильм «Кавказская пленница» без спортсменки, комсомолки, и как ее там звали (уже забыл).

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

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

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

Если вы нашли баг в предыдущей фразе — позвоните нам по телефону 555 28 16 88, спросите Джонни из ФБР.

Количество шагов для воспроизведения в описании бага зависит от того, насколько вы уперты и талантливы. Чем меньше, тем лучше, кагбэ…

В принципе надо понимать, что описание бага будет кто-то читать, и по указанным вами шагам будет пытаться воспроизвести описанную вами проблему. Если описание правильное — вам зачтется в другой жизни. Если описание неправильное, запутанное, сложное и неоднозначное, то — «ваши рыжие кудри примелькаются», к вам придут домой, и вас будут бить, Шура. Ибо описывать баги надо просто и однозначно, а не «как все».

2)

С другой стороны, подобное «домашнее задание» вызывает у меня крайнее подозрение. Вот такой я крайне подозрительный.

Понимаете, мне кажется, что «домашнее задание» должно показать, как вы ВООБЩЕ умеете думать в области «поиска багов», а не требовать список багов.

Мне кажется, что даже если вы продадите мне вашу душу вместе с вашими штанами, и найдете в ихней* бета-версии сайта сто сотен тыщ багов, то вам все равно скажут, что вы не подходите.

* Да, я знаю, что в русском языке нет слова «ихней».

Зато есть химический элемент «ихний» — его скоро должны открыть, это принесет в казну много элементов типа argentum.

Зато все ваши баги будут с вниманием рассматривать и радоваццо, что нашелся божий человек, калик перехожий, коий нам столько багов накатал, дай ему, Ивану-дураку-царевичу, бог здоровья, гей он еси молодец…

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

А почему?

А потому, что работа тестировщика (прошу стать прямо и включить мозг) не заключается в поиске багов.

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

Просто В ОБЩЕМ самым заметным результатом работы тестировщика является сборник багов, поэтому нормально, если окружающие так считают.

Пусть считают, делов-то.

Хуже, когда дело доходит до «Я тут нашел баг, а ведь это твоя работа, баги находить…«

Если в компании считают, что количество багов — показатель крутости тестировщика, то компания, скорее всего, небольшая, только-только начинает развиваться, и расти там (вы же мечтаете о карьерном росте до программиста, не так ли? Не врите, поначалу все об этом мечтают, это нормальное животное человеческое желание) вам не придется ни ввысь, ни вширь, ни вглубь.

И в мире станет на одного ненавистника профессии тестирования больше. А я в таком мире жить не хочу.

Конечно, певца при приеме на работу попросят спеть, кулинара — приготовить, путану — мгм, дизайнера — нарисовать, программиста — написать код. Если всё это правильно, тогда и тестировщика надо попросить при приеме на работу найти баги 🙂 Логика просто нерушимая, как СССР, который, как вы помните, разрушился ко всем чертям.

Но все это должно быть сделано как пример, а не как «у нас тут есть вот работа, сделай её, и мы решим, брать ли тебя, или нет, гыгыгы«.

Вам же предложили не решить пример, а сделать работу. «Найти как можно больше issues на бета-версии сайта» — я это воспринимаю именно так.

Если у вас есть возможность еще поискать работу — поискайте её ещё.

3)

Искренне рекомендую следующее:

1. Все-таки протестировать предложенное приложение и постараться найти там как можно больше багов. Просто для самоуважения. Список этот можете себе на стену повесить — он ваша интеллектуальнейшея собственность.
2. Забить на мечту о работе в той крутейшей компании.
3. Продолжать искать работу.
4. Найти работу, на которой работают правильные люди.

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

1. Вот приложение. Вот в нем есть такая-то функциональность.
2. Вот какие к этой функциональности предъявляются требования (вам кладут на стол список требований, или, может быть, краткое описание задач, которые выполняет этот функционал).
3. Пожалуйста, расскажи, как ты это дело будешь тестировать. Какие есть идеи, на какие аспекты ты обратишь внимание в первую очередь, а на какие забьешь болт, с чего начнешь и когда намереваешься завершить тестирование, где и как будешь искать информацию о тестируемой теме, и где ты возьмешь болт, чтобы им забить, если надо будет забить, как уже говорилось…
4. Не нервничай и не сучи ножками — тут все когда-то сидели точно так же, как и ты, и думали, думали, думали. Ты тоже думай.

Ну, а когда найдете себе работу с правильными людьми, вернитесь к той самой HR-отдел (цветы прихватите, а не только банку пива) и скажите ей все те комплименты, которые вы хотели сказать, но постеснялись.

Вдруг это ваша судьба?

Вот что я сказал бы, но проблема в том, что меня об этом не спрашивают.