Мой доклад на SQA Days-8

На эту конференцию я решилась-таки написать доклад. И он был принят программной комиссией.
Я очень нервничала, и чем ближе,тем больше проклинала тот день,когда решилась это сделать. Да, выступать очень-очень страшно.
Но,к счастью, все прошло довольно хорошо. :)

Ниже презенташка моего доклада и его текст.

Девять правил семпая, или как стать успешным наставником

«Девять правил Семпая, или Как стать успешным наставником?»
[1]
Каждый из нас, поступая на работу, был новичком. Период обучения каждого конкретного человека занимает разное время и зависит от опыта работы и коммуникаций с людьми, личностных качеств, технической базы и...наставника. К этому выводу я пришла,проанализировав успехи новичков и зависимость их от принципов работы наставников. В данный момент я сама являюсь наставником и хочу поделиться с вами основными правилами,которыми я руководствуюсь при работе со своими учениками.
Идея наставничества как метода обучения пришла из древних времен, когда мастера обучали учеников, которые смогли бы заменить их или просто помочь в работе. В восточной культуре существует понятие Сэмпая – так называют человека, у которого больше опыта в той или иной области. При этом возраст не имеет значения
Этот термин я и буду использовать в докладе, потому что японцы – наиболее уважающий друг друга народ, а именно к взаимному уважению и должены стремиться Наставник и Ученик.

Первое правило Сэмпая. «Вижу цель, иду к ней»
[2]
Роберт Кийосаки
Один из принципов наставничества состоит в том, что ученик почти все время находится или в непосредственной близости от Учителя, или выполняет его задания. Эта практика была перенесена в сферу Информацинных технологий, и, на мой взгляд, отлично прижилась среди тестировщиков. Причин этому очень много, основные,на мой взгляд, заключаются в том,что возможность получить образование по этому профилю практически отсутствует, и большинство людей,как ни крути, попадает в тестирование случайно.
Наставничество преследует несколько целей:
• Помочь человеку усвоить большой объем знаний за короткое время
• Облегчить адаптацию человека в коллективе
Это общие цели, преследуемые как для новичков в тестировании, так и для опытных сотрудников, сменивших компанию. Более развернутые цели при обучении новичков, выглядят так:
• введение в проект
• введение в коллектив
• обучение инструментам и шаблонам
• обучение с нуля тестированию
Для сотрудников же с опытом работы целей преследуется никак не меньше:
• введение в проект
• введение в коллектив
• обучение инструментам и шаблонам, принятым в данной компании
• перенятие опыта
(перенятие опыта подразумевает под собой осмысленные попытки «разговорить» человека, чтобы знать, чем отличались принципы или методы работы человека на предыдущей работе. Возможно, есть что-то, что стоило бы начать использовать и в компании наставника :) )
[3]
Поставленные цели должны быть достижимы. Например, цель «обучение тестированию за 2 месяца» является недостижимой по причине того, что она неизмерима. Такие цели следует разбивать на более мелкие – например, на умение писать баг-репорты, проходить тест-кейсы, писать тест-кейсы и тест-планы.
Для достижения поставленных целей нужно создавать условия Ученику. В идеале занятия Ученика должны одновременно служить и развивать несколько навыков ученика, а не один.

Второе правило Сэмпая. Желание учить и помогать КОНКРЕТНОМУ человеку
[4]
Л. Берне
Вторым правилом наставничества является желание Сэмпая помогать конкретному человеку, с его достоинствами и футболкой супермена, и учить его. Если между Сэмпаем и Учеником нет связи или взаимоуважения – ни один из них никогда не будет работать эффективно в паре и они не добьются хорошего результата.
[5]
Таким образом приходим к выводу, что Сэмпай должен сам выбирать себе Ученика. Будущих наставников нужно обязательно брать на собеседования кандидатов и советоваться с ними,принимая решение о найме. Ведь никто не будет так близко общаться с новым человеком в ближайшее время, как его Сэмпай.


Третье правило Сэмпая. Стратегия
[6]
Брайан Трейси
При обучении сотрудников хорошей является следующая стратегия:
1. «Я расскажу, ты послушай»
На этом этапе следует максимально полно дать необходимую информацию о предмете.
2. «Я покажу, ты посмотри»
Показать, что делать и как, лично нажимая на кнопки и комментируя.
3. «Сделаем вместе»
4. «Сделай сам, я подскажу»
5. «Сделай сам, расскажи, что сделал».
На этом этапе важно понять, правильно ли мыслит Ученик. Для этого можно использовать зрительный контакт или просить продолжить за вас фразу.
Иногда ребята очень быстро пролетают первые 3 этапа . Могут возникнуть непонятки с результатом выполнения задачи. Их лучше всегда формализировать, и ,в некоторых случаях, даже записывать. В то же время особо вдаваться в подробности тоже не стоит – нужно всегда оставлять человеку свободу для творчества в работе.
Сэмпай всегда должен знать:
• Чем в данный момент занимается его Ученик
• Каких целей позволяет достичь текущая задача Ученика
• Каков ожидаемый результат выполнения конкретной задачи
• Чем по плану он будет заниматься дальше
Это позволяет максимально быстро при необходимости скорректировать действия при внесении поправок в курс обучения.

[7]
Также я бы рекомендовала Сэмпаю вести дневник, особенно, если у него несколько Учеников. В такой дневник следует заносить свое отношение к сделанной работе ученика или общее удовлетворение\неудовлетворение, обязательно с пояснениями. Например,
«16.05.2010
В простых отчетах об ошибках делает много ошибок. Грамматика, структура.
Исправление ошибок в одном месте не переносит в другие.»
Также можно отмечать и положительные моменты в работе ученика :)

Четвертое правило Сэмпая. Право на свою точку зрения
[8]
Т. Питере, Р. Уотермен
Не стоит давить на корню желание Ученика отличаться. Задача Сэмпая – мягко направить индивидуальность в полезное русло. Если заставлять делать все «как я», то можно получить в итоге «напичканного» шаблонами ученика, который будет бояться ступить шаг в сторону, вместо самостоятельно мыслящего креативного специалиста, коего мы хотим воспитать. Это касается таких мелочей, как написание баг-репортов или тест-кейсов, к примеру. Не стоит заставлять человека использовать Ваши любимые слова или времена, вместо его любимых, если, конечно, это не обусловлено терминологией проекта, корпоративной политикой или желанием высших сил. На слайде показана идеальная команда – они все, вроде,и одинаковые – но в каждом есть неповторимая изюминка, которая делает его неповторимым и от этого особенно ценным. Ведь никто не будет отрицать,что у каждого человека есть свои слабые и сильные стороны. Правильное их развитие и делает человека специалистом.

