Искусство подбора персонала. Светлана Иванова

Ссылка на книгу (Издательство "Альпина Паблишер").

Мои выдержки из книги:

• Почему студенты задают много вопросов по второму и третьему разу?
• Я не волшебник, я только учусь.

Как оценить человека за час. Сложно что-то добавить, если описывать книгу кратко. Мне вообще нравятся книги Светланы Ивановой, она интересно пишет. Хотя, честно говоря, "Мотивация на 100%" впечатлила больше. Но тут зато сжато и лаконично именно про собеседования.

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

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

И вообще закладочек себе разных сделала. Светлана учит определять:

• Тип референции — Внешняя или внутренняя. Вы считате себя хорошим сотрудником? А почему? "Потому что я круто делаю то и то" (внутренняя, от себя зависишь), "Начальство хвалит, заказчики довольны" (внешняя, от других).
• Стремление — избегание. Смотреть, что преобладает в речи и делать выводы, когда идет отклонение от нормы.
• Процесс — результат.
• Процедуры — возможности.
• Сходство — различие.

Узнать все эти детали можно с помощью вопросов. Для типа референции я привела, остальные извлекаем из анализа речи кандидата с помощью лингвистического анализа. Главное — задавать открытые вопросы, которые не намекают на ожидаемый ответ. Например, "опишите ваш 1 рабочий день, если мы вас примем" вместо "Что вы будете делать... ?"

На собеседовании можно использовать проективное интервью, case-анализ, метод трех плюсов... Много всего! Читайте книжку и узнаете подробности 

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

Я уже попробовала попрактиковаться! Сначала на коллегах, а потом на студенте. Коллеги все единошные оказались, со внутренней референцией и ориентацией на интерес и инновации в работе. И так удивились, узнав, что есть люди с внешней референцией. "Да ты что? Зачем на мнение других людей оборачиваться? А если все вокруг меня дебилом считают, это разве что-то говорит?!", — преисполенный негодования, вопрошал мой коллега ))))

Даже странно было признать, что у меня смешанная референция в этом плане:

• Работа — я делаю работу хорошо и Заказчики довольны.
• Тренер — я постоянно улучшаю свой курс и студенты, дошедшие до выпуска, оставляют хорошие отзывы.

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

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

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

Нам, наверное, хорошо, когда вокруг все думают так же, как и ты. Одна я в нашей комнате неправильная какая-то, и как они меня терпят? 

В общем, книжка очень крутая, рекомендую всем, кто проводит собеседования!

На любую позицию, это все неважно. 100% узнаете что-нибудь новенькое. А как закончите читать, обязательно потренируйтесь на коллегах — весело, интересно и познавательно 

PS - Добавила книгу в общий список прочитанных мною книг.

Лайфхак. Как уговорить разработчиков начать писать автотесты

Обсуждали в чате со студентами, как писать автотесты. После гугления возникает мнение, что начинать надо с Selenium и GUI тестов. Но это же не так. Какой в них смысл, если ничего нет на уровне ниже?

Начинать надо с unit-тестов, которые пишут разработчики. Потом писать тесты на уровне API. Чем они хороши, я рассказывала в этом докладе. А потом уже заавтоматизировать через GUI минимальную часть. Но тут возникает проблема...

Проблема

Unit-тесты у нас никто не пишет, а к мнению джуниоров мало прислушиваются. 
Особенно разработчики. Как их убедить начать?

Лайфхак

Лайфхак подходит только в ситуации мальчик-разработчик и девочка-тестировщица!

А вы выберите самого умного разработчика (или самого дружелюбного, по ситуации), принесите ему блинчиков на масленицу и скажите:

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

Главное — похвалить! И накормить 

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

И разработчику не сильно внапряг заниматься "не своим делом", один тестик много времени не займет. И вообще не надо разработчикам давать тестами код покрывать, знаем мы их "покрытие" (поучительная история).
.
Написали unit-тесты, просите фреймворк для API. Джуниор его полгода будет пилить, а разработчик за день сделает. Особенно если никто не будет его просить еще и тесты туда добавлять 

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

Так что я к нему пришла с вкусняшками:

— Здравствуй, Васенька! Хочешь конфетку?
— Ух ты, спасибо! *довольный, жует*
— Слууууушай, я тут хочу на конференции выступить... *ручки за спину, взгляд — сама скромность*
— Ну и что?
— А было бы так здорово показать им реальный код! Представляешь, скачал — и оно все само запустилось! У нас же такие классные тесты, я бы вот это и это показала...
— *Взгляд становится настороженным* А от меня ты что хочешь?
— А можешь сделать мне такое тестовое приложение? Я вообще не знаю, с чего начать! А ты у нас ТАКОЙ умный, любую сложную задачу как орешки щелкаешь! (это правда, он умеет за пару часов сделать то, что казалось невозможным)
— *Гордо приосанивается* Ну да, это так.
— Ну вот! Я уверена, что у тебя такая задача буквально часик займет, ты же так быстро все делаешь! А я одна не справлюсь (((( Помоги мне, пожалуйста! А я тебе котлеток сделаю))))
— Ну лааадно, давай посмотрю...

Приложение он мне написал 
Котлетки свои тоже получил ))) Тут главное было — подойти заранее, я пришла с просьбой за полгода до выступления и где-то через месяц у него дошли руки сделать мне folks. Так что лайфхак вполне реальный 

После обсуждения лайфака в чате студенты попросили: Ольга, пишите еще в блог такие небольшие лайфхаки от себя, мелочь, а джуниорам полезно и не все очевидно!) Я бы с удовольствием читала.

Так что вот — пишу! Появился лейб "лайфхак", ну и в названии будет мелькать, если влезет)))

Я не волшебник, я только учусь

Позавчера одна из моих студенток показала картинку:

Она очень боялась, что не пройдет курс, но справилась!

А еще за день до этого я прочитала в книге Светланы Ивановой "Искусство подбора персонала" замечательную цитату:

ЗНАНИЕ и НАВЫК — принципиально разные вещи. Для того, чтобы НАУЧИТЬСЯ применять все те методы, которые мы рассмотрим, надо много ТРЕНИРОВАТЬСЯ и осваивать их ПОСТЕПЕННО, выбрав для начала те подходы, которые наиболее актуальны именно для вас, в дальнейшем добавляя все новы и новые методы и подходы.

Подходит к любому обучению, не только к материалу книги.

Мои студенты переживают, когда не получается красиво оформить чек-лист или правильно сформулировать название для бага. Но это не беда. Когда что-то не получается — это абсолютно нормально! Именно ради этого мы и приходим на курсы — чтобы оступиться и подняться под присмотром тренера.

Какой смысл платить деньги за курс, на котором все задания выполняются с первого раза и ничего нового не узнаешь? Нет, фишка обучения именно в том, чтобы начать тренироваться. Начать нарабатывать НАВЫК, имея хоть какое-то ЗНАНИЕ.

При этом обратите внимание на слово "постепенно" → все сразу вы не усвоите при всем желании. Именно поэтому в статье "Что делать после окончания курсов для начинающих тестировщиков" я рекомендую не проходить новых курсов ближайший месяц после выпуска. Сначала надо дать устояться тем знаниям, которые уже получены. Попробовать их поприменять в реальной работе, попрактиковать. Иначе это все просто забудется. Да, классно и здорово узнать за один раз много нового. Только через неделю 90% забудется. Учитесь постепенно.

Выпусники курсов делятся своим опытом, как нарабатывать навык на работе и дома:

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

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

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

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

Для студентов я — крутой гуру, который давно варится в области тестирования. Но для Максима Ильяхова я — простой студент, который делает глупые ошибки. Да, да, я тое не идеальна! 

Я прошла курс по информационному стилю и редактуре текста и теперь учусь писать полезные блог-посты в инфо-стиле. Получается не всегда. И не сразу. Далеко не сразу. Примеры:

• Что такое тест-кейс — Статью писала 2 недели. Писала, а потом по комментариям коллеги переделывала. И так несколько раз.
• Как заводить задачи — Написала статью еще на курсе по инфостилю. Потом доработала, принесла на встречу-обсуждение (проводятся в коворкафе раз в месяц). Тестировщиков в кафе не было, но пара ребят сказали мне "СПАСИБО! Очень полезная статья!". При этом по редактуре комментариев набралось штук 15 :) Переделала. Потом еще раз и еще. В итоге спустя месяц принесла на очередную встречу, опять получила фидбек "Крутая статья! Я уже узнала много нового", но опять набрали комментариев по редактуре. Перед публикацией снова дорабатывала.

