Неявные ошибки на собеседованиях тестировщиков

Которые допускают кандидаты, если на собеседование пришел я.

Они не попадут в отчет по собеседованию, о них не сообщат команде-заказчику, о них не скажут кандидату, их даже не будут обсуждать в конце собеседования.

Но они неизбежно испортят впечатление.

Функционал

Используйте слова правильно. 

Функционал — функция, заданная на произвольном множестве и имеющая числовую область значений.

Функциональность — набор возможностей.

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

Блоги и ютуб

- Как вы учитесь?

- Читаю блоги, смотрю ютуб. 

- А книги или практические задачи?

- Не припомню.

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

Но в гораздо большей степени это говорит о способности кандидата концентрироваться. 

Тестировка или регрессивное тестирование

Без комментариев, просто не надо так говорить.

P.S. Блядь

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

Юрий Бригадир, экспрессивно: 

А это что за: "БЛЯТЬ"? Это из какого Брокгауза ты накопал? Павел Васильев, краса русской поэзии: 

"А пристяжные... 

Отступая, одна стоит на месте... 

другая краденая, знать... 

Татарская княжна да блядь... 

Кто выдумал хмельных, лошажих, 

разгульных девок запрягать"

"Тройку" помнишь? Не помнишь? А что ты вообще помнишь? "Блядь", чувствуешь, недоумок, "блядь"!!! Через "Д". Пастернак его с Моцартом от поэзии сравнивал, ты хоть это понимаешь, чудовище? Не порть язык, мудила, не бери пример с попсы. Есть и другие капитаны культуры - Шнур, например, "Красная плесень", на худой конец!

 

Сегодня я узнал

Про собеседования и квалификацию тестировщиков. 

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

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

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

Итак:

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

Выводы для сотрудников:

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

Выводы для команд:

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

Капитанство, но от повторений хуже не будет.

 

Двенадцать способов выполнить задачу (в Контуре)

Этот пост я опубликовал во внутренней сети и он применим именно к нашей культуре разработки. 

Предвосхищая возгласы (всем, конечно же, не пофиг) вида: 

- Да у вас бардак и все делают что хотят, ужас, так жить нельзя!

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

Итак, сам текст: 

Papers, Please

Намедни обнаружил игру 2013 года "Papers, Please", автор Лукас Поуп, русификация есть.

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

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

У игры есть сюжет: подполье, революция, втягивание во взяточничество. Но я их пропущу.

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

• Тупые сограждане, которые забывают приготовить документы, поставить нужную печать, обновить паспорт после свадьбы.
• Регулярные изменения правил: виза, карточка с личными данными, разрешение на работу, санкции для отдельных стран. И сегодня нужно проверять не совсем то, что ты проверял завтра.
• Начальство и коллеги с регулярными личными просьбами нарушить правила, что ведет к...
• Штрафам за ошибки. А вы думали?

Для себя отметил, что особенно легко пропустить не что-то не совпадающее, а отсутствующее. Печать, разрешение на работу...

А ведь надо всё время спешить, быстрей, быстрей, нужно заработать на лекарство сыну.

Короче, игра сделана с душой и со знанием дела.

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

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

К прохождению - рекомендую.

P.S.
Кстати, по ней наши ребята сняли короткометражку PAPERS, PLEASE - The Short Film

Итак, мы съездили в Ростов

Мы уже побывали в Ижевске, Казани, Новосибирске, Питере и Перми.
Муза дальних странствий манила нас.

Тест-сессия, седьмая городская

Спасибо компаниям.

В 2013 E96.


В 2014 Яндекс.
В 2015 Контур.
В 2016 Экстрим.
В 2017 Контур.
Хотели в 2018, но перенесли на январь 2019 УБРиР.
В 2019 Контур.


Спасибо организаторам:
Саша А., Юра Р., Оксана В., Дима Я., Игорь Б.,  Настя Р., Семен В..
Теперь плюс Катя В., Наташа С., Антон В., Гриша Г..
Теперь плюс Питер и Новосиб, одновременно.

Спасибо тем, кого не назвал по имени: 
комиссии по проверке багов, пиар отделы, обрпрограммы, те, кого забыл.

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