Пятое правило Сэмпая. Доверие
[9]
Китайская мудрость

Чтобы понять, чего человек стоит, нужно доверять ему задачи все более и более сложные. Если Сэмпай будет все время перепроверять Ученика, он будет высказывать этим недоверие к ученику и его способностям, в результате чего сам Ученик разуверится в своих силах.
[10]
На практике же, к сожалению, проверять все-таки приходится. Например, например,задача слишком большая и серьезная. В таких случаях по возможности проверку нужно делать скрытно, чтобы о ней не знал Ученик. Пусть считает себя суперменом, когда вы якобы случайно наталкиваете его на мысль и прикрываете его спину :) Второй вариант – наоборот предупреждать о том, что вы будете проверять. Например, «Закончи с этим и обсудим дальнейший план действий».

Шестое правило Сэмпая. Ответственность
[11]
Д. Кеннеди
На слайде приведён пример настоящего Наставника. Это генерал Панфилов, чье соединение было награждено орденом, а сам генерал – удостоен звания героя СССР.
Дело в том, что ничто так не характеризует наставника, как его Ученики. Любая, даже маленькая, победа ученика частично является заслугой Сэмпая. Сэмпаю нужно стремиться к тому, чтобы на вопрос, кто этот человек, ответом было «Это Василий из дивизии Панфилова», «Это Петр, подопечный Марии».
[12]
Любой, даже маленький, проигрыш ученика является проигрышем наставника. Сэмпаю всегда нужно помнить об этом и интересоваться развитием Ученика, иначе Сэмпай может прослыть плохим или бестолковым учителем, а Ученик – бестолковым учеником. Ни то, ни другое невыгодно компании, а, значит,этого нужно стремиться избегать. Наставнику необходимо делить со своим Учеником победы и поражения.
Если Ученик сделал что-то не так, обсуждать и критиковать его поступок должен именно Сэмпай, а не другой Сэмпай, или Тест менеджер, или Проект Менеджер. Таким образом достигается бОльшая близость между Сэмпаем и Учеником, что позволяет Ученика раскрыться.

Седьмое правило Сэмпая. Спокойствие
[13]
Как уже говорилось, между Сэмпаем и Учеником должны установиться доброжелательные, доверительные и уважительные отношения. Учитывая, что Наставник является больше учителем, нежели контроллирующим органом, Сэмпай не имеет права жестко критиковать Ученика. Все проблемы, неувязки, непонимания и разочарования должны обсуждаться спокойно и взвешенно, критика должна быть только конструктивная, и вообще такие разговоры должны быть скорее похожи на общение друзей, когда один обратился за советом, нежели на ссоры детей и родителей вроде «Ты снова поступил не так!» или «Как так можно вообще?!». Если Вы чувствуете острое желание именно отругать человека, лучше отложите разговор о его промахах на другой день, когда смежете говорить спокойно.
[14]
Во время разговора обязательно нужно
• Выяснить причины, по которым Ученик решил поступить именно так
• Определить,как он должен был поступить
• Объяснить, почему его вариант решения проблемы плох, а предложенный вами – хорош
• Подвести итог
• Написать краткое резюме и отправить ему почтой
• Для Сэмпая – определить степень своей вины и причины, по которым он допустил такой проступок
Сэмпаю следует стать своего рода фильтром между Учеником и внешним миром на некоторое время. Затем следует постепенно выводить ученика во внешний мир.

Восьмое правило Сэмпая. Постоянное стремление к знаниям
[15]
Томас Джон Уотсон-старший
Сфера тестирования программного обеспечения и сами по себе информационные технологии сейчас развиваются семимильными шагами. Хороший тестировщик должен следить за их развитием и не отставать, иначе его профессионализм и ценность будет падать с каждым днем. Поэтому Сэмпай должен прививать Ученику желание развиваться и расти, узнавая что-то новое. Сэмпай должен уметь зажечь в Ученике искру. Лучший способ для этого – собственный пример.
[16]
Например, можно рассказать о недавно прочитанной статье за чашечкой кофе и спросить, что думает Ученик об основных проблемах, затронутых в ней. Или просто делать доклады для новых сотрудников по определенным темам, заставляя ребят думать и задавать вопросы.
Также Сэмпаю следует ставить ученику все новые и новые цели, которые будут развивать его и дальше, тем самым показывая, что всегда есть куда расти практически в любых условиях.
Я думаю, что у Вас тоже есть какие-то наработки по данному вопросу. Может, кто-нибудь ими поделится? 

Девятое правило Сэмпая. Дальнейшая забота об Ученике
[17]
Как правило, Сэмпаев помнят и уважают еще долго, если обучение проходило правильно и гладко. Поэтому, когда Ученик заканчивает обучение или переходит в другой проект, Сэмпай не должен рвать сразу все связи со своим учеником. Еще какое-то время (а,может, и долго) следует поддерживать его морально и быть советчиком в сложных для него вопросах, чтобы ученик не чувствовал себя брошенным в новую пучину неизведанных знаний.

Вывод
В заключение хочу сказать, что быть Наставником – очень ответственная часть работы, которая требует как глубоких профессиональных знаний, так и знаний в области психологии. В большинстве случаев именно от наставника зависит успех Ученика в данной компании. Подходите к обучению с умом, и пусть Ваши Ученики радуют Вас!

Отзыв: SQA Days-8

Вот и у меня дошли руки до своего блога и отзыва о конференции SQA Days-8, которая проходила в Санкт-Петербурге.
В общем впечатление о конференции весьма положительное. Такого рода мероприятия мне нравятся не только тем, что есть возможность получить новые знания, но и тем, что там я часто нахожу подтверждение каким-то своим мыслям.

Из докладов хотелось бы отметить следующие:

1. Михаил Павлов "Отвечает ли тестировщик за качество?"
К великому сожалению Михаила, частично об этом говорил Майкл Болтон буквально перед ним. Тем не менее, Михаил раскыл тему более полно и детально и я совершенно с ним согласна - тестировщик отвечать за качество не может. Странно было слышать, когда люди вставали и говорили, что тестировщик может это делать и некоторые из них это делают. Бежать, бежать из такой компании :) Как можно отвечать за то,что ты не можешь контроллировать? Можно отвечать за качество СВОЕЙ работы, за качество работы отдела тестирования - почти можно, если есть достаточно полномочий, но за качество продукта... Нет, увольте.

2. Александр Александров "Дефектные дефекты"
Слышла много негативных отзывов, мол, доклад скучный. Имхо, это просто манера изложения Александра. Или преподавателей УЦ Люксов. Или просто взрослых и мудрых людей. Доклады Александрова мне всегда нравятся тем, что в них толково раскладывается по полочкам все то,что постепенно во время работы превращается в кашу. Вроде думаешь - да и так все понятно, а нет, со временем не так уж и понятно становится :) После прослушивания его докладов знания становятся более систематизированными,что ли.

3. Денис Бесков "Послание аналитиков тестировщикам"
Интресен был взгляд со стороны аналитиков на работу тестировщиков. Учитывая, что до конференции я никогда не видела живого аналитика - было занимательно. :)

Глобальные идеи, которые я вынесла с этой конференции:
1. Автоматизация
Нужно автоматизировать рутинную работу, оставляя тестировщикам время именно на полет мысли и фантазии :) Конечно, при условии нестабильного функционала, краткосрочных продуктов и т.п. автоматизация остается в стороне.
2. Метрики
Жаль,что на предыдущей работе руки так и не дошли до введения метрик,хоть я и думала об этом. Все-таки нужно было потратить (не?)много времени и ввести парочку самых необходимых нам на тот момент.
3. Место работы, компания
Не позволять себя засасывать болоту :) И в то же время никогда не сдаваться.
4. Тулзы
Доклады о самописных тулзах гигантов индустрии меня мало интересуют ввиду их максимальной заточенности под конкретные условия работы\практики и стоимости.
5. Люди
Некоторые люди не настолько плохи, как казались.
Некоторые люди не настолько круты, как казались.

P.S. А Питер - да, как всегда прекрасен.

"Менеджер и программист"

Взято отсюда

Как-то очень жизненно :)

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

— Простите, не могли бы вы помочь? Я договорился с другом встретиться час назад, но не знаю, где сейчас нахожусь.

— Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы, - ответила женщина.

— Вы, должно быть, программист?

— Да, а как вы догадались?

— Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно говоря, вы мне совершенно ничем не помогли.

— А вы, наверное, менеджер?

— Да. А вы как догадались?

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

Monkey Habits

Когда я была джуниор тестировщиком, мне как-то дали ссылку на статью Monkey Habits , которая взорвала мне мозг. С тех пор эта статья всегда висит на одной из вкладок моего браузера и стала моей "настольной книгой". По-моему, она гениальна. Рекомендуется к прочтению всеми и заучиванию отдельных предложений наизусть :)

Реинкарнация доски

По следам Макса Дорофеева :)
В моей комнате тоже появилась доска задач! Правда, она не столь навороченная, однако, для моих нужд вполне хватает. Доска отражает только статус задач по тестированию - их количество в разных состояниях (Очередь, Выполняемые, Отложенные и Законченные) и людей, которые над ними работают.
Ах да, еще распределение задач по приоритетам.
Задачи имеют разный цвет бумажек в зависимости от проекта, на самих бумажках - краткое описание задачки.Приклееные к бумажкам закладки определяют исполнителей (каждый тестировщик выбрал свой цвет закладки).
Из минусов пока отметила только сложность сохранения законченных задач - пока я записываю информацию о выполненных задачах за неделю в эксельку с надеждой на дальнейший анализ. :)

(называния проектов скрыты :) )

Хедхантинг

На днях ко мне в скайп заглянула ХР одной софтверной компании с предложением о работе. Примечательно то, что до вчерашнего дня я и логина не знала от своего скайпа, так что 100% нигде не оставляла контактную информацию скайпа.
Вопрос: Как вы относитесь к таким внезапным предложениям? Что делаете и как отвечаете, в случае, если вас интересует\не интересует предложение?
Потому что я,честно говоря, растерялась :)

Загадки природы

Откуда берутся программисты с опытом работы в несколько лет, которые замечания воспринимают как личные придирки? К нам пришел один такой, пытаюсь с ним налаживать контакт и получать то,что нужно. Человек даже замечания по форме тестинг реквестов воспринимает как оскорбление! Что уж говорить о необходимости проверки версии перед ее выкатом на тестирование...
Я такого еще не видела :( Но пытаюсь объяснить,что это не моя прихоть, а обусловлено правилами компании\экономией ресурсов\сохранением истории переписки\и тд. Самое странное то,что до этого он работал в крупной компании с поставленным процессом тестирования.
Три дня обид (с его стороны) и стальных нервов (ессно,с моей стороны :) ) принесли мне его извенения за резкость, согласие писать реквест по форме, обещание проверять перед выкатом версии (для этого пришлось два раза фидбекнуть билд,который элементарно не запускался) и осознание мной факта, что этот человек совершенно не хочет заниматься ничем, кроме программирования (даже софт для себя же искать не хочет).
Посмотрим, что будет дальше. Буду внимательно наблюдать и слушать, когда мои ребята будут обсуждать с ним его баги.
А вообще такое поведение очень и очень странное, учитывая, что человек не работает еще и месяца и испытательный срок, соответсвенно, еще не пройден.

Баг Thunderbird, который заставил меня неудомевать

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

логин : admin
пароль: password[пробел]

подпись