Хорошие вещи не делаются с полпинка и с первого раза  Эта мысль утешает меня ))))

В следующий раз, когда будете в 10 раз переделывать очередной ДЗ на курсе, помните — вы не одиноки! Мы все чему-то учимся и все ошибаемся и переделываем, и переделываем, и снова переделываем. Это - нормально. Смотрите на картинку и помните о цели. И все будет хорошо 

Как заводить задачи в баг-трекер

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

1. Выберите тип

Разработчики не боги, они не могут делать все и сразу. Им нужно понимать, с чего начинать. Они сортируют задачи по типу — сначала новые функции, потом ошибки, потом все остальное.

Какие бывают типы задач:

• Баг — ошибка в программе.
• Улучшение — все ок, но хотим с перламутровыми пуговицами.
• Новая разработка — такой возможности нет, а очень хочется.

Допустим, заказчик захотел новую возможность, а вы завели ее не как новую возможность, а как баг. Разработчики весь месяц делали другие новые функции, и до вашей не добрались. Заказчик в ярости: вы же обещали... А виноват постановщик задачи — умей выбирать тип!

Баг	Улучшение	Новая разработка
Ошибка 500 при загрузке xlxs файла	Загружать файлы драг-н-дропом	Возможность грузить сразу несколько файлов
Город “Москва” исправляется на “Масква”	Выводить код ФИАС в результатах разбора адреса	Обработка иностранных адресов
Нет подсказок по букве "Б" на английской раскладке	Распознавать не переключенную раскладку в подсказках для email	Транслитерация в подсказках
При загрузке файла большого размера сообщение об ошибке “некорректный тип”	Увеличить ограничение на размер загружаемого файла до 30Мб	Загрузка файлов формата .djvu

Осторожнее с ошибками. Разработчик не любит слышать, что в его детище что-то не так. Он будет топать ногами и кричать “Это не баг и исправлять его не надо”. Финт ушами — ставьте улучшения вместо некритичных ошибок.

Системный архитектор реагирует на появление ошибки

2. Локализуйте проблему

Локализация — это поиск первопричины.

Не торопитесь заводить конкретную проблему, это ниточка. Потяните за нее и распутайте весь клубок. Если этого не сделать, разработчики исправят последствия, а исходная проблема останется.

Почему студенты задают много вопросов по второму и третьему разу?

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

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

Выдержка из книги:

В качестве провокации я использовала такой вопрос: "Почему так много тупых пользователей?". И четко увидела три принципиально разных варианта реакции кандидатов:

— тема поддерживается с огромным энтузиазмом (один из кандидатов даже рассказал мне, что у него есть собственная классификация тупых пользователей);

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

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

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

Пример из книги:

— Как вы прокомментируете то, что пользователи задают много вопросов по второму и третьему раз?
— Это в принципе нормально, не каждый человек понимает сразу то, что ему объясняют.
— И почему не понимают сразу?
— Да не стараются  понять, проще меня еще раз дернуть.

Я много общаюсь с пользователями. Как по работе, так и в виде тренера. Своих Заказчиков очень люблю, поэтому читать эти примеры было смешно.

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

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

Дзэн и искусство ухода за мотоциклом. Роберт Пёрсинг

Ссылка на OZON.

Роман о качестве. Как тестировщик, я просто не могла пройти мимо 

Автор рассказывает, как отправился с маленьким сыном в 17-дневную поездку на мотоцикле. В процессе езды он устраивал "нечто вроде шатокуа". Шатокуа — традиционный слет учителей и ораторов с публичными лекциями, концертами и театральными постановками (по названию озера Шатокуа в штате Нью-Йорк, где такой слет впервые провели в 1874 г).

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

Мне понравилось, как автор начал уходить в философию. Едет он с друзьями в поход на мотоциклах. Он изучил свой мотоцикл вдоль и поперек и чинит его сам. После того, как "специально обученные люди" на его глазах чуть не разломали машину напрочь. Увы, такие "профессионалы" есть в любых сферах деятельности. А друг главного героя к своему мотоциклу прикоснуться боится. Только механики, "сам не полезу".

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

