На рулезнейшем форуме суперспециалистов по тестированию спрашивают следующее:
Я начинающий тестировщик. Сейчас устраиваюсь на работу. В ответ на резюме, отправленное в одну из компаний, мне пришло предложение выполнить тестовое задание, которое заключается в том, чтобы найти как можно больше 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)
Искренне рекомендую следующее:
- Все-таки протестировать предложенное приложение и постараться найти там как можно больше багов. Просто для самоуважения. Список этот можете себе на стену повесить – он ваша интеллектуальнейшея собственность.
- Забить на мечту о работе в той крутейшей компании.
- Продолжать искать работу.
- Найти работу, на которой работают правильные люди.
В частности, в качестве тестового задания правильные люди предложат вам следующее:
- Вот приложение. Вот в нем есть такая-то функциональность.
- Вот какие к этой функциональности предъявляются требования (вам кладут на стол список требований, или, может быть, краткое описание задач, которые выполняет этот функционал).
- Пожалуйста, расскажи, как ты это дело будешь тестировать. Какие есть идеи, на какие аспекты ты обратишь внимание в первую очередь, а на какие забьешь болт, с чего начнешь и когда намереваешься завершить тестирование, где и как будешь искать информацию о тестируемой теме, и где ты возьмешь болт, чтобы им забить, если надо будет забить, как уже говорилось…
- Не нервничай и не сучи ножками – тут все когда-то сидели точно так же, как и ты, и думали, думали, думали. Ты тоже думай.
Ну, а когда найдете себе работу с правильными людьми, вернитесь к той самой HR-отдел (цветы прихватите, а не только банку пива) и скажите ей все те комплименты, которые вы хотели сказать, но постеснялись.
Вдруг это ваша судьба?
Вот что я сказал бы, но проблема в том, что меня об этом не спрашивают.
Чётко, даже добавить нечего 🙂
Душевно…
Да-да. Тот самый Soulkeeper. Прочитал. Спасибо, навело на размышления. Действительно, в другой компании мне предложили тестовое задание, к которому возникло меньше вопросов: пару задач на сообразительность и описать, как я собираюсь тестировать одно всем известное приложение. Так что спасибо еще раз. Однако, как Вы понимаете, очень уж тянет цепляться за любую возможность… Думаю, у Вас в свое время, возможно, тоже был такой порыв. 🙂
Как всегда, с художественной искрой . Спасибо.
Дык, “после литры выпитой” © сознание передает бразды правления подсознательному, а что там таится я и сам не знаю 🙂
Разумеется, все через это проходят, и желание “взять да и сделать” намного важнее осторожничанья и затаенного “поиска подвоха”.
К осторожничанью, кстати, тоже все когда-то приходят 🙂
“… вам кладут на стол список требований …”
Молодому бойцу, может, и дадут. А опытному хитро скажут – “сам выкручивайся”.
Кстати, совсем необязательно делать привязку к тестированию программ.
В компании, где я работал пару лет назад, людям давали простой предмет – ручку, степлер, – и просили протестировать. Псевдо-тестеры вставали и уходили, или требовали… хм.. требования и тест-кейсы.
Настоящие тестеры выдавали на-гора такое, что эйчарка только глазами хлопала.
а зачем, простите, проводить тестирование степлера или ручки? для того, чтобы показать свое нестандартное мышление, накопленный опыт, умение думать в стрессовых ситуациях? если пришел соискатель на вакансию тестировщика ПО, зачем ему давать тестировать всякую муть – кресло, кружку, пенал…
Сорри за вмешательство.
Это просто один из способов проверить ПРЕДРАСПОЛОЖЕННОСТЬ человека к тестированию. Не лучший по многим параметрам, но распространенный.
Если хочется четки привязываться к ПО, то можно предложить сферические протестировать поля ввода логина и пароля, например…
Ну и нормально.
Основное времяпровождение тестировщика перед приступанием к тестированию основано на том, сможет ли он полностью выяснить требования, или нет 🙂
@Antony
а зачем, простите, проводить тестирование степлера или ручки?
– Потому что это простой пример. Потому что от человека ожидают демонстрации подхода, а не баг-репорты.
для того, чтобы показать свое нестандартное мышление,
– Наоборот, стандартное тестерское мышление.
накопленный опыт,
– Да, опыт. Но не опыт тестирования ручек, а опыт тестирования вообще.
умение думать в стрессовых ситуациях?
– Ну если только само собеседование засчитывать за стрессовую ситуацию.
если пришел соискатель на вакансию тестировщика ПО,
– Дело в том, что с отношением “моя работа строго от сих до сих” человек вряд ли станет успешным в данной профессии. Зачем тогда вообще себя мучить? Есть и другие занятия в ИТ.
зачем ему давать тестировать всякую муть – кресло, кружку, пенал…
– Хотелось бы уточнить, это пенал – “муть”, или тестирование пенала – “муть”.
Допустим, только пенал. А чем тогда репорт на 1000 строк не муть? Или третий раз за неделю regression? Ведь это могут быть повседневные обязанности, только на интервью за человеком наблюдают, оценивают, а в его работе надо быть уверенным безо всякого (или с минимальным) наблюдением.
@Алексей Лупан
Да я бы даже сказал не предрасположенность, а степень просветленности.
К слову, на junior или entry level позиции такое задание не давалось. Тогда мы искали под senior level и/или team lead.
Насчет параметров – да, согласен. Все таким образом не проверишь. Технические знания проверяются по-другому, а вот эти базовые, универсальные навыки (то бишь, soft skills) можно проверить только таким образом – в действии. А ручка или пенал – “это неэстетично, но зато дешево, надежно, и практично”.
@Albert
Я думаю, демонстрация подхода при тестировании пенала или лифта имеет не очень много точек соприкосновения с тестированием конкретного ПО.
Еще хотелось бы спросить, где Вы увидели в моем сообщении намек на отношение к работе “с 9 до 6”?
Да, вникать в продукт человек обязан, его надо пропускать через себя, жить им. Каждодневный выход на работу должен быть хотя бы не в тягость, но и плясать от восторга не стоит.
С другой стороны, неужели если проводить на работе по 14 часов в день и заниматься ею по ночам, то станешь успешным.
А почему не стоит радоваться своей работе, и надо удовлетворяться тем, что она не в тягость?
Я вот, например, с радостью в понедельник приезжаю к восьми утра, и разработчики, приходящие к 11, уже получают свою порцию оснований для размышления. И мне нравится видеть, что начальство и коллеги ценят мой энтузиазм и позитивный подход, некоторые даже заражаются им и начинают работать лучше.
Роман, не упускай из виду одну нехорошую сторону – в exUSSR корпоративной культуре хвалить и ценить считается излишним (“Да, вы хорошо работаете, но так и должно было быть, вас же наняли для того, чтобы вы хорошо работали! Поэтому возвращайтесь в забой, зэка, и не гремите нам тут вашими костями”).
Особенно это заметно в маленьких компаниях, где поощрять деньгой или титулами сложно. И чем больше работаешь, тем всё то же самое – и зарплата, и обязанности, и проблемы нерешаемые.
Некоторые люди даже не знают, что бывает по-другому. Ибо бытие определяет сознание 🙂
Есть и другая грань – люди в семейном возрасте уже начинают ценить размеренность и нетребность прибегать на работу в любое-любое время, хотя в молодости это даже доставляло удовольствие.
Есть и особенности характеров.
Если у нашего коллеги отношение к работе на уровне “хотя бы чтоб не в тягость” – вряд ли он поймет твой задор про восемь утра. Мне так кажется.
Мне моя работа не в тягость, а очень нравится. Несмотря на то, что иногда приходится проводить regression пять раз за рабочую неделю 🙂
“Не в тягость” – это не необходимое условие, а достаточное. Ведь никто не станет спорить, что выполнение рутинной работы утомляет. А иногда хочется искры и задора, которые приходится находить не на рабочем месте.
Про радость приезда на работу к 8 утра. К сожалению, не могу ее разделить с Романом, всего лишь из-за того, что я сова (точнее филин) и по утрам всегда очень тяжело 🙂
> работа тестировщика (прошу стать прямо и включить мозг) не заключается в поиске багов.
> Она заключается в постоянных, нескончаемых проверках правильной работоспособности приложения. И баги, в общем, вторичный продукт, шлак, который появляется, и на который надо обращать внимание, но это шлак, он раздражает, и радоваться нахождению багов незачем.
фигня, пардон май френч
в основном тестеры нужны для поиска багов
дело, конечно, не в количестве, а в качестве
> > вы же мечтаете о карьерном росте до программиста, не так ли?
то есть по-вашему тестер – это такой типа недо-программер, которому расти некуда – только в программеры?
ерунда 🙂
Нет, по-моему, тестер – отдельная боевая единица в составе команды разработки.
согласен
но не думаю, что путь ему – только в программеры (хотя это тоже неплохо)
Когда-то давно я думал, что поработаю тестировщиком пару месяцев, а затем стану программистом. А вообще я хотел стать менеджером проектов 🙂
Однако же, уже много лет работаю тестировщиком, и программированием занимаюсь в мелочах, но полностью становиться программистом уже давно расхотел. И проектами управлять тоже не свербит – я управляю тестированием, и этим доволен. “Меня прёт!” 🙂
В тексте я сделал культурологическую ссылку к этому феномену – никто не хочет работать тестировщиком, думая, что это ступень к профессии программиста.
Тому причиной и оценка занятия сквозь призму социализации, и то, что зарплаты у программистов В ПРИНЦИПЕ на порядок больше, чем у тестировщиков.
Но в тестировании есть всё – и фан, и деньги, и социальное положение. Я окончательно прозрел только тогда, когда впервые получил в роли достаточно обычного тестировщика зарплату матерого программиста.
сложная цепочка 🙂
теперь понял
>Понимаете, мне кажется, что “домашнее задание” >должно показать, как вы ВООБЩЕ умеете думать в >области “поиска багов”, а не требовать список багов.
А мне такое задание нравится, как часть этапа приема на работу, при условии что сайт заморожен и глюки я его уже заранее знаю. Нестандартное мышление и прочее я спокойно смогу оценить на собеседовании, а вот способность спокойно и вдумчиво проработать над заданием в течении длительного времени нет.
Преимущества я вижу такие.
1) Показывает, уровень знакомства человека с тестированием в принципе. То есть, если он не знаком ,то и сценарий написать не сможет, и скриншоты не положит.
2) Показывает умение описать проблему, не скатываюсь да у Вас здесь вообще не работает :).
3) Примерно можно оценить уровень наблюдательность кандидата. Если люди принципиально не способные видеть проблемы.
Прочие тесты также важны, но и эта часть необходима, так как человек лучше всего проявляет себя в работе.
+1
4) Можно оценить, как кандидат умеет расставлять приоритеты. Оптимально он должен вначале дать самые серьёзные проблемы, и только в конце – опечатки и т.п.
Я таки жил довольно долгое время в том известном поселке Костюжены 🙂
К теме – скриншот как альтернатива ручки.
“The Impossible Challenge” by Darren McMillan – http://bit.ly/bP9seH
С одной формы накопали чуть ли не сотню дефектов
Вопросы на нестандартное мышление.
Некоторые из них задавали мне, другие читал у людей в блогах. Все хотел запостить… наконец есть время перевести.
В корзинке лежало 6 яиц. 6 человек подошли, взяли по одному яйцу каждый, и ушли. Но в корзинке осталось одно яйцо. Как это возможно?
Полиция окружила дом, где находится подозреваемый в убийстве. К сожалению, им только известно, что его зовут Джон. Ворвавшись в дом, они обнаружили людей, играющих в покер: плотника, железнодорожника, почтальона и пожарного. Без лишних разговоров, полицейские схватили и увели пожарного, который и оказался искомым человеком. Как они угадали?
Почему колодезные люки круглые?
Примем, что на Земле живет ровно 5 миллиардов человек. Считаем только для левой руки. Берем количество пальцев на руке первого человека, и перемножаем на количество пальцев на руке второго человека. Полученный результат перемножаем на количество пальцев на руке третьего человека, и т.д.
Какое число будет для всего населения Земли?
5 кусочков угля, морковка и шарф лежат в траве недалеко от дома. Никто их там не оставлял, как же они там оказались?
На столе в беспорядке лежит 20 монет одинакового достоинства. Половина лежит орлом кверху.
Задача. С завязанными глазами и в перчатках, разделить монеты на два набора по 10 в каждом. Количество “орлов” и количество “решек” в первом наборе должно совпадать с количеством “орлов” и количеством “решек” во втором наборе.
Изначальное количество “орлов” и “решек” неизвестно.
Доступные действия: передвинуть монету; перевернуть монету.
На слух и на ощупь монеты воспринимаются абсолютно одинаково.