При отправке же Thunderbird обрезал пробел в конце пароля,что и стало причиной задержки в работе :(

Беречь и защищать

Заметила за собой такую черту - я защищаю своих курируемых учеников до последнего от внешней критики (когда критикуют программисты, проект менеджер или еще кто), в то же время сама, при необходимости, "ругаю" их. То есть выходит, что я стремлюсь к тому, чтобы ругать их лично, при этом предварительно выбрав слова, которые максимально понятно объяснят конкретному человеку суть его проступка.
Так вот,как только заметила это за собой, стала задумываться над правильностью своего поведения. С одной стороны, я берегу их психику, ограждаю от лишних конфликтов и создаю более доверительные отношения между наставником и учеником. Да и незачем выносить сор из избы...
С другой же стороны, они могут стать неприспособленными к "свободному полету" и рабочему общению с другими людьми по МОЕЙ вине, ведь нужно учиться регулировать конфликты самостоятельно и полноценно отвечать за свои поступки\проступки.
А как же тогда принцип "Хвалить - публично, ругать - лично"?

Ключевые сотрудники

Читаю книгу "Балдеющие от адреналина и зомбированные шаблонами...". В этой книге авторы часто употребляют выражение "ключевой сотрудник". Как по-Вашему, может ли тестировщик быть ключевым сотрудником

1. рамках компании
2. в рамках отдела тестирования
?

Офис квартирного типа

Как Вы относитесь к офисам квартирного типа (когда ИТ компания располагается в квартире жилого дома)?

Я считаю такую компанию шарашкой, и ничего не могу с собой сделать :(
Или совсем-совсем молодой и несерьезной.

Дай качестВО! по-советски

Нашла несколько агитационных советских плакатов, которые хочу распечатать и повесить в нашем оффисе, в той части, где сидит отдел тестирования :) Пока картинки нередактирвоанные.

Смело и безбоязненно критикуйте недостатки в работе!


Дай качестВО!


Работник милиции! Будь бдителен! (в дальнейшем будет заменено на "Тестер")

Долой брак!

What leads to success?

Послушала заменчательный рассказ Ричарда Джонса о 8ми секретах успеха. Согласна со всем :)

Оригинал тут.


1. Passion
Do it for love, not for money.

2. Work
"Nothing comes easily. But I have a lot of fun."

3. Good
"To be successful out your nose down in something and get damn good at it."
Practice, Practice, Practice.

4. Focus
"Focusing yourself to one thing"

5. Push
"Push yourself. Physically, mentally, you gotta push,push,push."

6. Serve
"It is a privilege to serve as a doctor."

7. Ideas
Listen, Observe, Be Curious, Ask Questions, Problem solve, Make Connections

8. Persist

Статистика отношения к тестированию ПО

Интересная статистика по отношению к тестированию ПО.
Я отношусь к компании, в которой тестирование считается для отдела QA :( А как бы хотелось работать вместо со счастливыми 54% процентами QA населения, у которых функциональное и\или модульное тестирование проводится с помощью программистов!
(кликабельно)


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

SQA Days 8

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

Интструмент для создания правильных гайдов

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

a. ....
b. ....
c. Steps = шаги.
Шаги пишем в формате
1. Достать паяльник. (абзац)
2. Ударить себя по голове.
d. Expected results = результаты прохождения каждого шага
Пишем в формате
1. Паяльник в руке.(абзац)
2. Голова болит. Перестало быть скучно.
Обратите внимание, что если Шаг 1 будет занимать две строчки, то...

Слышала только положительные отзывы :)
З.Ы. Гайд внутренний, для использования внутри компании.

Лучший инструмент тестирования

Оригинал здесь.
В очередной раз спасибо Энди за наглядность и юмор :)

Распределение задач и планирование

Было в моей работе такое время, когда я год работала единственным тестировщиком на всех проектах и частично мне помогал ПМ. В ту счастливую пору необходимости письменного планирования задач у меня не было по причине того,что
1. вся команда сидела в одной комнате и могла спросить, чем я занимаюсь
2. На документирование уходило драгоченное время, которого было очень-очень мало и так
3. Я и так знала,чем мне заниматься, и моей работой не руководил никто,кроме меня самой.
Однако,с появлением нескольких людей в команде тестеров и большого количества проектов, возникла-таки необходимость в документированном планировании работы отдела. Я задумалась об этом тогда, когда вопросы типа "Что мне сегодня делать?" от членов команды начали меня сердить по причине того, что то,что я запланирвоала себе, нужно было отодвинуть, дабы проанализировать ситуацию и придумать им задачу :)

Взяв за основу формат эксель-расписания, который использовался на моем предыдущем месте работы, я продолжила его импрувить.
1. Определила каждую строку экселя = 0,5 часа.
Чтобы визуальный вид длительности задач был примерно пропорционален их распределению в дне. К сожалению, не всегда получается сохранять пропорции, но я стараюсь :)
2. Добавила поле TOTAL к каждому дню, которое содержит общее количество часов.
Это было вызвано тем, что в моей компании свободный график, и можно работать в один день 5 часов, а в другой 13. все решает сам человек. Соотвественно, задачи тоже должны быть распределены на все время человека, которое он планирует потратить в день. Это также полезно для планирвоания бюджета - у нас QA могут не знать, сколько часов в день или сколько бюджета выделено на определенный проект. Но это должен знать человек, который распределяет задачи.
3. Цветовая индикация.
Каждый проект имеет свой цвет в плане. Это делает план более веселым :) А с практической точки зрения - проще посмотреть время, потраченное на работу над каждым проектом и те, для кого написан план, могут определить свои проекты, не читая их названия. Становится еще удобнее, если цвет проекта в экселе каким-то образом связан ассоциативно с проектом - например, основной цвет логотипа продукта. И ребята всегда знают, в какой проект им заносить свое время в системе учета времени.
4. Положила в SVN.
При коммите отправляю уведомление о том, что план был изменен и для кого.

Единственная серьезная проблема, которая возникает - это суппорт. Изза непредвиденных задач приходится переставлять некоторые между людьми или менять им дни выполнения. Это решается довольно просто - отложенные задачи я храню на страничке Template, которую копирую каждый раз при написании плана на новую неделю + в экселе довольно просто переставлять задачи - скопировал и вставил на другой день :)

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

Естественно,что такие задачи, как репродюс кастомерских багов, добавляются не в начале недели, а по мере возникновения :)

