Осторожно - манипуляции или "Ты же профессионал - ты все должен понимать"

Бывают ситуации, когда чувствуешь, но не можешь с 100% уверенностью сказать, что тебя "разводят". На что разводят - не понятно, но когда развели, уже, вроде бы, ты сам принял решение, сказал - когда это сделаешь и отказываться становится неудобно и стыдно.

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

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

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

Наивная конфликтология в картонках

Сидели с коллегам за рюмкой чая. Кроме всего прочего затронули конфликты и споры в команде. Делились опытом. От коллеги по цеху прозвучал слегка наивный (мое глубокое ИМХО), но интересный способ делегирования своей команде разрешение споров.

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

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

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

Картинка номер три - нолик. Эта картонка означает, что человек просит руководителя принять решение. Т.е. человек самоустроняется и готов подчиниться воле начальства.

Картинка номер четыре - две стрелки указывают в одну сторону. Это самое приятное - коллеги приняли одно решение.

Подход напомнил мне три варианта решения проблемы: смириться, бороться и уйти но - "с поправками на ветер".

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

Если команда новая или в споре участвуют новички, то чаще случаются первые (спорим дальше) варианты.

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

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

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

Корпоративные почтовые мэмы

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

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

Сегодня о душевной корпоративной переписке.

Ролевые Игры: Аттестация, Демотивация или "Олег, ну ты же все понимаешь..."

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

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

С замечательной игрой Аттестация я сталкивался на всех этапах своего профессионального взросления. На всех 4,5 местах работы, где мне посчастливилось проработать (половина - это тот самый случай, когда человек возвращается на свое предыдущее место).  Постсоветская оборонная компания, мелкий аутсорсинг, ИТ центр крупного международного банка и стартап (затянувшийся, правда, на 10 лет) - ограниченно, но достаточно, чтобы понять какие правила хочется видеть в игре с целеполаганием и оценкой сотрудников.

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

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

Кот Леонтьева

Про Кота Шредингера знают многие.  Про кота Леонтьева - избранные.

Конференц связь. Митинг. Иностранный проект менеджер отсутствует. Русские говорят по русски. На заднем плане орет кот.

Р1: Что это?
Леонтьев: Кот. Есть хочет. 
Р2: Покорми.
Лентьев: После митинга....

Спустя полчаса митинг заканчивается. Высылаются minutes of meeting. Последний пункт:

## Feed Cat. Urgent. Who: Leontiev. When: ASAP.

Иностранный проект менеджер спустя час появляется. Копипастит письмо. Ставит критикальный флаг письму.

>> ## Feed Cat. Urgent. Who: Leontiev.
What risks do we have? How this will affect delivery dates? Do we have any workaround?

Чесно слово - я рыдал.

Цикл замкнулся

Про жизнь, которая так предсказуема.

Два джуниора тестера получают задание протестировать гуй. 

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

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

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

Новый билд. 

Джуниоры заводят по багу.

Цикл замкнулся... 

Ключевые навыки в резюме: Люблю грамотно выстраивать свою речь

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

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

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

Люблю грамотно выстраивать свою речь

Любовь к работе в слаженном коллективе

Психологическая устойчивость, отсутствие отвращения к рутинной работе

Имеется свидетельство об отличной работе

result-focused (resolved more than 1600 technical problems for last two years)

...выносливость, умение работать с документами, обширные знания в области информационных систем

Общение с людьми, обслуживание клиентов

Уверенный интернет серфер

...находить ответы на самые сложные вопросы и добиваться результата

Гибкость

Структурированность

Высоким целеполагание

тут скорее опечатка но даже если человек с "С высоким целепологанием" или у него "Высокое целепологание" выглядит тоже забавно

Моете ли вы руки до и после?

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

Человек жаловался на свою команду, которая не может точно выполнять "простые" правила описанные на вики. Рядом стоял и поддакивал другой наш коллега. Разговор шел в неформальной обстановке (как водится выпивали). И меня зацепило то, с каким пылом  Коллега №1 клял разработчиков за то, что его простые правила либо игнорируются, либо выполняются не до конца.

Небольшая предыстория. Пришел в команду Коллега №1 недавно. Полгода назад. Все, вроде бы, было неплохо. Знания получил. Процесс передачи из разработки в тестирование поставил. Начал требовать от разработчиков соблюдения Definition Of Done. Стал его расширять и в какой-то момент столкнулся с тем, что ребята не до конца выполняют все дефенишины. Причем разработчики честно признаются: правила правильные, они согласны... Но вот выполнять их целиком или постоянно то ли сложно, то ли забывают. А сами правила действительно достаточно простые  и правильные (насколько я мог судить по словам коллеги).


Коллега №2 поддакивал и говорил, что разработчики очень  не любят правила. Вообще мы, как Дартаньяны, должны за ними следить. 


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


Я: Говорите правила правильные и обязательные?


