Упоминается Роман Савин, бо совместно листали его замечательную книгу «Тестирование дот ком» в попытке узнать, что такое тест-дизайн, и не нашли 🙁

Я начинающий тестировщик. Сейчас устраиваюсь на работу. В ответ на резюме, отправленное в одну из компаний, мне пришло предложение выполнить тестовое задание, которое заключается в том, чтобы найти как можно больше 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-отдел (цветы прихватите, а не только банку пива) и скажите ей все те комплименты, которые вы хотели сказать, но постеснялись.

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

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

В целом «народное» мнение на эту тему можно сбилдить таким образом: «Зачем нужны тестировщики, и можно ли их всех запихнуть в одну ракету и направит ее в недра планеты Земля? И если да, то когда ближайший рейс?«

Кагбэ, да, но…

Роль тестировщиков в программистском быту

В проекте по софтразработке тестирование — такая же нудная и скучная работа, как и программирование, обработка счетов и подметание офиса.

Это просто работа, которую надо сделать.

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

Почему тестированием занимаются тестировщики, а не сами программисты?

Тестировщик — самый дешевый и удобный эмулятор конечного (не путать с «конченным») юзера.

Работа тестировщиков стоит дешевле, поэтому тестируют — тестировщики, а не программисты.

Не будет тестировщика — эту работу должен будет сделать программист. Или менеджер проекта. Или клининг-менеджер (читаем от английскаго слова «clean» > чистота, а не от слова «клиника»).

На полном серьезе на форуме тестировщиков рассматривается вопрос «Должны ли сами программисты тестировать?«

Да, если речь идет об атомарном тестировании всего того, что они ваяют.

Может быть, если речь идет о той части, которую будет видеть пресловутый «конечный пользователь».

Однако тема растянулась на две полновесные страницы…

В общем, тестировщик — это роль в проекте.

Если нет проектной возможности, то эту роль исполняет кто угодно, как правило, сам программист или же пользователи. Есть целая стратегия, тестировать «на людях» и править ошибки по мере их накопления.

Если есть возможность, то эту роль исполняет отдельный человек. Например, Bruce Willis или сам Чак Норрис, — и баги в замешательстве разбегаются до того, как их напишут.

Почему тестировщик ценится дешевле программиста?

Идеальный ответ: Потому, что вас много, а мы — одни 🙂

Потому, что без тестировщика программу можно сделать и продать/использовать. Сам по себе тестировщик без работы программиста не ценнее набора скрепок.

Собственно, роль тестировщика в проекте, благодаря засилью мемов и программистской классики, определяется достаточно мутно. Чаще всего я слышу то, во что когда-то искренне верил:

При наличии оппозиции, знании того, что работа будет тщательно проверяться, программист будет тщательнее подходить к задаче.

То есть, программисту нужны оппозиционеры и надсмотрщик. Как же…

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

Программистам не нужен надсмотрщик-проверяльщик, призрак которого где-то маячит, и скоро как придет, да как проверит всё и вся…

Им нужен помощник, равноценный им по уму-разуму чувак, который понимает, что, как и зачем они делают, и может подсказать, если где-то как-то слажали.

Ошибка в программе — трагедия и для программиста, и для тестировщика.

Цель всей команды — уверенность в том, что в итоге сработана отлично работающая программа.

Пресловутый пользователь на роль тестировщика не подходит. Менеджер проекта — тоже. Голодные дети дома и кредит за машину — тоже нет. Только тестировщик.

Мотивация программиста

1. Создать продукт, об авторстве которого будет приятно сообщать когда-то потом кому-нибудь, кто отличает бит от байта.
2. Забрать себе все существующее бабло и пойти домой.

Мотивация тестировщика

Всё та же — деньги и слава.

Вот если тестировщику будет суждено “вариться” ТОЛЬКО в обществе тестировщиков, то да, единственной пузомеркой является количество и важность найденных багов. Причем количество считается более ценным, почему-то…

Конечно, каждый, кто сейчас сажает глаза, выглядывая в пикселях монитора этот текст, не нуждается в детализации этой темы.

Однако продетализируем.

Деньги — да, нужны. Нужны, как любое средство гигиены, например, наличие зубной пасты в ванной. Она должна быть, причем ее должно быть столько, сколько нужно для того, чтобы каким-то ранним утром не пришлось узнать, что зубной пасты в доме нет…

То есть — много больше, чем «в среднем по рынку».

Когда паста есть, особого внимания к себе не привлекает. Ну, есть. Должна быть. А что, бывает иначе?

Слава — это ориентир того, что до сих пор ты все делаешь правильно, и заслуживаешь признание и одобрение коллег.

Еще раз — коллег. Собратьев по уму-разуму.

Мы стадные существа. Поэтому мнение стада относительно себя самого — неимоверно важно для каждого.

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

У подписчиков и читателей по этому поводу очень-очень другое мнение…

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

Деньги ≈ Слава

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

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