О мечтах. Очень бы хотелось найти такую систему, в которую бы можно было настроить доступ нескольким пользователям с определенными правами, чтобы можно было перемещать задачи драг-энд-дропом, чтобы при перетягивании задач программа детектила, что ты ее переметил туда, где теперь в сумме получается больше 8ми часов,к примеру, и цветом выделяла эти дни... Но, к сожалению, все, что я встречала, было однопользовательским максимум с возможностью экспорта в ХМЛ,а о драг-энд-дропе и других желаемых функциях нет и речи :(

Paint в Windows 7

Я познала дзен. :)
В Пейнте, встроенном в Вин 7, у инструмента Brushes (Watercolor brush, Oil brush) заканчивается краска на кисточке...
Так мило. Будто намекая на скоротечность и непредсказуемость жизни.

А задумка отличная, как по мне :)

"Борется за свою славу"

Сегодня пересмотрела фильм "Обыкновенное чудо" и нашла в нем очень интересный момент.
По сюжету Король ищет свою сбежавшую дочь и заходит в трактир. Заговорив с Трактирщиком, Король интересуется, кто в данный момент еще проживает в трактире.

Трактирщик: Охотник с двумя учениками.
Король: О, так, значит, он может мне помочь! Он много охотится и многое видит. Может, он видел мою дочь?
Трактирщик: Нет, этот охотник Вам не поможет, он больше не охотится.
Король: А чем же он занимается?
Трактирщик: Борется за свою славу. Он собрал уже 50 дипломов о том, что он знаменит.
Король: Так чем занимается-то?
Трактирщик: Отдыхает. Бороться за свою славу, может быть, гораздо утомительней...

Грустно, что тоже самое происходит и среди тестировщиков - слишком многие стремятся доказать, что знамениты (или стать знаменитыми). При этом у них все меньше времени остается на само тестирование.

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

Эмоции и наставничество - несовместимы

Наставник (сен-сей :) ) никогда не должен позволять себе резких фраз в отношении Ученика и жесткой негативной окраски действий, например "это же позорище", "ты меня разочаровал" и т.д.
Это негативно влияет как на межличностные отношения между Сен-Сеем и Учеником, так и на производительность Ученика - он начинает бояться сделать что-то не так или снова быть раскритикованным.
Лучше использовать слова, имеющие нейтральный окрас и в случаях, когда Ученик поступает неправильно, в нейтральных выражениях и нейтральным тоном объяснить, почему это неправильно и к чему может привести.

Опечатки

Некоторые заказчики очень прохладно относятся к spelling errors в проекте, хоть программа и является лицом компании. Мне бывает очень смешно читать сообщения, написанные на ломаном английском через ПРОМТ. :)
Так вот, насчет ошибок в надписях, подписях и сообщениях.
Иногда они могут стоить очень дорого,как в примере ниже.
На этом ролике YouTube проигрывается одна из серии популярного шоу "Will it blend?", и в этой серии ведущий задает этот вопрос относительно пластиковых карточек - дисконтных, кредитных, депозитных и тд. В начале ролика он просит женщину достать их все из кошелька и поучавствовать в шоу. Так вот,на 57 секунде, когда карточки начинают превращаться в пыль, на экране появляется надпись - "Please, try this at home!" !!!



По закону за такое можно подать в суд, потому что человек может принять это как руководство к действию и потерять все свои карточки. (Следует сказать,что во всех остальных сериях этой передачи фраза написана как "Please, don't try this at home!".)

Вывод: тестеры всегда должны быть внимательны даже к "незначительным" и "неважным" опечаткам и грамматическим ошибкам.

Игра в быстрые вопросы

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

Так вот, для поддержания и проверки знаний, в последнее время я начала практиковать использование быстрых вопросов своей команде. Суть такова - ни с того, ни с сего (для подопечного, конечно же, у Вас-то все давно продумано!) задаете вопрос члену команды, устно или письменно через асю - неважно. Вопрос должен быть конкретным, чтоб задать его быстро, и быстро услышать ответ. Например, назвать методики сокращения количества тестовых примеров, перечислить виды тестирования и далее в таком духе.
Задали - и наблюдаете.
Если вопрос устный, то смотрим за глазами человека и его движениями, чтобы понять степень подготовленности человека морально и степень знания вопроса. Вывод для Вас, если подопечный не справился, должен быть такой : "дать Васе на самообразование повторить этот материал".
Ни в коем случае нельзя сердиться и нервничать ("Как ты можешь не знать таких элементарных вещей!"), иначе игру можно считать законченной,а менеджера - проигравшим - ему начнут врать. Да и и игра перестанет быть игрой, превратившись в чекпоинт.
Если вопрос письменный, то нужно наблюдать за выражением лица (если это возможно) и следить,чтоб у человека не было возможности\времени открыть Гугл. Остальное все также, как и в случае с устным вопросом.

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

ОБЯЗАТЕЛЬНО необходимо объяснить команде, что это не проверка знаний и не контрольная работа, а просто такая игра, в которой можно очень быстро проверить свои знания в той или иной сфере, чтоб знать, какие знания следует освежить.

Делаем фотографии багов с PicPick

Не так давно открыла для себя новый скриншотер PicPick, который намертво поселился на моем компьютере :)

Функционал, который меня покорил:
- встроенный графический редактор, схожий с Paint Windows 7
открывается сразу после создания скриншота с новым только что сфотографированным приложением
- большой выбор регионов фотографирования
десктоп, часть экрана, свободный регион, который можно просто обозначить мышкой, и т.д.
- все фото можно повесить на конфигурируемые горячие клавиши
ускоряет работу :)
- пиксельная линекйка
- транспортир
наконец-то мерять углы и "ровность" линий стало проще простого
- пипетка для определения цвета элемента
очень удобно,если нужно подделать на скрине какую-то мелочь
- бесплатный с постоянными обновлениями
- и многое другое :)

Выбор окружения для тестирования

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

Для мира:
http://www.w3schools.com/browsers/browsers_stats.asp

Для стран СНГ:
http://www.liveinternet.ru/stat/ru/browsers.html?period=month

Для Украины:
http://index.bigmir.net/users?&d=0&y=2

Обратите внимание, насколько отличается статистика мира и Украины :)

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


