Хочу высказать огромную благодарность Татьяне Зинченко за такой прекрасный курс!
Для человека, пришедшего "с улицы", полный кладезь информации. Которая к тому же подается в легкой и непринужденной манере. На Таниных лекциях некогда скучать, потому что параллельно докладу идет живое обсуждение в чате. Причем и сам преподаватель смотрит в этот чат! И как она все успевает?
Удержать внимание аудитории - большой труд. Не говоря уже о такой придирчивой аудитории, как онлайн. И Тане это удавалось! Вообще ее манера объяснять сложные вещи простым языком широко известна еще с выступления на SQA Days 10.
Я записалась на данный курс, еще ничего не зная про SQL, зато зная про ораторские способности тренера. Однако к моменту начала курса (а записалась я месяца за 3) я уже выучила основы основ. Но что поделать? Деньги уплочены, вдруг что-то новое узнаю?
И вы знаете? Узнала! Особенно меня порадовала последняя лекция, про SQL-инъекции. Вот уж что-то, а этого я не знала. Было безумно интересно и полезно. И сразу же возникло желание потыкать свое приложение, что вообще очень важно на тренингах - желание применить знания!
Вот казалось бы, да? Первые несколько ДЗ я решала вообще без запуска командной строки. На win 7, да еще и 64-разрядной вообще случаются казусы с установкой... В общем, я не заморачивалась, а просто открывала код создания БД и, читая его, отвечала на вопросы.
И все равно! Я почерпнула много новых знаний! Даже имея некие знания про группировки, общаясь сейчас постоянно с ораклом, я услышала нечто новое (и не только в последней лекции, просто там все было неизведанным).
Поэтому, ребята! Хотите знать больше? Побалуйте себя! Сходите к Тане, она вас многому научит. Даже если вы считаете, что и так знаете достаточно :)
Если вы хотите записать красивое обучающее видео, то можно использовать программу Wink.
Также очень удобно записать свои действия для разработчика, вставив комментарии "Тут мы нервно дергаем левой кнопкой мыши и у нас получается...", "бага! Вот тут надо поправить текст на ..."
Как это сделать?
1. Запускаем программу
2. File - New project
3. В открывшемся окошке ставим галку "Hide Wink Window"
4. Далее выбираем в выпадающем списке "Window", если нам не надо записывать весь экран, допустим, мы хотим сделать запись Notepad ++.
5. При выборе "Window" разблокировалась кнопка "Choose".
Задачу в helpdesc поставили, админ сделал свой magic и появилась у Заказчиков возможность писать нам в общий доступ, так сказать. Чтобы каждый вопрос видела вся команда, а не только ее часть, подписанная на customer@support.
В итоге мы начали активно использовать галочку "Restriction to Workers", дабы попрятать комменты, не имеющие смысла для Заказчика. И даже скрыли от него закладку "Журнал работ" (где ты пишешь, сколько времени потратил и на что, и было ли это интересно), зачем ему смотреть наши ворклоги?
Однако я ходила и думала... Вот, скрыли мы свои комменты "Ага! А я говорил - потестить внимательно!!", "Да тестила я!!!". В джире их не видно будет... А вдруг email нотификации придут? о_О
Не доверяю я задачкам, закрытым без тестирования ))))
В общем, думала, думала, пошла к админу, докопалась - проверял? Нет.
- Давай Никите доступ.
Прихожу к Никите:
- Поздравляю, ты - Заказчик! Ставь мне таск.
- Ок, не вопрос, под кем логиниться?
Создали таску, я пошла ее покомментила, что-то простым комментарием, что-то "спрятанным". Ну и ворклоги заполнила. Посмотрели на пришедшую почту - уф, с комментариями все хорошо. А ворклоги приходят! Кхе кхе кхе. "1 час, нейтрально, пыталась воспроизвести проблему". Ну бывает же такое, когда не воспроизводится? А представьте, такое сообщение Заказчику уйдет?
Таааак, бегом к админу! Снова magic, снова я химичу с тестовой задачкой и иду к нашему "Заказчику", который коллега.
- Ну, что пришло?
- А что, должно было что-то?
- Ага.
Смотрим. Пришло только "этот коммент будет виден" и "этот тоже".
- Ура, закрываем!
- А что, ты что-то еще писала?
- А ты под собой зайти и посмотри Activity Stream :)
Зашел... Похихикал :)) Читается оно снизу вверх, если что...
Мораль сей басни такова - не доверяй сторонним программам! Их тоже надо тестить...
Раз пошла такая пьянка - публиковать отчеты ребят, которые восхищаются летней школой, но не ведут собственных блогов...
Отзыв Павла Волкова! Встречаем:
Летняя школа тест-дизайна - отличный способ получить новые знания от двух, одних из самых авторитетных, людей связанных с тестированием: Алексеем Баранцевым и Натальей Руколь. Так я думал, когда подтверждал свое участие в мае.
Я ожидал, что в школе будут, в основном, младшие тестировщики, что оказалось не так. В качестве бонуса к замечательным тренерам, я получил больше 20 опытных и дружелюбных тест-лидов, или близких к этой должности людей.
Процесс обучения проходил легко и непринужденно. Утром и вечером.
Утром, Алексей рассказывал про методы создания тестов и отвечал на наши вопросы.
А вечером Наталья пыталась донести до нас, в игровой форме, важные в тестировании и разработке вещи.
Коллектив школы мне очень понравился, и я буду рад их видеть в дальнейшем - на конференциях, тренингах и пьянках. Привет, Андрей.
В целом, все прошло очень хорошо. Я получил ответы на все свои вопросы и +200 опыта.
Ну не смогла я, не смогла (с)
Начала читать... Остановилась на 37 странице. Не могу. Не нравится. Вообще, от слова "совсем".
Вступление какое-то... Такое... Знаете... Как будто меня в секту приглашают. "С помощью этой книги вы сумеете" и бла-бла-бла... Я честно пыталась. Тем более, что на обложке этой книги нарисована схема, про которую недавно Андрей Дзыня рассказывал. Про то, где в итоге "отложи или делегируй все, что занимает больше 2 минут". Может, он поделится своим впечатлением от книги))) Может, она все-таки интересная? Где-нибудь там... потом...
Просто сегодня, идя домой, я подумала о том, что ничего из этих 37 страничек не запомнила. Совсем ничего. Вначале хотела дочитать, да просто чтобы мнение о книге в целом составить. Но... Вот уже второй день я в метро закрываю книгу на полпути и сижу медитирую. А ведь интересные книжки читаешь всю дорогу... Так какой смысл ковыряться в книжке, которая тебе не нравится?
В общем, возможно, когда-нибудь... Я к ней вернусь. Мне, в конце концов, и Глеб Архангелький не понравился, когда я его в магазине полистала. А начала читать - и прониклась. А тут ни полистать не интересно, ни начать читать... Эх. Смотрю на надпись "мировой бестселлер" и мне кажется, что я чего-то не понимаю просто...
Может, кто-то выскажет противоположное мнение и я вернусь к ней раньше, чем планировала?)
Читала я ее весьма скептически настроенная. Первый пример, разбор письма Ваньки из чеховского рассказа меня не особенно впечатлил. Однако стиль повествования у автора легкий (внезапно, да?), поэтому дочитала я книжечку с удовольствием. Она, кстати, довольно тоненькая, на "3,5 часа" по оценке издательства. Эту оценку я комментировать не буду, так как быстро читать не умею.
Вот, казалось бы, "прочитал и забыл" каждую главу. Однако на следующий же день после "Вот тут я дал, в натуре, маху" мне надо было написать Заказчику о том, что я ошиблась в оценке и фишечка будет готова в следующем релизе, не в текущем.
Ручки сразу потянулись к сумке... Нашла пример, посидела, подумала... Написала письмо.
Вот тогда то я и поняла, что все "такое простое и элементарное" ни разу не елементарное, как до дела дойдет. И это очень здорово, когда под рукой есть такая "книжка-подсказка". Надо попросить об услуге? Открой пример, посмотри. Надо признаться в ошибке? Открой пример, посмотри. Надо извиниться за что-то? Ну вы поняли...
Я считаю, что книжку надо обязательно прочитать всем, кто ведет переписку с Заказчиком. Ну и всем остальным - мало ли, привалит счастье. А вы уже знаете, где подсказки искать :)
Как обычно происходит support, или поддержка пользователей?
Обычно есть некая горячая линия, которая отвечает на вопросы конечных пользователей. Но, помимо них, есть еще и непосредственный Заказчик. Который вначале проводит приемочное тестирование, а потом уже отдает продукт своим пользователям.
Кто же общается с Заказчиком?
1. Аналитики
Ну, казалось бы, а кто еще? Аналитики пишут ТЗ, согласовывают его с Заказчиком, рассказывают разработчикам, что им надо сделать... Дают ответы на бесконечные вопросы тестировщиков, утрясают проблемы со сроками и многое, многое другое...
Но бывают и другие варианты...
2. Тестировщики
Ну а кто еще так знает продукт, как тестировщик? :) Логика опять налицо. Тестировщик - последняя стадия продукта, его последний этап. Он знал его на этапе требований, а теперь он докапывается до сути реализации. Ну кому еще отвечать на вопросы "а какие параметры можно отправлять через soap-запрос в этом методе?"...
Разумеется, бывают и другие варианты. Особенно в agile - командах, где нет четко выраженных аналитиков или тестировщиков. Но нас то интересует именно второй вариант, правда ведь?
Чем хорош такой подход?
Разнообразие - ты не ограничиваешься рамками "сел и потыкал", ты порой сам пишешь и согласовываешь ТЗ (ну а что делать, если оно непонятно написано?). Спектр твоих обязанностей расширяется и разнообразия в работе хватает с головой.
Быстрый feedback - обратная связь всем нужна, всем важна. Как иначе узнать, понятное у вас описание в википедии или не очень? У Заказчика нет Аналитиков/разработчиков под рукой, ему похуже будет...
Рука на пульсе - ты всегда знаешь, какие баги есть на предпродукционной платформе, удачно ли прошел релиз? Ведь кто "яйца на бочку" кладет ((c)Андрей Мясников), подтверждая, что ошибок в релизе нет, он - готов? Тестировщик! Кому, как не ему, первому узнать о проблемах пользователя?
Быстрый ответ - Заказчик тоже хочет быстрой обратной связи. И если у него есть проблема, он хочет знать, откуда она и когда ее поправят. Уверена, что тестировщик тоже очень хочет это знать, тут их интересы совпадают.
Соответствие ожиданиям - вы сталкивались с ситуацией "сломанного телефона"? Когда реализовали одно, а выяснилось, что нужно было совсем другое? Ситуация была очень ярко показана в ролевой игре в летней школе тестировщиков. А, чтобы такой ситуации не было, тестировщику надо знать, что нужно Заказчику. Какие у него возникают вопросы и пожелания. Как он пользуется системой...
В общем, сплошные плюсы. Назначаем тестировщика ответственным за customer@support и радуемся жизни. У менеджеров появляется время на более важные дела, а тестировщики держат руку на пульсе.
Казалось бы, все хорошо? НО! Подумайте сами о минусах такой почты...
1. Как обрабатывается заявка? Чтобы она не потерялась "где-то в почте у коллег", создается task в баг-трекере. В который аттачатся письма, в котором идет обсуждение, что ответить, что сделать итд.
Теперь представьте себе длинную переписку. И ее отображение в комментариях... Тут, как говорится, "лучше один раз увидеть".
2. А если тестировщик забыл приаатачить письмо? Дел много, главное - ответил, остальное ерунда. По прошествии времени сидит, смотрит на задачу - "блин, что-то же делал,а что?". Лезет в почту, ищет, аттачит... Время - деньги!
3. Тестировщик заболел / ушел в отпуск. Его Заказчика радостно передают другому. У этого другого информации - все, что в джире было. А ведь половины и не было (чтобы не раздувать комменты). Что делать? Куда бежать?
В общем, так подумаешь, подумаешь... И поймешь - надо Заказчиков в баг-трекер переводить!
Создать специальный тип задач - Support Request. И пусть пишут вопросы туда. А ответственные (читай - тестировщики) будут отвечать. Но одно дело - ответить на 2 строчки, а другое дело, переслать письмо, где эти самые две строчки окаймляют "Кто? Кому? Кто в копии? Тема письма", а также подписи.
Всем хорошо! Все плюшки подхода остались, а минусы решились! Добавилась информативность - теперь вы всегда в курсе, что происходит на проекте, даже если не входите в почту его support-a. И легко можете заменить коллегу.
Но! Опять это "но", будь оно неладно.
Ребята! Подумайте заранее. Ну если у вас уже есть такая почта. И в джире (возьмем как пример баг-трекера) уже есть куча тасков, созданных по этим письмам. Подумайте заранее о возможном переходе Заказчика в джиру!
А если не подумать? Зачем Заказчику вообще этот переход? Все за тем же - чтобы можно было следить, решают ли твои проблемы, чтобы можно было ссылаться на "а вот в этом письме (в этой задаче) мы говорили о том, что...", чтобы можно было отслеживать ход работ, в конце концов.
Так вот. Все Заказчику видеть явно не надо. Только свой проект и только такие запросы. Но старые запросы ему видеть интересно. А иначе какой смысл? Часть переписки - в джире, а часть - в почте.
Итак! Добавили права, открывать доступ к багам. В принципе, в той же джире это сделать несложно. Казалось бы. Особенно, если в заголовке задачи честные тестировщики указывали магические буковки "CR", ну или что-то похожее, чтобы можно было найти махом все задачи с приаттаченными письмами. В той же джире можно выделить все эти таски и парой щелчкой мышки поменять им уровень доступа.
Ура? Агащаз. Сначала багу открой и почитай комменты.
А что мы пишем в комментах?
"Хихи, наконец-то они поняли, что это неудобно"
"Да вы что? Это нереализуемо! Нафик всех!"
"Ма-а-а-а-аш, посмотри, плиз, тут можно что-то сделать?"
"По-моему, они нас динамят..."
...
Ну и всякие мелочи аля "Закрывающему потестить то-то" или "пофиксил тут-то", которые Заказчику, опять же, не нужны.
Так вот. Вместо того, чтобы потом отслеживать все эти комменты и выставлять на них ограничения (видят только коллеги), подумайте об этом заранее. И в тасках, в которые аттачите переписку с Заказчиком, весь флуд сразу ограничивайте на видимость. На всякий случай. На будущее. Пригодится.
PS - Начитавшись Демарко, вдохновившись мистером Томпсоном, я решила если не каждый день, то хоть иногда находить умные и/или полезные идеи в течение рабочего дня и записывать их...
PPS - А пряча в джире флуд 6 часов подряд, я не могла промолчать...
Эту книгу я начала читать еще перед отпуском. И вы знаете, как то так хорошо пошло... Даже на море порой, приходя в номер, я брала книгу в руки и читала. Что уж говорить о Москве!
Это действительно роман... Интересный и увлекательный. Написанный очень простым и понятным языком, однако скрывает за внешней привлекательностью глубокие идеи. Если просто взять и почитать "записки менеджера" - врядли кто-то сильно ими проникнется. А почему? Потому что контекста нету.
Очень сложно вызубрить формулу. Точнее, вызубрить как раз легко, а вот понять ее потом - сложно. Так бывает, когда на собеседовании участник легко тарабанит все правила и даже с ходу расписывает, как он будет тестировать ваше приложение... Но, стоит его посадить перед компом - "на, тестируй!", как от легкости построения плана неостается и следа...
На самом деле их можно понять - когда у тебя мало времени и ты волнуешься, сложно выдать хороший результат. Однако, если ты знаешь, что тебе надо делать, только лишь в теории, врядли у тебя что-то получится.
Но, даже не имея собственной практики, можно глубже понять теорию... На чужом опыте! Ведь как пишут истинные мастера своего дела - они пишут так, что, читая книгу, ты погружаешься в мир автора, ты словно становишься этим самым главным героем. Переживаешь за него, сочувствуешь ему... И, разумеется, принимаешь все близко к сердцу. Его впечатления, его опыт - становятся твоим опытом. Отчасти, да...
Но в этом и состоит гениальность автора - он не просто дает некие "формулы счастья" для менеджера ПО. Он объясняет, чем именно они хороши, он показывает в контексте. Что было "ДО" их применения и что стало "ПОСЛЕ". Ну чем не опыт? Иногда лучше поучиться и на чужих ошибках :))
Роман очень интересный и увлекательный! Прочитав его, мне очень захотелось написать что-нибудь похожее про тестировщика. Чтобы вот так вот - не сухими формулами, а наглядными примерами из жизни. Чтобы читалось, захватывая дух, и при этом получать новые знания. Новый опыт.
Хотите почитать, каково живется менеджерам? Не знаете, чем эти "лоботрясы" занимаются весь день? Почитайте Тома Демарко - и многие вопросы отпадут сами собой!
Еще одна замечательная книжка от издательства "Манн Иванов и Фербер".
Книга о том, как научиться слушать других людей. И как показать им, что вы их слышите. Конечно, нельзя, вот так сразу, стать специалистом в деле переговоров, но из книги определенно можно начерпать кучу идей. В конце каждой главы идет практическое задание. Попробуйте их выполнить, глядишь, люди вокруг взглянут на вас иначе :)
Книга во многом пересекается с другой замечательной книгой о переговорах - "Что и как говорить, когда ставки высоки?". Книги о разном - что говорить и как слушать. Но пересекаются. И это радует.
А еще книга пересекается с теориями Адама Джексона, философии которого я придерживаюсь. Наверное, именно поэтому она мне так понравилась.
Автор учит нас "отражать" людей. Потому что многие люди в нашем жестоком мире испытывают дефицит зеркальных нейронов, который приводит к нервозам, депрессиям и прочим гадостям. И им очень хочется, чтобы их услышали! Поняли! Иначе говоря - зеркально отразили их мысли. Надо сказать, это довольно сложно сделать, хотя и легко звучит.
Но сложно не прислушивать к тому, кто проводил переговоры с терростистами. И обучал людей вести такие переговоры. Мне очень понравилось определение фазы своих эмоций. Если вы злитесь, это значит, что ваша "разумная часть мозга" уже отключилась, в бой идут животные инстинкты. Чтобы вернуться к рациональности, надо пройти такой вот путь:
Движение от «черт возьми» к «согласен»:
«Вот черт!» (фаза реакции): это катастрофа, все
пропало, с этим справиться невозможно, надо удирать.
«Боже мой!» (фаза разблокирования): да, ну и каша, как
же это все разгрести? И почему это всегда происходит со мной?
«Так…» (фаза перестройки): кажется, это можно
исправить. Хотя, конечно, ничего веселого в этом нет.
«Ну, хорошо…»(фаза
перефокусирования): я не позволю, чтобы это испортило мою
жизнь/карьеру/семью/день, и мне прямо сейчас нужно сделать вот что…
«Согласен» (фаза переподключения):– сейчас я все
исправлю.
Так и вспоминается
письмо от Заказчика, от описания которого у меня шарики за ролики заехали. Ведь
если нам что-то кажется очевидным, мы считаем это очевидным для всех. И не
проясняем некоторые моменты. А получитель в итоге вообще ничего не понимает. Первая реакция от письма «вот черт! Надо удирать!»
J
Кстати, а вызнаете, что, когда мы озвучиваем свои эмоции
(не обязательно вслух, можно и про себя), например, «я рассержен», то мы
успокаиваемся? Поэтому, вопреки распространенному мнению,в момент стресса вовсе
не надо себе лгать, говоря «Я спокоен! Все в порядке». Надо сказать себе
откровенно «Вот черт! Я напуган».
Конечно, если
зациклиться на этом этапе, то проблема не решится, поэтому потом надо
переходить на другую стадию. Но в первые момент – можно и чертыхнуться!
Подводя итог - книга обязательна к прочтению! Умение слушать лишним никогда не бывает. Но помните! Просто прочитать - недастаточно. Учитесь применять. Не все и сразу (так просто не получится), а выбрав какой-то прием, ищите повод его применить. Потом еще и еще. А потом - перечитайте книгу и переосмыслите. Выберите новый прием, который нужен вам на новом этапе - и вперед, к практике!
Причем уже успела забыть, как. Что-то я все думала, думала про Гандапаса и черт дернул полезть в гугл и узнать, а где-когда он выступает? И тут смотрю - Москва!!! И причем 12 июля! (А было тогда 8 число, 10 вечера). Ой-ей-ей, что же я так поздно узнала :((( Это же Гандапас, мест наверняка уже нет...
На следующий день (ну не глубокой же ночью мне людям названивать) я позвонила по телефону. Хотела узнать насчет оплаты. Ведь если еще, о чудо, остались билеты... Их надо выкупить срочно-срочно!!! А, как назло, денег на карточке у меня нет. Но я готова была съездить в обед и оплатить. Это ж счастье какое, за 3 дня до выступления билет купить.
Июнь, дожди... По закону подлости, как только перестаешь сдавать сессию, май и июнь резко перестают быть самыми жаркими месяцами в году.
Вот только кто сказал, что с окончанием института учеба должна заканчиваться? И кто сказал, что нельзя учиться на природе, наслаждаясь чистым свежим воздухом и параллельно занимаясь?
Наталья и Алексей Баранцевы специально для таких людей, которые хотят совмещать приятное с полезным, придумали летнюю школу тестировщиков. Место, где люди занимаются... В Крыму!
И вот он - долгожданный день отлета. Вставать пришлось в 5 утра и Москва была не слишком веселым провожающим - выйдя из дома, я поразилась ливню, который застилал все вокруг. Он яростно бил по асфальту, на котором уже образовался мини-океан. И я стою - в легких балетках на босу ногу. Спасибо брату, попытался подогнать машину поближе. А я пробежалась к нему по бордюру. Ноги, конечно, все равно промокли, и я очень переживала, что заболею в первый же день учебы.
Но ничего, все обошлось! В самолете уже я начала задумываться о том, как бы мне поработать еще успеть. Конечно же, успела в итоге около половины :) Про regexp посмотрела видео (хоть и не до конца), а по SQL сделала все, что могла. Не могла только ДЗ на "потыкай свое приложение". Вай-фай был ужасен, да.
С другой стороны, может, это и хорошо? Помнится, когда-то мы переезжали со старой версии JIRA на новую и я в новогодние праздники баги переводила :) Казалось бы, зачем, после отпуска бы перевела, да и не моя изначально задача была... Но вот ведь... Неймется :) И в отпуске думала, что вечерами буду просматривать "кто что сделал" в джире, перепроверять и заворачивать баги обратно )))) Но увы, не срослось. Выкачать приложение на свою машину было нереально, зайти на dev-платформу - тоже.
Но ничего! Зато можно было вдоволь наслаждаться отпуском и прекрасной компанией вокруг!
По приезду мы расселись в качельки, образовав "круг тестировщиков" и стали представляться. Вставал очередной коллега, клал себе руку на грудь и говорил:
- Я Вася, и я - тестировщик!
Аплодисменты, Вася садится. И так по кругу :)))
Первый "рабочий", точнее, учебный день начался довольно весело, на первом же теоритическом занятии мы с Таней поняли, что не зря нас вместе поселили)))
Очень часто в провале проекта хочется обвинить кого-нибудь... Кого угодно, но только не себя. Мы же все белые и пушистые, у нас есть куча веских доводов, почему мы ничем не могли помочь.
Но если отложить в сторону это навязчивое желание и задуматься... Всегда помните про метод "5 почему?", так мастерски рассказанный Натальей Руколь на SQA Days 10. Почему мы провалили проект? Потому что неправильно поняли требования? А почему? Где? На каком этапе?
Вы правда думаете, что требования до вас доходят ровно в том виде, в котором их представлял себе Заказчик? У вас такая афигенная команда и вы уверены, что нигде ничего не теряется?
Проверьте себя и свою команду! Устройте ролевую игру! Можно даже поменяться ролями, приятно ведь иногда побывать и в шкуре разработчика/аналитика. Легко критиковать менеджера, пока сам не побудешь в этой шкуре. Думаете, "вот если бы вы-ы-ы писали требования", все было бы супер-пупер? Проверьте!
Отважные ребята из летней школы тестировщиков бросили вызов непосильной задаче! У них не получилось, но они хотя бы попробовали :))
Итак, встречаем!
Ролевая игра
Что нужно Пользователю?
Автор идеи - Наталья Баранцева
Организатор игры - Наталья Руколь
Участники - все ученики летней школы!
Наташа Руколь => Эмиль + Андрей => Наташа => Юля и Нина => Таня и Ира => Дилара, Катя, Света, Игорь, Валентин.
Вначале всех выгоняют, остаются только Пользователь, Заказчики и наблюдатели.
Наблюдатели - это все оставшиеся участники школы, которые хотели видеть весь процесс целиком. Посмотреть со стороны, увидеть всю подноготную - что и на каком этапе потерялось/исказилось...
Общаться можно только с вышестоящим звеном цепочки. Тестировщик к пользователю не может подойти, он должен давить на разработчиков, те - на аналитиков и тд и тп.
Времени у ребят - по 3 минуты, на все-все-все. Только тестировщики начинали без ограничений. Но что говорить, давайте слушать!
Итак, все ушли. Остались только Пользователь и Заказчик. Пользователь озвучивает свои пожелания.
Немного мешает фоновый звук и детские крики, но уж извините, запись и так обработана...
Едем дальше
Все, время вышло, вопросов у Заказчиков не возникло. Чтож, переходим к следующему звену цепи. И вот уже Заказчик рассказывает сейлеру, чего хочет этот странный юзверь.
Плохо слышно, но в середине разговора прибежала Наташа (пользователь) и сказала, что Заказчики имеют шанс что-то спросить у нее, почему нет то? Это нижним звеньям к ней нельзя обращаться, а Заказчикам очень даже можно...
Чувствуете уже, да? Версия Андрея "нужна табличка...", тут же версия Эмиля "нужна напоминалка"... А ведь всего второе звено из длинной цепочки прошло...
Заказчики молчат, приходят Аналитики. Сейлер объясняет просьбу Пользователя Аналитикам.
Наташа не выдерживает и опять вмешивается, тонко намекая на то, что пора писать ТЗ (на обоях которое)
На заднем фоне идут тихие переговоры с Заказчиком... Ок, все обсудили, а дальше... Приходят тестировщики? Не-е-е-ет, им еще рано...
Наталья Руколь уводит в сторонку двух программистов - Ирину Винокурову и Татьяну Зинченко. И сразу говорит Тане, что она - плохой разработчик и раздолбай. Ну, недалеко от истины ушла, в принципе то :))) Слушаем самое сокровенное. Доселе про этот разговор знали только Наташа, Таня, Ира и я (диктофон то кто-то должен был держать)
Потом прибегает Наташа, которая не может не поинтересоваться, а есть ли у ребят тест-менеджер. На нее все шикают, нам, мол, не до тебя, уходи, и продолжают задавать вопросы.
Наташа ходит вокруг, слушает, что втирает тестировщикам Таня, и хихикает :)))
Тестировщики уже любят будущего пользователя - "Ну ичары, как обычно, все забывают, они такие". Ай яй яй, а где же любовь к сотруднику?
К концу разговора мы слышим в основном голос Иры - она, как прилежный разработчик, давала четкие ответы всем желающим, а раздолбайский разработчик Таня отбрехалась от Валентина, который все пытался у нее хоть что-нибудь узнать, и убежала к Заказчику. Прибавки к зарплате просить :))) Ну она же все сделала, ей положено.
Ира тем временем уже взвыла и сама стала ненавидеть "этих ужасных тестировщиков с их глупыми вопросами!!!!", временно забыв, к какому клану она относится.
Ну ок, тестировщикам сокращают время и они идут составлять тест-план.
Таня в это время ходит вокруг Заказчика и требует прибавки к зарплате. А когда она приходит "помочь" тестировщикам, Ира ее отправляет обратно - "Иди премию нам попроси, а?"
Потом Наташа снова объявляет правила "Допустим, все, что вы сейчас скажите, все работает. Вы там все баги нашли и там все работает". А то ведь тестировщики так старались, так старались, расписывали кейсы, на всякие граничные значения...
Тут надо отметить лица Пользователя и Заказчика, когда тестировщики сказали про Mac. Андрей пытался схомячить свою шляпу от стыда :)))
Тестировщики объясняют, что у них за формочка. Мелькают фразы "так, а это что такое?" от рассказчиков :))) А Наташа напирает "Так что же вы тестировали? Расскажите, пожалуйста".
Тестировщики молодцы, вещали в диктофон :) Вместо того, чтобы говорить громче, дабы все слышали. Ну ладно, рассказчица продолжает, ее коллеги ее перебивают :) И пытаются на ходу вкурить, что это за форма такая, которую они тестировали, разбив на части и не зная, что проверяют коллеги. Поэтому пользователь их иногда перебивает, чтобы понять, о чем они.
- Мы ставим галочку.
- Нет, чекбокс!
- Нет, галочку!
И это спорят не тестировщик с программистом, а тестировщик с... тестировщиком :)))
Света молодец, отличный кейс насчет смены должности! А то заспамят бедного сотрудника :))) Или вообще о нем забудут. А пользователь с заказчиком продолжают угорать, наблюдая за всем этим делом
Понравилось "потом приходит напоминалка... Или... Ну я не знаю, что! Я не буду об этом рассказывать - в требованиях не было" )))
Наблюдатели, которые в теме, хихикают и шикают друг на друга - молчи, мол, а то тестировщики уже косятся подозрительно. Видимо, догадываются )))) Что сделали что-то не то.
- Отпуска в двух случаях...
- А кто вам сказал про второй случай?
- Не знаю!!!
А потом пошла исповедь аналитиков. Правда, вначале Ира (хороший разработчик) отвела таки душу "я теперь поняла, почему меня ведьмой считают! Достали со своими вопросами!!!"
Но потом дали слово аналитикам - что же сделали не так разработчики? И тут наконец-таки выяснилась страшная тайна!!! Разработчики сделали форму, которая... Никому не нужна! Бедные, бедные тестировщики...
Потом высказался сейлер. Оказалось, у Наташи была целая пачка вопросов к Пользователю! Но она не имела права их задавать, только если бы ее об этом спросили бы...
Смотря какого, разумеется. Но, допустим, календарь, на дату которого строится отчет. Проверяем:
Заносим данные, смотрим на дату, когда данные были внесены;
Граничные значения - чуть пораньше, чуть попозже, это может быть день, а могут быть минуты
Другая бизнес-логика;
Потом пошли отрицательные кейсы - многие наверняка захотят вкопипастить в поле ввода какую-нибудь бяку. Но вот с этого ли стоит начинать?
Я тут на днях услышала про один весьма любопытный кейс:
Звонит пользователь, так и так, данные в отчет не приехали.
Ребята и так и сяк отчет корячат, разные коэффициенты пробуют, плохие данные...
Потом выяснилось, что пользователь ввел дату (внимание!)... С клавиатуры!
И в каком-то браузере (что-то мне подсказывает, что в IE, не знаю что...) оказалось, что, если выбрать дату из выпадающего календарика - все работает! А если вбить руками - нет...
Мораль сей басни такова... Бежим и пробуем "положительный" кейс в своих приложениях :)
А еще, перед тем, как пытаться разломать ваш календарик, потратьте минутку, просто пролистайте его и почитайте названия месяцев... Знаете ли вы, что...
При фильтрации ресурсов maven-ом в формате UTF-8, содержащих русские символы, заглавная буква 'И' преобразуется в "некорректный символ".
Такая ошибка воспроизводится только на ОС Windows и только с заглавной буквой 'И'.