Регистрируйтесь на седьмую.
Пост в UTC.

О соревнованиях тестеров и навыках

Я занимаюсь тестированием с 2007 года и самоидентификация для меня важна. В том числе она включает в себя ответ на вопрос "Какой я специалист? Что я умею, а что нет?"

Из 8 проектов, в которых я работал дольше месяца, в 4 я был первым тестировщиком в команде. За процессы в 2 из этих 4 команд мне не стыдно.

Я всегда старался узнать ответ на вопрос — насколько хороший я тестировщик?

Ответ на этот вопрос не может не включать проблему сравнения себя с другими тестировщиками.

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

Один из способов — соревнования тестировщиков.

Я принимал участие в 4 соревнованиях по тестированию и каждый раз занимал призовые места:

• 1 место, вне зачета тестили е96
• 1 место, тестили экстрим
• 3 место, тестили мобилки
• 2 место, тестили кроссаут

Еще два соревнования тестировщиков я организовывал и судил.

Себе я доказал всё, что хотел.

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

Да, но...

Некоторые призеры первых тест-сессий, которые приходят на ум:

• Юра Рягин, руководитель отдела тестирования в Экстриме
• Наташа Селиверстова, самый сильный тестер в екбшном Яндексе.
• Саша Ахметов, широко известный в узких кругах Контура

Есть какая-то корреляция...

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

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

• слепая печать
• хоткеи и фишки в инструментах
• быстрый доступ к информации
• умение в календарь
• пустой почтовый ящик
• ...

• Оформить скриншот за 2 секунды.
• Создать дефект из шаблона меньше, чем за минуту.
• Ответить на вопрос "Над какими задачами ты работал в апреле 2016 года?" меньше, чем за минуту.
• Создать встречу на 1,5 часа на этой неделе на 4 человека и 3 менеджера, и чтоб у всех не было занято.
• Написать скриптик на питоне или баше, готовящий данные.

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

Подробно и хорошо об этом механизме пишет Лемов в книге "От знаний к навыкам". Книга есть в библиотеке.

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

Кстати, мне нравится, что в управлении разработки Контура

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

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

Что делать?

Сравнивать.

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

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

Напротив — программист ... Ну ты понял.

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

P.S. А еще следи за новостями, одна тест-сессия будет 1 декабря, другая в начале февраля.

О выборе, автоматизаторах и универсалах.

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

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

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

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

А это значит, что ожидаемый портрет - он как "Бойцовый Кот"

«... есть боевая единица сама в себе, способная справиться с любой мыслимой и немыслимой неожиданностью»

Это не значит, что портрет нам не подходит, это значит, он имеет меньшую ценность. 

Я не пойму, хорошо это или плохо - ставить себе подобные ограничения?

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

Disclaimer: Еще раз, я говорил не о человеке, а о некоем образе, который я успел составить за время собеседования и чтения тестового задания. Как нам и завещал Канеман, в реальности человек окажется совсем другим и будет вести себя немного не так и серьезный процент выводов будет неверным.

Будущего пост

Около года назад группа тестеров контура встретились и создали некоторый текст на предмет "А какими будут тестирование и тестировщики компании через 3 года, в 2020?"

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

Если есть желание - присоединяйтесь в комментариях.

Итак,  тестирование в Екатеринбурге, 2021

Игроки

Контур, от 1к разработчиков, полторы-две сотни тестеров, аппетиты найма сильно не вырастут, но останутся стабильно большими.
Яндекс, две-три сотни разработчиков, тестеров немного, до 30, нанимают мало.
Наумен, как яндекс, только Наумен. Сюда добавим еще несколько компаний с собственной разработкой и небольшим количеством тестировщиков.

Не знаю, выживет ли Абак, но если да, то там человек до 25.

Компании, бизнес которых не разработка. МТС, ITM и всё такое.  В сумме много, но живущих очень по отдельности тестеров.
В них отдельной когортой банки - Тинькоф, Сбертех, Альфа, СКБ Лабс, кто там еще - от 10 до 30 тестировщиков в каждом, растут медленно. От предыдущей группы отличаются удвоенной зарплатой и наличиев автотестеров.

Разработка на иностранный аутсорс небольшими группами и общей мощностью от полусотни до сотни.