Вывод: перед тестированием ЛЮБОГО приложения, тестировщику обязательно стоит основательно изучить статистику возможного использования окружения для тестируемого приложения, чтобы максимально ориентироваться на потребителя (здесь следует учитывать регион предполгагаемых пользователей). Также следует периодически мониторить изменение используемого пользователями ПО для эффективного реагирования на изменение нужд пользователей.

P.S. Теперь понятно, почему я вижу эти баги - у Оперы недостаточно процентов использования в мире, чтобы проверять под ней приложения и исправлять ошибки :)

Ограничение количества символов в текстовых полях

В своей работе каждый тестер сталкивается с тем, что нужно ограничивать максимальное количество введенных символов. У нас в компании практикой уже выработаны некоторые стандартные значения длины. И вот, читая блог, я обнаружила список самых длинных названий, доменов и т.д.
Я сделала вывод, что нужно пересмотреть наши стандартные значения длины полей - нам-то нетрудно сделать поля длиннее, а короткие поля, как оказалось, могут принести неудобства определенной (хоть и маленькой) части пользователей.

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

Одни из самых длинных улиц России = 80 символов без указания дома
улица 1-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 9 домов
улица 2-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 34 дома
улица 3-я За Линией Октябрьской Железной Дороги, Россия, Тверская область, Тверь - 61 дом

Самый длинный домен из Украины = 239 символов (не знаю, как сейчас, а когда я писала, то не могла к нему доступиться)
http://www.public-organization-capital-of-the-world.which-establishes-world-records-welcomes-all-inhabitants.of-the-planet-and-invites-them-to-visit-our-ancient-city.yours-faithfully-chairman-of-government-anatolij-kosjanchuk.epak.infocom.lviv.ua

Киррилические домены
http://президент.рф/
правительство.рф

Самый длинный почтовый домен = 68 символов без учета имени пользовтеля
@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com

Самая длинная аббревиатура
«SKOMKHPHKJCDPWB»
Самая длинная аббревиатура в России = 55 символов: НИИОМТПЛАБОПАРМБЕТЖЕЛБЕТРАБСБОРМОНИМОНКОНОТДТЕХСТРОЙМОНТ

Самое длинное название = 132 символа
«Кафедра гигиены, эпидемиологии, медицинской полиции, медицинской статистики, учения об эпизодических болезнях и ветеринарной полиции»

Самое длинное название города = 179 символов
Бангкок. На тайском языке: «Krungthepmahanakhon Amornrattanakosin Mahintharayutthaya Mahadilokphop Noppharat Ratchathaniburirom Udomratchaniwetmahasathan Amonphiman Awatansathit Sakkathattiyawitsanukamprasit», что в переводе означает «Город ангелов, великий город, резиденция изумрудного Будды, неприступная крепость, великая столица мира, одаренная девятью драгоценными камнями и изобилующая великолепными королевскими дворцами, напоминающими райские жилища, из которых правит олицетворение Бога, Город, дарованный богом Индрой и построенный Висанукамом».

Самая длинная фамилия = 43 символа
Если написать ее по–русски: «АИЙИЛЬЦИКЛИКИРМИЦИБАЙРАКТАЗИЙАНКАГРАМАНОГЛУ» (в переводе «Сын героя знаменосца флага с полумесяцем и звездой»).

UI баги blogspot.com

Вы расстраиваетесь,когда находите баги не в тех приложениях,которые Вы тестируете?
Я вот очень расстраиваюсь, когда вижу такие явные и некрасивые баги в широкоиспользуемых аппликухах или на частопосещаемых сайтах. Вот и мой любимый blogspot.com чудит...

Номер раз. Форма входа, язык интерфейса - Украинский.

Номер два. Метки "облаком" (нижнего скроллбара на экране нет, текст просто обрезан).

Придется использовать метки "списком", но тоже выглядит не фонтан - видны разделители между линками...


Длинные слова тоже выходят за "рамки дозволенного" :)


И отсутсвует нотификация об окончании загрузки файла в блог.

P.S. У меня Opera 10.

Priority & Severity

Пока в нашей компании жизнь была спокойной и налаженной,я искренне недоумевала, зачем дублировать информацию, имея, кроме поля Priority, еще и обязательное поле Severity. Но теперь, имея массу тикетов перед релизом и не имея поля Severity в кастомерском багтрекере, я понимаю, что мне его не хватает :)
Priority - это приоритет, а Severity - "строгость","жесткость". Я, наконец-то, столкнулась с такой ситуацией, когда приоритет ошибки гораздо выше, чем ее строгость, и наоброт - строгость выше, чем приоритет ошибки.
Например, ГУИ баги у нас обычно имеют низкую строгость и, зачастую, низкий приоритет, однако, перед релизом приоритет внезапно растет, в то время, как строгость остается прежней. :)

Радуюсь тому, что взгляды меняются, причем вполне обоснованно :)

UPD: Сегодня добавила в багтрекер поле Severity.
Столкнулась с тем, что отличие между полями не все понимают, и мне предлагают перед релизом менять приоритет, который у нас ранее обозначал нечто среднее между строгостью и приоритетом. На мой взгляд, ошибка не может изменить свою строгость с течением времени,а вот приоритет вполне может быть изменен и будет меняться.
Поэтому отвоевала оба поля, посмотрим, что выйдет :)

Как заставить людей развиватсья?

Стоит ли заставлять людей (читай - подчиненных) развиваться и работать над собой? А,может, не брать таких на работу после испытательного срока? Или позволять им жить в своих раковинах и делать одну и ту же работу, которую они выполняют? Я в тупике.

Иди туда, не знаю куда, проэстимейть то, не знаю что

Передо мной встал вопрос эстимейта всего тестирования нового продукта, что для меня впервые. Почитав в интернете об этом нелегком деле, так и не решила, как же мне его эстимейтить. Предлагали много вариантов:
- 0-400% от времени разработки (как-то слишком неопределенно)
- 40-50% от времени разработки (что меня тоже не устроило, потому что продукт будет разрабатывать Джуниор-программист без опыта нормальных эстимейтов)
- рассчитать примерно и умножить на два (хороший метод для больших проектов, однако если сделать так в маленьком - предполагаемый бюджет может испугать кастомера)
- привязываться к модулям и примерному количеству тестов (этот вариант мне понравился больше, однако эстимейты будут очень"примерные", потому что,как правило, тестировщику трудно увидеть все подводные камни,на которые натолкнется программа после ее реализации, а не "на бумаге").