К1: Да


Я:  Без них проекту прям смерть?


К1: Ну чо передергиваешь. Они нужные и их легко выполнять. Просто все. Достаточно один раз понять и использовать. И все. Ну умные же люди. Могли бы уж запомнить. И делать.


Я: Ммм. Ты в курсе что руки нужно после туалета мыть?


К1: Ну в курсе.


Я: Моешь?


К1: Мою


Я: Всегда?


К1: Ну практически.


Я: А перед туалетом мыть руки нужно?


К1: Нужно. ..


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


Долго молча пили пиво...

Достойное рыночное качество

Вдруг вспомнилось.

Первый раз я сознательно (поездки к бабушке в Ростов исключаются, так как всегда был под наблюдением взрослых) покинул родной Ульяновск в возрасте 24 лет. Свадебное путешествие. Египет.

Даже со своим странным английским смог найти общий язык с молодым рыночным торговцем. Мы несколько раз пересекались (его магазин был напротив отеля) и в последний день перед отъездом на родину сели возле входа в его магазин и вроде бы даже пили чай. Я, глядя на его товары, искренне посетовал:

- Bad, Bad quality - тыкая пальцем в пергаменты, каменные скарабеи и прочие товары произнес я.

- It is not bad quality, - c наигранной обидой ответил парень - it is market quality.

Шикарный ответ. 

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

Достойное рыночное качество...

Когда то я был идеалистом и считал, что качество должно быть идеальным. Сейчас считаю, что качество должно быть достойным.  В канун Нового Года хочу всем читателям и просто хорошим людям пожелать Достойного Качества во всех делах! Ибо рыночное качество не всегда достойно нас самих ;)

Удачного и достойного 2012 года!

Трудности перевода

Когда то, давным давно, в далекие студенческие годы, мне посчастливилось быть курсантом военной кафедры.

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

Целая тетрадь.

Записная книжка отзаборовдообедов.

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


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

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

Задачи на сообразительность 9. Профессиональное

 

Задача на эту неделю не столько на сообразительность, сколько на рассуждение о качестве.

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

Закончил "Стили Менеджмента" Ицхака Адизеса. Второй день не дает покоя мысль, что "Бюрократы"слишком хорошо прижились в среде тестировщиков.

Как и Герой-одиночка, Бюрократ все понимает буквально. Чтобы поверить во что-то, -A-- непременно нужно увидеть это своими глазами. Он не любит рисковать...

Предприниматель, разглядев в тумане большое ухо, огромную ногу и широкую спину,  осклицает: «Ага, похоже, это слон». Он заполняет пустоты в информационном тумане с помощью  воображения и делает вывод. 

-A-- не способен к догадкам. Большое ухо, большая нога и широкая спина не станут слоном, пока туман не рассеется. И тогда, потрогав и обнюхав слона, Бюрократ недоверчиво скажет: «Хм, может быть, это и слон». 

Бюрократ считает, что, пока есть сомнения, строить догадки недопустимо.

Переводя на наш язык

Тестировщик: Бага?

Программист: Фича.

Бизнес аналитик: Фича.

Клиент: Фича.

Тестировщик: Хм... ну может быть, может быть...

Новый офис, новые баги.

Или взгляд в старом офисе был замыленный и в новом - видны все проблемы, но тестерские интересности повсюду.

На станции метро, каждый вечер одна и таже бага - реклама отваливается и виден вот такой рабочий стол винды.

Последний аргумент

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

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

Весомый аргумент в споре

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

Но все таки, заметьте, кончик аргумента слегка изогнут. Все таки кто-то очень сильно упирался ;)

Странные метаморфозы термина BUG - в маркетинге

В книге Психология Влияния наткнулся на интересный маркетинговый трюк называемый BUG. Подробности ниже.

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

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

Если бы вы могли получить то, что хотите, какую бы идеальную систему для управления процессом обеспечения качества, вы бы пожелали?

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

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

Когда я только пришел на работу, централизованно можно было только собрать совещание. Когда я уходил, проектировщики могли выгружать из своей системы данные технологам в их систему. Наши экономисты уже автоматически формировали отчетность, в том формате которую требовали бухгалтеры и финансисты. Централизовано работала электронная почта с одним доменом и службой Active Directory. Централизованно же мы закупали ПО и лицензии. Пытались влиять, опять же централизованно, на закупку/распределение компьютеров. На внутреннем веб-сайте с использованием IIS+IE+Active Directory   работала система одного окна для поисковых систем по архиву, внутренним базам данных. Было чем гордиться. Почти  пять лет я потратил на автоматизацию и объединение разрознненых систем и процессов.

И вот то же самое начало я вижу и сейчас (про то же самое я, кстати, читал и в How We Test At Microsoft): отсутствие централизации в процессе обеспечения качества, и самое главное - отсутствие единого продукта для автоматизации работы специалистов  по обеспечению  качества (и тестировщиков).