Обучение

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

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

Компании с 20+ сотрудников ведут внутренний курс итоговой мощностью на выходе до 5 человек, если не лезут в автоматизацию, то может даже получиться сносное качество.

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

Компании с меньшим, чем 20, количеством тестеров успешно наставничают и не понимают сути проблем больших братьев.

 

Стеки

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

Тестеры остальных компаний сидят на традиционных стеках: рельсы в абаке и ява везде.

Ява заменяется на котлин, но принципиально картину это не меняет.

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

Проекты

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

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

У людей из продуктовой будут перспективы роста выше "рабочий", качество на выходе и интерес к их мнению.

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

Квалификация

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

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

Переходы между компаниями

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

Собеседования

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

Команды

Вслед за продуктами, которые делятся на микросервисы, фронт и бэк, команды делятся так же. И тестеры вслед за ними. Максимальное количество тестеров в команде - 4, после - делятся.

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

Книги

Как и сейчас, те, кто читают, имеют +30% к зарплате, но помалкивают об этом.

Задачи

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

Тестировать их можно либо кодом, либо контрактами, останется и то и другое.

Фронт и бэк

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

Нефункциональное тестирование

Технари - отдельные статистически незначимые глыбы за космический прайс. 

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

Релизный цикл

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

Конференции

Мы так и не привезем SQA в екб.

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

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

Специфические навыки

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

Стартапы

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

Саентологи

Датасайнс, нейросети. Масса проектов, в них масса людей, но потом всё равно окажется, что надо тестить верстку админки и искать хитрые тестовые данные. Реальность скучная. тем не менее. строчки в резюме будут и мы будем чуть ближе к умным словам. Теория эксперимента от умных слов не меняется.

Конец 

Я попытался описать близкое будущее, но получилась какая-то текущая реальность с украшениями. Ну, что есть.

Инструменты тестировщика

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

Roadmap тестировщика в контуре

У нас в контуре есть гайд о том, каким мы видим проектировщика.

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

Этот текст должен использоваться для оценки специалистов и для идей о том, что делать и как развиваться дальше. Не всегда успешно, но все же.

Когда нибудь придет время  и он будет торчать наружу, пока же лежит в корпоративном гите.

Итак:

Тестировщик в Контуре

Per aspera ad astra

О чем речь?

Текст поможет ответить на вопросы **Кто я и как мне стать круче?** и понять, кем хочешь быть в профессии и что сделать, чтоб стать лучше.

Стажер, младший тестировщик (0)

Чтоб стать

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

• Высшее техническое образование
• Серьезный объем подготовки
• Опыт работы в профессии

Гейзенбаг

Третьего дня просмотрел трансляцию конференции Гейзенбаг.

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

Особенно хотелось бы отметить доклад Николая Алименкова Паттерны проектирования в автоматизации тестирования.

В докладе Николай пройдётся по всем известным паттернам и подробно опишет их с несколькими практическими примерами.

Рекомендую просмотреть.
Основную и самую ценную мысль Николай сказал в самом начале. Своими словами:

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

Лекция Сергея Мартыненко

Спасибо Насте Ронжиной и проекту Контура "Гуру на Урале".

Тервер на службе менеджера:

ROI от автоматизации тестирования:

Следующий тренер - через год.

Про то, куда иду

Ты "свет фар" своего проекта. (с)

Сэм Канер.

Про то, откуда иду, я уже писал. Теперь про то, куда.

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

 

Ты не программист

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

Но приложения создают именно программисты. И отчасти ты - программист.

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

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

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

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

Если ты пишешь тесты, то код тестов соответствует стандартам кода продукта. Тесты - часть продукта и их качество - качество продукта. Ты пишешь код системы тестов на нужном уровне. И проходишь стандартное ревью программистов.

Ты не проектировщик

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

Но твоим продуктом будут пользоваться люди. И отчасти ты - проектировщик.

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

Ты не аналитик

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

Но аналитики определяют, что мы должны создать. И отчасти ты - аналитик.

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

Ты не менеджер

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

Но ты работаешь в команде. Будь менеджером.

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

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

Ты тестировщик

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

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

Ты профессионал

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

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