Я проэстимейтила все вручную,разбив задание на более мелкие:
1. Выявление требований
2. Создание спецификации
3. Последующая поддержка спецификации
4. Написание тест плана
на каждый вид тестирования,который будет проводиться, было выделено время отдельно, также как и на написание плана на фичу\модуль
5. Ревью и поддержка тест плана
учитывая,что проект небольшой, для экономии времени я приняла решение, что ревьювер должен сам исправлять и добавлять тесты, просто отмечая их другим цветом, например, в экселе или просто включить Review Changes в мапе)
6. Полное тестирование первого билда
Первый проход всех тестов нвоого проекта составляет больше времени,чем следует выделять на регресионное тестирование одного билда, поэтому я выделила это время в отдельную ветку.
7. Регресионное тестирование
Обсудив с SEO количество билдов, которое предполагается в данном проекте, методом "пальцев в небо" было выбрано количество, которое составляло среднее значение между тем, на сколько рассчитывал SEO, программист и я :) Теперь я знаю, что самый большой оптимист - SEO :))
Так вот,вернемся к эстимейтам. Взяв выбранное количество билдов, я умножила время прохождения тестов по одному модулю\фиче на их количество. Исключение составили такие штуки как Инсталляция и Лицензирование - в нашей компании эти модули не тестируются в каждой итерации, так что время регрессионного тестирования на них я выделила как Время прохождения тестов модуля *Количество билдов\2.
8. Проверка багфикса.
Программист отвел себе на багфикс 1 день, что меня улыбнуло :)
Я же прикинула так - на каждый билд по 3 часа на проверку тикетов (это значение будет зависеть от сложности проекта. Мой, как я уже говорила, маленький и довольно простой).
Ну и, конечно, каждую часть множила не на два, а на 1.25-1.3, из расчета, что проект могу тестировать не я, а падаваны :)

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

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

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

Переносить задачи приходится потому, что возникают непредвиденные (для меня в момент написания плана) дополнительные задачи, например, баги от юзверей; заказчику предоставилась возможность презентовать свой продукт на конференции или тренинге,и ему срочно нужен новый билд с пофикшенными багами #x, #y, #z ("Да,я знаю,что вы должны были в пятницу выложить билд с пофикшенными 10 тикетами, но мне нужны только 5 и завтра!"); фидбек билда, запланированного на тестирование, а потом его внезапный приход, когда программист справился быстрее,чем ожидал и обещал; и т.д. и т.п, все то,с чем маленькая аутсорсовая компания сталкивается довольно часто.

Я думала о том,что было бы хорошо планировать какое то резервное время (так называемая "неопределенность") с учетом рисков, которые могут возникать, на n часов в неделю в зависимости от проектов, над которыми ведется работа. Такой подход позволил бы выдерживать эстимейты и приходить к концу недели с выполненным планом. Но в плане пустые поля уж точно будут выглядеть странно.
Строгие эстимейты, пожалуй, должны привязываться к итерациям, а не к неделям (в моей компании итерация редко длится неделю), ведь это гораздо критичней. Однако недели складыаются в итерации...

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

Думая о том, как решить эту проблему, я нашла несколько вариантов, которые имеют свои плюсы и минусы.

1. Заключение "мирного договора" между программистами и тестировщиками.

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

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

2. Приоритизация задач.
При появляении новой внезапной задачи просить ПМа приоритизировать ее (если реально сложно сделать это самому), при этом обьяснив, что работа над проектами А и В сдвигается на n дней,если делать новую задачу срочно и всеми тестерами. Здесь могут найтись новые варианты распределения людей по задачам :) Пожалуй, у этого метода минус только в том, что необходимо отвлекать ПМа от его обязанностей. А с другой стороны, он ведает всей информацией о приоритетах и планах, так что без него тут не обойтись.

3. Планирование буфера неопределенности на основе имеющейся статистики.

Собрать информацию о подобных факапах за последние n месяцев, посчитать среднее количество часов в неделю (не арифметическое) и планировать работу не на 40,к примеру,часов, а на 40 минус среднее.

Минус - все равно недостаточно точно будет :(

Крупная компания vs Маленькая компания

Работая в большой компании (~90 человек), было весело, познавательно, и тем не менее жестко. Большая компания как Голиаф - неповоротливая и негибкая, с четко выраженными характером и наклонностями. К тому же,как правило, в больших компаниях очень много времени уходит ни на что - ненужные отчеты, совещания, снова отчеты... и жесткая иерархия. Директор становится человеком, от которого зависит твоя зп, но который по факту ничего о тебе не знает, кроме имени и проектов, над которыми работаешь. Он также далек от сотрудников, как и президент страны - всегда навиду и делает,вроде,все для нас, для своего народа. :)
В этом плане маленькая компания гораздо эффективней работает: ежедневные отчеты можно заменить планом на день\два\неделю, отмеченную в экселе, мапе или любым наглядным способом. Совещания можно заменить стенд-ап митингами, этакими 15-минутками, а то и убрать вообще. Конечно,важные вопросы все же стоит обсуждать на совещаниях, но это,как правило,бывает редко. Но, на мой взгляд, ДЕЙСТВИТЕЛЬНО ВАЖНЫЕ вопросы не решаются с участием всей тимы\копмании.
Однако, в маленькой компании очень трудно развиваться личностно и профессионально, особенно, если нет кого-то, кто был бы умнее\искусснее тебя.

Рост нашей маленькой компании я воспринимаю как радостное событие, но какая-то грусть на сердце о том, что вместе с количеством новых людей и проектов появляется все больше тех минусов, которые мне не нравились в большой компании.

Вопросы для собеседования специалистов по качеству