Это очень похоже на тестирование. Если заметить только саму проблему, не докопаться до ее первопричин, то фикс не поможет. Ну удалят сорняк с поверхности, не затронув корень, он вырастет снова, причем в другом месте.

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

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

Все решения просты — после того как их найдешь. Но они просты, лишь когда знаешь, каковы они.

Подходит не только для тестирования, но и для обучения. Моих студентов периодически клинит на простых вещах. Когда мы вместе выводим ответ, они сильно удивляются "Это так просто! Почему я сразу так не сказал(а)?".

А в тестировании? Нашел проблему, не можешь локализовать. Ищешь, ищешь, ищешь... А потом находишь элементраный ответ! Но он элементарен только тогда, когда ты его уже знаешь.

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

Есть много ловушек сметки. Это и мандраж, и скука, и многие другие. Особое внимание хочется остановить на скуке. Если заскучал — прервись! Отдохни! Попей чай, кофе, погуляй, сходи в кино, поспи. Все, что угодно, только прервись. Иначе результата не будет.

В общем, много хороших мыслей в книжке. И полезных 

Но до чтения "Дзена" надо дорасти. Мне книга далась тяжело, потому что философией как таковой я не очень увлекаюсь. Я слышала вдохновенные отзывы о том, как читаешь роман и проникаешься идеей и рассчитывала на книгу аля "Цель". Вот там читаешь увлекательную историю и умудряешься делать мудрые выводы. А тут читаешь не сильно увлекательную историю, потому что истории как таковой мало, большинство времени отдано под шатокуа.

Но тут уже "на вкус и цет все фломастеры разные" ©

PS - Добавила книгу в общий список прочитанных мною книг.

Денежный тур (The Money Tour)

Предисловие

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

В ПО аналогично — у пользователя должна быть веская причина для покупки конкретного продукта. Найдите "продающие" функции приложения. Спросите маркетологов, которые проводят демонстрации. Узнайте у них, что нужно пользователям!

Тестировщик денежного тура:

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

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

Мощная вариация тура — Тур Скептичного Заказчика (Sceptical Customer Tour). Выполняем Денежный Тур, но представляем, что Заказчик постоянно останавливает демонстрацию и спрашивает "Что, если..?".

• Что, если я захочу сделать так?
• Как я должен делать это?

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

Цель тура: найти функции, которые заставляют людей тратить деньги на ваше ПО и проверить их работу.

В Дадате пользователи платят за:

1. Стандартизацию данных через файл или API.
2. Подсказки.

Начнем со стандартизации.

Проверяем все, что связано с деньгами? Пополним счет, обработаем файл и проверим списание средств? Неверно! Туристы приезжают посмотреть на пирамиды, а не отдать деньги экскурсоводу. Конечно, будет печально, если их не пустят внутрь, так как сломался аппарат приема денег. Но это не главное в туре. Нет пирамид — неважно, работает денежный аппарат или давно сломался.

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

Итак, какая проблема у пользователя? Есть клиентские данные, записанные абы как. Необходимо привести их к единому виду и исправить опечатки.

Пользователь платит за то, что:

• Данные стандартизируются — нужно побольше разных кейсов придумать, в каком виде эти данные могут поступать. Например, в исходной системе на форме ввода адресов надо вводить отдельно город, отдельно улицу и т.д. Для обработки в Дадате система склеивает адрес из кусочков. Это могут быть разные разделители (точки, запятые, пробелы), могут быть разные обозначения полей “ул. Московская”, “улица Московская”, “Московская улица”. И я как пользователь хочу платить деньги, зная, что Дадата справится с моим форматом выгрузки.
• Данных может быть много в ширину — Ну вот мои пользователи заводят по 10 адресов и 10 телефонов! Дадата должна их обработать, а не отрезать “лишние” колонки.
• Данных может быть много в высоту —200 тысяч разных данных в одном файле тоже не должно стать проблемой при наличии денег.

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

Не путайте денежный тур с туром оплаты. Лучше вспомните о вариации скептичного Заказчика:

— А что, если я загружу файл txt, но в формате csv?
— Мы все обработаем, смотрите! *демонстрация*