Самый ценный ресурс тестировщика - доверие. Тебе доверяют.

Про то, откуда иду

Главпроектировщик, Сергей, с коллегами создал манифест о хорошем, правильном проектировщике. А про тестеров у нас в компании такого нет.
Короче, я тоже захотел. Но не осилил.

Кто такой - отличный тестировщик?

Кого я называю отличным?
В чью группу хочу попасть?
Кто работает лучше меня?
На кого равняюсь?
У кого хочу учиться?

В мире? Виттакер, Канер, Бах, Болтон. Почему? Они профессора, программисты, авторы книг, евангелисты. Я читал их книги и статьи.
В стране? Руколь, Назина, Баранцев, Александров, Мартыненко, Мериин, Нечаева, Высоцкий. Почему? Они известные тренеры и докладчики. Я был на тренингах и слушал доклады.
В Екатеринбурге? Юра Р., Женя А., Илья В., Ната С.. Почему? Они умеют работать, у нас были совместные проекты.

- Можно ли стать отличным, не интересуясь, как работают другие?
- Нет.

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

Так и записал. Что еще?
Не знаю.

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

Куда и откуда?
Прежде всего это история людей, с которыми работал.

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

Второй шаг - в Наумене удалось вместе работать с руководителем разработки SD, программистом А.Л..

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

Третий шаг. В тот период я занялся переводом "lessons learned in software testing", книги, которая не столько о стандартах, техниках и методологиях, сколько о о ситуациях, в которые попал автор. Читая ее я чувствовал, что веду диалог с автором о том как жить и работать.
В ней есть понемногу обо всей жизни тестировщика. Попасть на работу, работать руками, что и зачем автоматизировать, на какие конференции ходить, какие подходы срабротали, какие нет. Как нанимать и как увольняться.
Иногда даже удавалось успешно применить какой-нибудь из 293 уроков.Рассылка о состоянии тестирования, посещение конференций, маркетинг своей деятельности и многое другое вышло со страниц этой книги.
Канеру в деле воспитания меня помогали Блэк, Виттакер, Криспин, Адизес и многие другие.

Следующий шаг и следующий человек - Ю.З., аналитик, менеджер разработки.

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

А еще показала как по-разному можно решать задачи.
Автор 500 постановок к одному продукту - показала, как вести продукт с 5 аналитиками и практически без ТЗ - в привычном нам виде. Менеджер, собравший топовую команду тестирования - показала, как жить без багтрекера и без открытых багов. Мне, тестировщику показала.

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

- Что дальше?
- Не знаю. Наверное, опять ищу человека.

- Пост точно про тестирование?
- Нет. Про жизнь.

Репост старой записи о проценте нахождения багов разными техниками

Ссылка:
https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/

Вам не нужно больше тестировщиков

Я все еще под впечатлениям от нетленки Болтона девятилетней давности.

Менеджеры и тимлиды:
У вас в командах уже есть тестировщики, но вы хотите ещё, потому, что:

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

Вам не нужно больше тестировщиков:

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

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

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

• Вам нужно уйти из бизнеса по разработке программного обеспечения.

Про аналитику

Текстовая версия моего рассказа на летучке от 9 декабря.

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

Часть первая. О чем?

До сего времени я был знаком с шаблоном  юзкейса

Я как {роль} хочу {что-то}, чтобы {цель}. 

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

Итак, что такое юзкейс?

Повествование о взаимодействии человека с системой.

1. Лица
2. Цели
3. Успех
4. Расширения
5. Обработка
6. Данные
7. Валидация

Особенности

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

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

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



Часть вторая. Зачем?

Каждый новый шаг в выбранной вами профессии стоит дороже.

• Сперва нужно знать как чем отличается гет от пост, делить на классы эквивалентности, писать чеклисты и делать что говорят.
• Затем - разбираться в стеке OSI, писать скрипты bash, пользоваться фидлером, рисовать карты памяти и приоритезировать свои задачи.
• Идем дальше - и мы уже чуем слабые места layer'ной архитектуры, программируем на любом скриптовом языке, оцениваем узкие места коммуникативвных средств и понимаем, зачем в реальной жизни нужны ТОС и ТАУ.

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