Так как это первый пост, то я заранее хочу предупредить,что в моем блоге слова тестер,тестировщик и специалист по качеству являются синонимами. И на самом деле значат одно – специалист по качеству :) А употребляются разные слова лишь для устранения тавтологии.
Начну издалека :) Когда компания стала расширяться, стало необходимым проводить собеседования. Я, как человек робкий и волнующийся, стала гуглить на предмет вопросов при приеме на работу тестировщиков. Благо,интернет уже давно предоставляет массу информации о тестировании, как на русском, так и на английском языке.Так вот, в списках вопросов, рекомендуемых для собсеседований тестировщиков, мне казались совершенно неуместными для людей с опытом работы вопросы о том,что такое тестирование, баг, тестирование белого и черного ящика и прочая элементарная ерунда... Но не прошло и двух месяцев, как я столкнулась с тем, что, действительно,в некоторых случаях это можно и НУЖНО спрашивать.
Собеседовать людей с опытом работы оказалось гораздо сложнее, чем без опыта :)
У человека без опыта главное выявить наличие способностей к тестированию, склад ума... И, конечно же, желание учиться. Да,также важно не ошибиться с тем, что работа человеку подойдет. Ведь тестирование – это такая работа, которая несколько перевернет восприятие окружающего мира.
Люди же с опытом работы представляют собой другую категорию. Тут для меня важно понять
- что он на самом деле умеет
- стремления и вИдение своего будущего
- умение работать в команде
- адекватность,в смысле спокойствия и нормального взаимоотношения с другими тестировщиками\программистами (что особенно важно).

Еще я сама не люблю стоять на месте. Для меня остановка в развитии – это маленькая духовная смерть :) Поэтому также для меня важно знать, хочет ли человек развиваться и что он для этого делает.
На основе всего этого у меня появились свои собственные вопросы, которые мне интересны при собеседовании опытных тестировщиков (в смысле – с ОР). Некоторые вопросы являются опциональными, и,если человек хорошо ответил на несколько вопросов из категории, остальные вопросы из данной категории не считаю нужным задавать.
Итак, приступим.

Категория
1. Профессиональные вопросы.
1. Что такое тестирование?
(на самом деле определений существует несколько. Мне нравится то,которое дается по стандарту IEEE, оно самое полное). Этот вопрос позволяет определить позицию человека в тестировании. Вариантов масса. «Выполнение с целью найти ошибку», «проверка функционала на соотвествие документации» и тд.
2. Что такое баг?
Этот вопрос также позволяет определить отношение человека к тому,что считается ошибкой. Частично должно вытекать из ответа на вопрос 1.
3. Тестирование белого и черного ящика.
Да-да, к сожалению, иногда нужен этот вопрос.
4. Отличие нагрузочного тестирования от стрессового.
Просто так, чтобы узнать глубину понимания области человеком. Даже если он никогда не занимался ни тем, ни другим, ответ нужно знать.
5. Критерии выбора тестов. Методы (пути) сокращения тесовых сценариев
Человеку ведь все равно придется писать тест план,и, вероятнее всего,что он это уже делал так что...must to know.

2. История и развитие.
1. Самое большое достижение на одном из предыдущих\нынешних проектов.
Естественно, мне бы хотелось услышать о достижениях в области тестирования ПО.
Это позволяет определить,собственно, достижения, а также узнать о стремлениях человека сделать мир лучше :)
2. Баг, которым вы гордитесь.
Многое скажет о человеке. Возможно, это будет информация о хитроумности, возможно, о критичности,а,может,просто о чувстве юмора. В любом случае пригодится. Также интересно отношение человека к этому багу. Вроде как - "нашла баг,который заставил нас отложить релиз. Было весело." Хороший тестировщик понимает, что откладывание релиза - это совсем не весело. Тем более,когда такой критичный баг находят пережд релизом... Нехорошо характеризует отдел тестирования.
3. Как выглядели хранилища тестов, где проходился тест план и как можно было просмотреть результаты в каждый момент времени.
Интересно,обращает ли человек на это внимание и с чем\как умеет работать.
4. Последняя прочитанная книга о тестировании.
Мы ведь помним,что остановка –это смерть? :)
5. Блоги, которые читаешь\нравятся\не нравятся.
Следит ли человек за изменениями в сфере тестирования? Новые методы,развитие, знает ли современных наших\зарубежных гуру тестирования и как относится к их идеям\методикам\организации процесса тестирования.

Категория 3. Зачем?
1. Нередко тестеров после очередной выдачи зп посещают мысли о том,чтоб переквалифицироваться в программиста. Почему вы не перешли в программисты? Что вам нравится в тестировании?
Хочу отметить, что этот вопрос уместен в моей компании,потому что у нас специалист по качеству НЕ МОЖЕТ переквалифицироваться в программисты. Вернее,может, но не как ступенька роста тестировщика, а на общих основаниях. Для чего задавать – очевидно :)
2. Почему решили сменить место работы? Что не устраивало или перестало устраивать там?
Варианты – деньги, проекты,люди,etc... Все это расскажет о личных качествах человека. Конфликтности,его ценностях и интересах. В варианте с деньгами нужно быть осторожным – где гарантия, что человек не уйдет от вас, если ему еще где-то предложат чуть больше денег?

Категория 4. Задание
Отличным заданием, на мой взгляд, для всех тестировщиков является тестирование простого предмета, например, ручки, настольной лампы, блокнота для записей, включателя света (как у Гугла ;)... Это должно быть что-то,находящееся в комнате, где проходит собеседование, чтоб было возможно пощупать или показать что-то жестами.
Иногда такое задание ставит соискателей в тупик! А ведь тестировать можно абсолютно все, если знаешь алгоритм. Более того, это задание имеет даже бОльшую ценность при собеседовании человека с опытом работы.
Здесь для меня важно
- Уточнение(выяснение) требований
- Позитивные тесты
- Негативные тесты
- Виды тестирования, которые проводит человек
- Может ли он сам распределить свои тесты по видам тестирования, которые применяет?
- Последовательность тестов (не нужно скакать позитив-спека-негатив-позитив-позитив-спека). Все мысли у тестировщика с ОР УЖЕ должны быть рациональны и структурированы)
На практике я пока такого не встретила. Как правило, собеседуемых не торопят,и они вполне могут попросить время на обдумывание.

Вот,пожалуй,и все. Хочу отметить,что эти вопросы, не отменяют других обязательных. Это просто список вопросов, которые задаю я, и на которые мне важно знять ответ для того,чтобы охарактеризовать соискателя. Ведь у меня есть всего 1,5-2 часа для того,чтобы понять, подходит человек или нет. А время всегда должно проводиться максимально эффективно. :)