— А что, если у моих пользователей по 5 адресов? Вы можете осилить только один?

— Нет, что вы, ограничений пока нет, загружайте все!

— А что, если в фамилии мои операторы часто опечатываются?

— Мы исправляем большинство опечаток, давайте посмотрим на вашей тестовой выборке?

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

И только после проверки функционала стоит убедиться, что пользователи смогут за него заплатить. Теперь обратим взор непосредственно на деньги:

— Можно пополнить баланс из личного кабинета.

— Можно пополнить баланс, начав грузить файл (если средств для обработки хватит только на половину).

— Скидки работают, но не применяются внутри одного файла (если обработали 120 тысяч, цена 9 коп начнется со следующего файла)

Функционал проверили, деньги проверили. На этом всё.

Теперь перейдем к подсказкам.

Внимательно читаем продающий текст на странице и делаем выводы, за что платят пользователи.

И опять начинаем с функционала. Нам не нужны хитрые классы эквивалентности “а что, если ввести китайские иероглифы, спецсимволы…?”. Думайте о позитивных сценариях. Думайте о том, что будете показывать на демонстрации, чем будете гордиться? “А еще мы умеем так и вот так!”. Если вы разрабатываете продукт, вы наверняка знаете о том, что он умеет.

Но если вы пришли на середине проекта, и у вас нет идей, то вспомните о скептичном Заказчике и попробуйте ответить на все его “а что, если…”:

— А что, если я введу короткое имя? У меня в классе училась девочка Янг!

— А что, если я введу составное имя?

— А что, если я знаю только название организации? Понятия не имею об ИНН, ОГРН и прочих вещах?

— А что, если я не помню точное название улицы?

— А что, если… ?

И только проверив тот функционал, за который стоит платить, убедитесь, что за него можно заплатить. Пожалуй, все! Хотя задачка не для пары часов, а для нескольких сессий! А ведь казалось бы, просто денежный тур…

<< Тур по путеводителю. The Guidebook Tour

>> Тур по ориентирам. The Landmark Tour

Вернуться к полному списку туров

PS: Статья написана в помощь студентам моих курсов по тестированию. Изучайте новое, не стойте на месте!

PPS: Статья сохранена на Testbase, чтобы не потерялась ссылка.

Exploratory software testing. James Whittaker

Книга на Amazon.

Must read для тестировщика! Причем любого уровня:

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

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

Мои заметки по книге — Как искать баги — исследовательские туры Виттакера.

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

Из особо понравившегося в книге:

The price of entry is low, but the road to mastery is difficult

Стать тестировщиком может каждый. А вот стать мастером в своей области — это надо уметь!

Интересный факт о тестировании игр для XBox - там много всего скрыто (hidden элементы). Программисты выводили всю скрытую информацю в игре, чтобы тестировщики видели, на что влияют их действия. Это помогало им тестировать быстрее и умнее. Очень любопытный пример, хорошая практика!

А как тренер, я не могла пройти мимо этой цитаты:

However, i would add that no matter what practical experiance you may have, you never really know a subject until you have to teach it. There are so many nuances to engineering endeavors that we don`t think about except at an intuitive level. Having to explain those nuances to someone else is a lot harder than it sounds.

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

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

Или даже когда выступаешь на конференции. Вот вроде знаешь, как идет процесс в компании. Знаешь, как пишутся автотесты. Но, когда это надо объяснить "с нуля", начинаешь понимать, как много ты еще не знаешь. В итоге как в том анекдоте:

Ну и глупые школьники сегодня попались! Объяснил тему — не поняли. Объянил еще раз — не поняли. Объяснил третий раз — сам уже понял, а они не поняли!

Так что просто попробуйте объяснить свежевыученные знания другим. Устройте мини-конференцию или обучение у себя в компании. Коллегам приятно, и вам полезно!


С разрешения автора я публикую в блоге вольный перевод 4 главы его книги, посвященной собственно турам. Но настоятельно рекомендую прочитать всю книжку. Там ведь не только 4 глава. Есть много другого интересного. Есть опыт применения этих туров в Microsoft, есть невыпущенные статьи, размышления на тему будущего тестирования, есть... Да много чего есть. Прочитайте и узнаете!

PS - Добавила книгу в общий список прочитанных мною книг.