Можно использовать модель пирамиды - чтоб подняться на уровень выше - нужно расширить базу. Чтоб хорошо тестировать нужно немного программировать, немного сисадминить. Уверен, что когда-то, чтоб стать еще лучше в тестировании нужно будет разобраться в теории музыки.
Это всего лишь модель.
Есть и другая модель - когда знания и умения дают в совокупности синергетический эффект. У человека становится шире круг инструментов, которыми и с которыми он работает. Богаче язык, больше метафор, больше способов посмотреть на мир и возможность выбирать самый эффективный из них.

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

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

Это профессия аналитика.
Я делю знания аналитика на две части -
Первая это инженерия систем, проектирование систем, создание моделей - все вот это. Описание и создание неких ментальных конструкций.
Вторая - коммуникация. Представление этих конструкуций в понятной форме.

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


Как они мне могли бы пригодиться?
Менеджеры не звери и программисты не сволочи. И часто могут хотеть помочь нам. Зачастую - в случайный момент времени нам выдается значительный ресурс программиста. И я ставлю 5 к 9, что если каждому из вас выдать программиста на неделю, то вы не придумаете ничего полезней чем "чини старые баги". и 7 к 9, что даже если придумаете, то это будет абстрактное желание в виде устного творчества.

К чему я? Тестировщики часто ставят задачи. Множество микрорешений на уровне продукта. Задания на доработку тестирующей системы, создание заглушек, инструменты сопутствующей автоматизации.
А теперь попробуйте вспомнить, из за чего программисты делают добрую часть ошибок? Из за некачественного задания.
Автотесты - большой продукт. Сотни тысяч строк. Сколько у них постановок? А почему? Я видел у 2 команд. Удивите меня.
А можно ли назвать задания которые ставят тестировщики качественными?

О профессионалах.

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

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

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

Здравствуй.

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

Оказалось, что работа тестировщика — не такая уж и простая. Каждый день приложение становится больше, добавляются новые функции и нужно помнить все больше деталей, проверять все больше особенностей работы приложения. И очень важно не забывать о профессиональном росте - есть масса книг по тестированию и еще много курсов. К сожалению, на книги совсем не хватает времени, я прочел только две - Савина и ту книгу Канера, о которой услышал на собеседовании. Зато я был уже на трех конференциях и регулярно смотрю записи докладов с SQA Days. Правда уровень докладчиков там год от года ниже — почти все что они рассказывают, нельзя применить к нашему проекту, так как он намного сложнее инфраструктурно. Да и проблемы в докладах решаются как-то легко — у нас это никогда не взлетит, у нас другая структура команд.

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

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

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

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

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

Кстати! О хорошем. У нас отличные программисты! Мне кажется, что одни из лучших. Никогда еще не посылали меня, всегда слушают, помогают, находят решение. Написать скрипт, помочь поймать баг. И даже просьбы расставить айдишники локаторам выполняют не дольше, чем за два дня. И большие задачи, которые я от них иногда хочу - сразу ставят к себе в план и выполняют в ближайшую итерацию. Уже скоро возьмут задачу по добавлению организаций в систему через api. И баги они берут и чинят сразу! Мои так вообще почти никогда не отклоняют с "не воспроизводится". Тем более, что если, например, импорт в принципе не работает, то тут уже не сможешь ничего отклонить =)

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

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

Четвертая городская сессия тестирования

И первая, которую делал не я.
И первая, в которой я принимал участие.
Отчет на сайте  UTC.
Коротко, мое мнение:

Акелла не промахнулся.

 А теперь позволю себе процитировать организатора сессии - Юру Рягина, дальше - его текст.

О тест-сессиях