Что же мы имеем:

Excel - незаменим при построении тестовых roadmap-ов, собственно тестов и даже для создания документов.

Word - тоже полезен для создания документов. Отчеты, спецификации,... (если бы не корпоративные политики давно бы использовал только Open Office Write и Calc, кстати говоря).

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

MS Project - диаграмму Гантта никто не отменял.

HP Quality Center - хранить тесты, планировать регрессионные тесты...ну хоть что то же нужно автоматизированно готовить - хотя бы регрессионные тесты.

Confluence/TWiki/Sharepoint/ - коллективный разум должен хоть что-то после себя оставлять в виде файлов, ссылок, статей и картинок.

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

А как же все это связано? Специалистами. Вся эта кирпичная крошка густо замешана на опыте, знаниях, воспоминаниях специалистов.  Плюс еще конечно техзадания, спеки, тест планы. Но сколько храниться в головах специалистов...А сколько еще предстоит узнать...

А что бы я хотел иметь?

Я бы хотел иметь систему. Одну. Чтобы я мог сам построить workflow.  Чтобы я видел версию документа не в SharePoint, а мне приходило оповещение, поскольку я в роли тестировщика указан в данном проекте.

Хочу полноценную систему документооборота с архивом.

Хочу систему управления требованиями в том же виде, что и в Word или Wiki, но если я помечаю абзац как требование - это требование начинает жить своей жизнью: с версионностью, историей изменений, приоритетами и подтверждениями.

Хочу чтобы эти требования без циничного копи-паста оставляли свой след в системе разработки тестовых сценариев. Т.е. хочу чтобы существовала система для создания тестовых сценариев. Похожая на Excel таблицы, но каждый тестовый сценарий мог бы существовать своей, особой жизнью и также - с историей, версионностью и обратной связью к требованиям. Как это прекрасно получать traceability matrix автоматически... 

 А представьте, как прекрасно выглядят деревья тестовых сценариев с различными тегами (или категориями, или ярлыками).

А когда вы выбираете тестовый сценарий для редактирования - вы получаете Wiki систему с скриншотами  и возможностью самореализации.

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

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

О да, моя система могла бы многое. Если бы вы спрашивали о фиче1, вам бы предлагали фичи, который рассматривались с этой фичей раньше (фича66, фича121).

Моя бы система на вопрос о environment ошибке предлагала бы контакты суппортеров и workaround. Более того, она сама бы рассылала сообщения суппортерам. Ты звонишь по контакту, а он, какое чудо, занимается твоей проблемой уже почти три минуты.

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

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

Моя система сама рассылала бы QA Daily Report и табель.

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

Моя система была бы идеальна...

Именно поэтому бы ее никто и не смог использовать.

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

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

И все таки, если уж понеслась такая ярмарка...

Моя система управления процессом обеспечения качества была бы OpenSource.

Моя система была бы модульной и позволяла бы внедрять себя поэтапно. Строилась как конструктор.

Моя система могла бы расширяться пользователями и иметь свой собственный язык программирования, либо позволяла дописывать себя на любом языке, либо встраивать плангины. Либо позволяла делать и то и другое и третье.

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

Карма тестировщика

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


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

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

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

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


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

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

Подводя итог.

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

Это бывает даже очень весело.

Хотя, бывает и немного больно - нос еще побаливает.

Вы хотите тестов? - их есть у меня...

На днях услышал байку. Про тестировщиков. Про русский менталитет и стремление к идеальному, индийскую смекалку и понимание клиента.

Чтобы не раскрывать всякие коммерческие секреты именую всех просто: pападный хозяин (клиент), работник в русском офисе (русский значит), индийские аутсорсеры.

Было у русского работника 200 тест кейсов. Хороших, продуманных тест кейсов. Хозяин возьми и скажи ему: "А сделай в два раза больше тест кейсов и - за неделю".

Русский работник привык все делать хорошо и продумано. Поскольку времени на прогон тестов не увеличивали, то зачем создавать новые тесты, rогда времени на поддержание старых хватало впритык? Что именно расширять русский работник знал, но требовала эта работа месяц - не меньше.

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

Индийцы: "Да, не вопрос".

Через неделю 400 тестов протестированы силами двух индийцев.

Русского сотрудника ругают и переводят в другой проект. Индийцам перепадает проект и перспектива более близкого будущего отношения.

А что собственно сделали индийцы...

Во-первых они разделили 200 тестов на 400. Грубо каждый тест на два.

Во-вторых они протестировали не 400 тестов, а 100 - в случайном порядке.

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

Намечается парадокс.

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

2. Русский проявил упорство и настойчивость (поскольку думал как нужно делать правильно), но получил нагоняй.

Есть конечно вопрос о профпригодности заказчика (ну или его представителей). Но задача была поставлена - кто с ней справился, то и герой.