4

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

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

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

Многие наверное уже слышали, что в ближайшем выпуске подкаста Radio QA Андрей Солнцев, автор UI-Testing фрейморка Selenide будет проводить тестирование экспертов. Заключаться это "тестирование" будет в том, что молодой и любознательный тестировщик Александр подготовил набор коварных вопросов по разным темам ручного тестирования. Эксперты должны будут в прямом эфире не упасть лицом в грязь и ответить на вопросы так, чтобы Александр понял ответ :-) Вести выпуск будет Андрей, а в качестве экспертов приглашены директор по качеству Mail.ru Алексей Петров, живущий сейчас в Тайланде инженер Стас Катков (многолетний опыт в тестировании) и ваш покорный слуга.

Начало эфира в 17:30 мск, в четверг, 16 июля. Приходите на прямой эфир, там можно будет пообщаться в чатике и покритиковать экспертов :).

Подробности о передаче можно прочитать на сайте.

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

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

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

Кстати, о тонких чувствах ручных тестировщиков, ушедших в автоматизацию, в субботу 04.07 в 16:00 мск выходит подкаст на Radio QA :-)

2

Команда, в которой 10 разработчиков и ни одного тестировщика похожа на футбольную команду без защитников. Кстати, и 1 защитник особо погоды не меняет.
Из прошлогоднего креатива про то, как бы было, если бы в футболе размышляли, как некоторые личности из IT сферы.

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

(с) моё

- В защитники уходят те, кто не могут стать хорошими нападающими, это недонападающие.

(с) Андрей Ладутько

 

"Любой тест-менеджер хотел бы знать какие таски были выполнены <тестировщиком> за время тестовой сессии."

Интернет пишет вот, что любой хотел бы. Лично я не хотел бы, что я делаю не так? :)

Мне кажется не стоит путать роли тест-менеджера и надсмотрщика. А вам?

П.С. контекст цитаты - session-based testing.

Ну пройдемся немного по докладам.

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

Не ко всем докладам пока есть видео, но скоро появятся, потерпите :).

Сергей Атрощенков "Тестовые оракулы на основе концепции EI/EQ (эмоционального интеллекта)"  http://sqadays.com/ru/talk/25831

Любопытный доклад про то, как наблюдения за эмоциями (субъективные факторы) могут помочь в работе определять объективные факты (например, баги замечать). Кое-что общего в идее есть с  вебинаром от  it-boost с http://it-boost.com/statistika-ili-intuitsiya-chey-kung-fu-kruche , где я впервые услышал понятие "жопочуй".  Хочу обратить внимание, что хотя эмоции наверняка дают интересные сигналы, их верную трактовку сильно усложняет наличие внешних (вне рабочих) эмоций (забыл молоко купить, футбольная команда вчера выиграла, зарплаты вечно не хватает и тд.) как очевидных, так и более глубоких подсознательных. Сергей посоветовал разделять вектора рабочих и внешних эмоций, но я думаю, что это на практике не всегда просто, может даже невозможно.

Ольга Павлова "Порог вхождения как критическая точка пользовательского опыта"  http://sqadays.com/ru/talk/24046

Веселенький доклад, который напоминает, что если просто сделать "как в спецификации записано", то можно очень быстро получить провальный проект, особенно, если сделать это на точке входа пользователя в программу. Юзабилити наше все, а если вам при первом запуске программы предлагают заполнить формуляр на 30 полей, то возможно вы даже и не узнаете, как хорошо и правильно все устроено внутри. В конце доклада возник небольшой флейм с зрителем из "Одноклассники.ру" по поводу того, что автор "только указывает на проблему, но не дает путей решения". Возможно это так, но тут я согласен с Ольгой - докладчик строит доклад на свое усмотрение. Укажешь путь решения - спросят "почему не обсудил, когда данные пути не подходят". Обсудил - "почему не все альтернативы указал". "И вообще теперь наговорил всякого, половина мне вообще не подходит, зря и слушал" :). Ребята, у нас 30 минут на "длинный" доклад, еще меньше на блиц. Есть вопросы - общайтесь с докладчиком. Хотите решить именно вашу проблему в глубине - некоторые докладчики предлагают консальтинговые услуги, звоните-заказывайте ;-).

Владимир Мозжечков "Техническое собеседование Senior QA. Проведение и прохождение" http://sqadays.com/ru/talk/24011

Несколько провокационный доклад про то, как проводят собеседования в фирме аутсорсинговой фирме Smartech (http://smartru.com). Оказалось, что мне проще положительно пройти тест на беременность, чем закончить техническое собеседование на Senior QA на отлично. Потому что, полный ответ на поставленную задачу даст мне только 3 балла из 5, а для 5-ки нужно еще догадаться, что часть задания была скрыта, и успешно решить ее про запас. Подход спорный, так как с одной стороны, некоторые сильные кандидаты просто по-доброму удивятся, увидя объём задания и соскочат. С другой стороны, представьте, у вас есть кандидат который сделал всё что задавали, плюс тест-план, плюс автоматизированные тесты, плюс еще небольшую диссертацию по TCP/IP протоколу приложил. Если спросите меня, то возможно и в работе он, когда получит задание протестировать небольшой проект, вложит туда свою энергию и способности, и потратит ресурсы на то, чтобы сделать больше, чем предусмотрено бюджетом заказчика. По мне, так лучше меньше, да лучше :). Доклад тем не менее весьма полезный, вы можете теперь представить, что потенциально могут спрашивать на собеседованиях, и если вы основательно подготовитесь к этому, то никакой другой вас уже не испугает :). К слову, в данный момент открытых QA вакансий на сайте фирмы, и на hh.ru нет.

Инна Смирнова "Эффективный тест-менеджмент... и как с ним бороться" http://sqadays.com/ru/talk/25902

Вопреки услышанной от кого-то из организаторов установки, что нельзя пересказывать чужие книжки в своем докладе, я считаю, что хорошая презентация отличной и полезной книги имеет свою ценность. Что и показали оценки доклада (2-ое место). Инна говорила про один из бестселлеров Ицхака Адизеса "Стили Менеджмента и Мисменеджмента" (http://www.amazon.com/Management-Mismanagement-Styles-Kalderon-Adizes/dp/0937120014 ) в применении к общению с (тест)-менеджерами, а также со взглядом на саморазвитие. Адизес различает 4 компоненты в стиле управления P (Производитель), А (Администратор), Е (предприниматель), I (интегратор). В каждом менеджере наиболее развиты одна или две компоненты, и недоразвиты или отсутствуют остальные (и это - норма (с) :) ). У каждого стиля свои плюсы и минусы, к каждому стилю - свой подход. Можно пройти тест http://adizes.me/paei_test/ и узнать, к какому стилю относились бы вы, если бы были менеджером :).  У меня вышло PaEi, с преобладающим E:). Мне показалось, что большинство примеров были взяты прямо из книжки, было бы еще лучше, если бы Инна придумала примеры из повседневной жизни тестировщиков. Я книжку прочитал в 2011 году, и вспоминаю о разнице в типах, как правило, сразу после неудачного подхода к одному из "менеджеров", т.е. слишком поздно :). Поэтому меня интересовало то,  как можно практически применять знания типов (оценивать менеджеров и записывать буквочки в телефонную книжку)? Надеемся услышать об этом в следующий раз. :)
А в целом, если вы не слышали об Адизесе - обязательно прослушайте доклад!

Часть 2

Часть 3