Думаю, можно смело сказать, что в сообществе тестировщиков Екатеринбурга в последние годы зародилась некая новая традиция - традиция проводить городскую сессию тестирования. Такая тест-сессия представляет собой соревнование, в котором активные представители сообщества тестировщиков нашего города целый день "меряются силами", тестируя предложенный на тест-сессии продукт. Городские тест-сессии в г. Екатеринбурге проводятся с 2013 года и организуются примерно раз в год различными компаниями. Так, например, в 2013 году тест-сессия была организована Максимом Захаровым (Naumen) и Антоном Андреевым (E96) при поддержке от СКБ Контура (продукт был предоставлен порталом E96), в 2014 году Максимом Захаровым (Яндекс) и при поддержке от Яндекса (тестировался также продукт Яндекса - Мастер), в 2015 году - Оксаной Валишиной (СКБ Контур) и Максимом Захаровым (СКБ Контур) при поддержке СКБ Контура (Тестировался продукт "Стафф" от СКБ Конутр). Лично я принимал участие в двух. На каждом таком мероприятии были новые лица и новые правила, на каждое мероприятие приходило очень много разных интересных людей, и каждая сессия давала новую пищу для размышления как участникам, так и организаторам.

Об организации

Участие в тест-сессиях принесло мне кучу положительных эмоций, новых вызовов в развитии себя в направлении тестирования и многое другое (ну и мне ещё удалось оказаться среди призеров данного мероприятия, что, конечно, было по-особенному приятно. После тест-сессии в декабре 2015 года у меня зародилась мысль - "а почему бы не организовать данное мероприятие самому и провести его от имени нашей компании?". Соответственно, цель была поставлена... оставалось только найти подходящий продукт, определиться с временем проведения и заручиться поддержкой руководства. В мае 2016 года ко мне обратились Алексей Смирнов и Александр Ложкин с задачей: «Юра! У нас есть новый продукт, пора бы его начать тестировать!». Тут же мне вспомнилась моя идея о проведении тест-сессии, и мы с коллегами, заручившись поддержкой руководителя проекта (Алексея Смирнова), начали планомерную подготовку к ЧЕТВЕРТОЙ ГОРОДСКОЙ СЕССИИ ТЕСТИРОВАНИЯ от «Группы Компаний Экстрим». Процесс подготовки описывать, пожалуй, не буду. Хочу сказать отдельное спасибо Максиму Захарову и Оксане Валишиной за то, что поделились своим опытом в проведении предыдущих тест-сессий. Без этого опыта мероприятие бы получилось не таким, каким оно получилось. А также нашему генеральному директору Максиму Сереброву, который взял на себя все вопросы, связанные с оплатой аренды помещения и других важных деталей мероприятия.

Как всё было

Итак, день: 2 июля 2016 года. Место: "Коворкинг Соль". Участие приняли 27 участников и 11 организаторов. Всех участников на входе встречали волонтеры, выдавали бейджики, ручки и блокноты, направляли и рассказывали, что, собственно, нужно дальше делать. После того как все "опоздуны" подошли, мы начали делить участников на команды. Итого получилось 14 команд:

1. "#1": Швецова Ксения (ГК Экстрим), Суханова Наталья (Netelement),
2. "ТСЖ Багхантеры": Денисламова Динара (Naumen), Сабиров Евгений (ГК Хост),
3. "SashaTest": Лескина Александра (Naumen), Турыгина Александра (СКБ Контур),
4. Комиссарова Анастасия (Naumen), Платонова Наталья (Сбербанк-Технологии),
5. Ярунова Галина (ГК Экстрим), Беглецов Владимир (Сбербанк-Технологии),
6. Мотина Наталья (Naumen), Шутов Борис (Яндекс),
7. "Dream Team": Подрезова Виктория (ГК Экстрим), Пироженко Валерия (Naumen),
8. Клёнова Галина (Naumen), Ушакова Наталья (не пришла),
9. "Test-n-Roll": Буторин Василий (НПО автоматики), Черемных Татьяна (Netlabsystems),
10. Кадочников Игорь (ГК Экстрим), Баянов Илья (ГК Экстрим) - команда из службы технической поддержки компании организатора,
11. "Сачки1337": Коткова Юлия (Naumen), Плетнёв Степан (Прософт Биометрикс),
12. "Двадцать седьмые" : Куликов Илья (ГК Экстрим), Захаров Максим (СКБ Контур),
13. "Explosion": Рыбасова Ангелина (Naumen), Рощупкин Виталий (СКБ Контур),
14. Ахметов Денис (Яндекс), Небова Полина (i-link консалтинг).

Как видно из состава команд, большинство участников было из Naumen'a (целых 8 человек). А вот из СКБ Контура было всего трое человек, а все потому, что в этот день у них был летний праздник. После того, как все участники были распределены по командам, началась вводная по продукту, который предстояло протестировать. В этот раз на тест-сессию был предложен продукт из сферы ЖКХ под названием РГИС (Региональная информационная система ЖКХ) под брендом Эльпас. Указанный продукт является довольно специфичным, поэтому вводная о нем получилась достаточно подробной и объемной. В частности были озвучены ответы на вопросы о том "Зачем?", "Почему?" и "Как?". Под конец рассказа о нашем продукте многие утомились, а другие были в шоке. После рассказа о продукте были оглашены правила мероприятия, список специальных багов в тестируемой системе - "Пасхалок" (да-да, они были сделаны специально для мероприятия), информация о том, как добраться до необходимых материалов (например, до аналитики), а также озвучена система начисления очков. В тестируемом приложении было несколько "точек входа". Т.е. тестировать можно было не только GUI приложения, а также загрузку данных через файлы (FILE) и взаимодействие через REST API. Поэтому для начисления очков использовалась следующая незамысловатая система: Для заведения багов был подготовлен специальный проект в нашем баг-трекере: Все инструкции получены, откладывать больше нечего. Поэтому настал час "X" и всем была дана команда "На старт! Внимание! Марш!". Все команды ринулись в бой, а разработчики начали яростно отбиваться от приходящих багов. Два часа пролетели незаметно, после чего настал обед, где все участники мероприятия решили подкрепиться перед второй частью мероприятия. Во второй части тест-сессии участники перешли от тестирования GUI к более сложным вещам, связанным с REST API и XML/XSD. Менторы мероприятия только и успевали бегать от одной команды к другой и отвечать на поставленные вопросы (а некоторые даже так устали, что решили немножечко отдохнуть на диванчике). Вторая часть тест-сессии длилась почти 3 часа. В то время, пока жюри подсчитывало количество очков каждой команд, решено было пообщаться и обсудить прошедшее мероприятие. Все из участников мероприятия успели познакомиться поближе, узнать кто чем занимается и посмотреть на общую статистику по мероприятию, а так же посмотреть на специальные баги. А там было на что посмотреть.

Итоги

А вот и "статистика" по прошедшему мероприятию.

• Всего найдено 301 баг, из них:
  • 202 принято,
  • 92 отвергнуто,
  • 7 "Пасхалок".
• Всего 202 бага, из них по приоритетам:
  • 7 с типом "Blocker",
  • 19 c типом "Critical",
  • 43 с типом "Major",
  • 69 c типом "Minor",
  • 64 с типом "Trivial".
• Всего 202 бага, из них по "точкам входа" в приложение:
  • 189 в GUI,
  • 13 в FILE,
  • 0 в API.

Всего в реальном баг-трекере проекта заведено 52 бага/таска (критичность при переносе была дополнительно пересмотрена), при этом часть багов было сгруппировано (например баги связанные с версткой объединены в один баг/таск). Примерное количество уникальных багов - 110 штук. Призы уже были готовы увидеть своих победителей, оставались лишь считанные минуты для оглашения результатов тест-сессии по продукту РГИС. Собственно итоги (прошу прощения у тех кого я утомил столь долгим текстом). Победителями четвертой городской сессии тестирования стали: Первое место: Команда "Двадцать седьмые": Илья Куликов (ГК Экстрим), Максим Захаров (СКБ Контур) - 96 очков. Второе место: Команда "Сачки1337": Коткова Юлия (Naumen), Плетнёв Степан (Прософт-Биометрикс) - 72,5 очка. Третье место: Команда "Explosion": Рыбасова Ангелина (Naumen), Рощупкин Виталий (СКБ Контур) - 72 очка. Итоговую таблицу со всеми командами можно найти тут. И заключительное фото со всеми участниками и организаторами. Всем участникам и организаторам ещё раз большое спасибо! Отдельное спасибо Евгении Азановой (Naumen) за фоторепортаж (все фото можно посмотреть тут).   PPS. Все найденные баги в ближайшее время будут взяты в работу и устранены! Через 1-1.5 месяца ожидается дополнительный отчет, насколько тест-сессия помогла данному продукту при внедрении.