Podlodka QA Crew#10 Call for papers

Подлодка объявляет call for papers: https://docs.google.com/forms/d/e/1FAIpQLScMLpMAUsSHswJbMx8gUKBU9epORws6VN4ymqmeBjAo1wVarQ/viewform

Мне безумно нравится тема предстоящего сезона Подлодки: “Метрики и оценка результата”.
Это одна из тем, которые, с одной стороны, касаются области QA, а с другой, связана с вопросом “как жить эту жизнь?”.

Думаю, про это можно говорить бесконечно.

Стори пойнты vs человекочасы - кто кого забОрет? И вообще, зачем нужны футболки или стори пойнты, если в сутках все равно 24 часа и заказчик хочет фичу точно в срок, вне зависимости от того, померяем мы фичу в часах, футболках или попугаях? Как вообще можно что-то запланировать, когда не знаешь, что точно будешь делать и каким способом будешь это делать? Что можно померять, что нельзя? Как померять то, что можно померять? Как измерить то, что (как будто) нельзя померять? Как использовать метрику так, чтобы она была инструментом привнесения ценности, а не пыточным орудием для сотрудников?

Смежные вопросы про "как жить эту жизнь":

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

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

Но, может быть, еще сделаю это когда-нибудь в будущем.

QA Sis Conf - Как работать работу в современном мире?

Большинство проблем, которые я наблюдаю у новичков в тестировании и которые действительно мешают работать, парадоксальным (или нет?) образом относятся не к области QA как таковой, а к “как жить эту жизнь?”.

Ольга Артемьева написала отличный пост про то, почему так получается.

Добавлю немного к ее посту.

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

Или все же на курсах дают задачи, которые…

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

- имеют решение

- имеют цель - принести ценность нам (чтобы мы что-то запомнили и еще в идеале получили удовольствие)

Представим кого-то, кто проходит курсы, выучивается делать задачи такого типа и награждает себя значком “good learner”. Ничто не предвещает беды.

Тем временем на работе:

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

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

- имеют цель - принести ценность бизнесу

И тут оказывается, что нужно уметь:

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

- оценить задачу “на входе”. Больше нельзя слепо брать все задачи, которые дают, и делать

- говорить “нет”. Даже тим лиду. Даже клиенту. Даже если очень страшно. Если мы не можем сказать “нет”, нашему “да” нельзя полностью верить и на нас нельзя опереться

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

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

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

- отслеживать количество glue work и принимать меры, когда ее становится слишком много

Список можно продолжать.

А что делать-то? Оля в докладе предлагает признать, что это отдельные навыки - и учиться им.

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

#qasisconf

Как работать работу в современном мире?

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

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

Одним вещам нас учили явно. Куда впадает Волга? Как возвести число в степень? И прочие предметы в школе и институте. Это — формальный учебный план.

А есть еще ценности, нормы и процедуры, которые мы усвоили неявно. Например, что бабушка печет пироги и заботится о внуках. Что надо сидеть неподвижно 45 минут и не вертеться. Что если у тебя проблемы с одноклассниками, надо решать их самостоятельно и не жаловаться родителям и учителям. Что «светлая голова, но ленишься» лучше, чем «звёзд с неба не хватаешь, но старательная». И кучу всего еще. Это называется скрытый учебный план (или hidden curriсulum).

А потом мы приходим на работу в айти и тестировании и от нас требую совсем иного.

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

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

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

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

Про все это и что с этим делать я рассказываю в докладе на QA Sis Conf.

Дополнительные материалы:

• Элфин Тоффлер. Третья Волна
• Hidden cirriculum in Education: Definition & Exampels
• Наталья Петровская. Как понять, что я хороший тестировщик?
• Максим Дорофеев. Путь Джедая
• Сергей Нужненко. Менеджеры почем?
• Антон Зотин. Почему вам не стоит внедрять Agile?
• Деконструкция идеи на примере «Тестирование — легкий путь в айти?»

#подпольный_евангелизм
#карьера_в_тестировании
#qasisconf

Пять копеек про восприятие профессии

Как будто очень много написано про контроль качества. Профессия на слуху, материалов - море, курсов (платных/бесплатных) тоже. Однако до сих пор работа в этой области часто (или всегда?…) воспринимается людьми «снаружи» как поиск дефектов (багов) и работа с инструментами, которые часто даже не являются инструментами, специфическими именно для тестирования.

- Работаю в такой-то сфере, есть некоторый опыт в IT. Как думаешь, стоит ли мне податься на вакансию в сфере тестирования?
- Если есть уверенные знания в теории тестирования - почему бы нет, попробуй.
- Я работал с командной строкой.
- А какие знания именно по тестированию у тебя есть? Может, что-то изучал самостоятельно или на курсах?
- Все самостоятельно изучал! SQL, Postman...
(диалог из реальной жизни)

Какие визуальные образы используются, когда идет речь про QA/QC?

- Лупа или микроскоп
- Жуки

Кажется, все:/

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

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

Какие выводы хочется из этого сделать?

Кажется, что о профессии говорят как будто много, но недостаточно:/ Не в плане количества, а в плане содержания.

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

Ожидания от кандидатов - 1

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

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

Почти каждого кандидата я прошу…

...барабанная дробь...
...драматическая пауза...

…рассказать, как бы он протестировал логин.

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

Возможно, некоторые кандидаты от такого вопроса мысленно закатывают глаза. У них опыт 5-10 лет, а им тут логин подсовывают. Как так можно? Еще бы предложили стул потестировать. Или тортик.
Задача как будто бы недалеко ушла от тестирования тортика, да?

Не совсем.

Какие есть ожидания:

—-уровень тестирования тортика начался —-

🔹 Стажер: Рандомно (без учета приоритетов) перечислит очевидные сценарии, которые можно проверить со стороны пользователя.

🔹 Джуниор: Сначала обозначит основные позитивные и негативные сценарии, потом начнет думать над остальными. Вглубь не полезет

—-уровень тестирования тортика закончился —-

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

🔹 Сеньор: помимо всего перечисленного - укажет на неочевидные рискованные моменты. Предложит план, как их побороть - или как с ними жить.

🔹 Единорог: задаст вопросы, после которых я потемнею лицом и пойду переосмыслять свой подход к тестированию.

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

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

Пользователь сможет работать на системе, только если все три сессии работают одновременно.

Если кандидат не очень умеет в тест-анализ - он, скорее всего, протестирует лишнее (логин форму, например) и при этом не учтет большую часть рисков.

Чем это чревато в работе: функциональность будет как будто протестирована, ее доставят на продакшен систему… и там начнут происходить инциденты.

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

Ожидания от кандидатов - 2

Это может выглядеть, например, так:

У пользователя не работает логин? А логин и пароль корректные вообще? Хм, говорят, точно корректные. Так, надо воспроизвести на тестовой системе. Ой, не воспроизводится. Наверное, дело в разных средах. Может, у нас продакшен упал?!! Да не, такое саппорт сразу бы заметил. И другие пользователи могут залогиниться. То есть продакшен хост точно работает. Что мне делать?

/Звуки паники/

А как бы это могло бы выглядеть, если бы в тест-анализ было инвестировано больше усилий?

Например, так:

У пользователя не работает логин? Поисследую всю цепочку интеграций. Чтобы пользователь начал логиниться на нашей стороне, нужно, чтобы третья сторона прислала такой-то файлик в таком-то формате с такими-то данными. Этот файлик к нам пришел вообще? Надо посмотреть в лог такого-то компонента. Что тут есть? Входящий запрос от третьей стороны с данными о пользователе есть? Нету. Ага. Значит, не было даже попытки залогиниться в нашу систему. Что я тут могу сделать? Я могу объяснить, что на нашей стороне проблемы не обнаружено, а пользователь не залогинился т к третья сторона не прислала нам данные, необходимые для этого логина. Я могу предъявить аргументы - отсутствие попытки логина в логах. Дело закрыто!

/Звуки счастья/

Адаптация к эмиграции - 1

Делюсь записью еще одного доклада с QA Sis Conf - и заодно пишу алаверды из серии “как жить эту жизнь”.

Важная идея, с которой Женя делится в докладе: эмиграция - это стресс, а выйти из ситуации стресса можно только двумя путями: истощение или личностный рост. Это значит, что если переезжаешь и адаптируешься - в качестве бонуса получаешь общий level up. Примечание: если ты хочешь адаптироваться - ты совершенно точно это сделаешь.

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

Какие ожидания от переезда у меня были? Ожидала, что будет сложно и что не получится работать с той эффективностью, которую я привыкла от себя требовать. Ожидания оправдались процентов на 150. Возможно, на 200.

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

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

Работу я не меняла. Переезжала без смены компании и даже без смены проекта. Буду в дальнейшем также избегать переездов со сменой компании. Сменить страну - огромный стресс, сменить работу - дополнительный огромный стресс. Хочется, чтобы эти два стресса были максимально разнесены по времени.

#qasisconf

Адаптация к эмиграции

13 июля я прочитала одноимённый доклад на конференции QA Sisters Conf #1.

Послушать запись можно здесь: https://youtu.be/WwD7nAHVyKU

Конференцию организовали в кратчайшие сроки силами админсостава сообщества QA Sisters, куда входит ваша покорная слуга.

Отуда взялась идея и как прошли три недели конференции вы можете почитать у моих коллег: Дарьи Супруновой и Ольги Артемьевой. Я ничего лучше уже не напишу.

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

А я пока расскажу о самом докладе.

Что я планировала рассказывать: как справляться с неопределенностью в условиях эмиграции.

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

И оставлю здесь тезисы, которые я готовила для выступления (но, как всегда, растеклась мыслию по другим аспектам, которые в моменте казались мне важными для проговаривания).

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

▫️Эмиграция — ситуация стресса. Из ситуации стресса всегда будет только два исхода: личностный рост или истощение. Если вы адаптируетесь успешно, это обязательно значит, что у вас на выходе произойдет некоторый личностный рост. Вы будете с чем-то справляться лучше, у вас появятся какие-то адаптационные навыки. У каждой свои. Если вы не адаптируетесь, произойдёт истощение. Это не смертельно, просто важно это принять во внимание. Даже если вы вернётесь обратно, какое-то время вам всё равно будет плоховато.

▫️Психологическая адаптация — не единственная. Исследователи выделяют разные виды адаптации: физиологическая, культурная, социальная, экономическая. Для меня всё, что не физиологическая адаптация — психологическая адаптация, потому что в конечном итоге всё перечисленное влияет на психику. А психика влияет на всё перечисленное.

▫️Психика — это главная ценность и приоритет при адаптации к чему угодно, в особенности к эмиграции. Если можно потратить чуть больше денег, но это сэкономит чуть больше душевных сил, стоит потратить чуть больше денег. Особенно это важно в долгосрочных вопросах (например, при съёме квартиры, которая в приоритете будет комфортной, а не дешёвой).

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

▫️Чтобы успешно адаптироваться, надо понимать зачем. На любом этапе привыкания важно не упускать из виду ответ на вопрос "зачем это всё". Чем чётче вы даёте себе ответ на этот вопрос, тем надёжнее ваша опора в этом месте. Вы полностью дезориентированы в городе и ищете куда выкидывать раздельный мусор — вы точно знаете зачем. Вы идёте сидеть в пятичасовой очереди в миграционке — вы точно знаете зачем. Вы сражаетесь с непонятной и нелогичной системой здравоохранения — вы точно знаете зачем. Вы получаете пятый отказ без объяснения причин, когда ищете работу — вы точно знаете зачем. Зачем вам продолжать это делать.

▫️В среднем делать какие-то выводы об адаптации в новой стране можно не ранее, чем через 3 года после переезда. Желательно все 3 года более-менее жить в этой стране и не уезжать жить подолгу на Родину.

#psy

Адаптация к эмиграции - 2

Что я сделала хорошо?

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

Что я бы сделала по-другому?

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

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

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

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

Немного ссылок на ту же тему:

- Виды усталости. Почему упоминаю их тут: в эмиграции навалятся примерно все, причем одновременно. Особенно если надо эмоционально комфортить не только себя. Мне кажется, заранее переоценить эту нагрузку очень сложно, а недооценить - очень легко! https://www.tgoop.com/testing_and_life/813
- Кейс: переезд по визе партнера: https://www.tgoop.com/testing_and_life/1076
- Кейс: переезд со сменой работодателя: https://www.tgoop.com/shooandendlessagony/118
- УПД: Кейс: еще одна эмиграция по рабочей визе год спустя: https://www.tgoop.com/prosvetlennaya/818, https://www.tgoop.com/prosvetlennaya/819, https://www.tgoop.com/prosvetlennaya/822

Про идеальные тест-кейсы - 1

“Тест должен быть написан так, чтобы его понял кто угодно”
“Тест должен быть понятным для ребенка”
“тест должен быть такой, чтобы его мог выполнить человек с улицы”

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

Когда-то я была с этим полностью согласна. Мысль, что можно создать Идеальный Тест, который может выполнить любой, выглядела очень привлекательной.
Но…

Если присмотреться к этой идее, она содержит несколько убеждений:

1) Точные инструкции, как работать - существуют
2) Тестирование может выполняться людьми почти без экспертизы, если дать им Достаточно Хорошие Инструкции
3) Если “случайный человек с улицы” это ты, то ты должен понять любой тест (приятная мысль!)
4) …а если ты не понимаешь тест, то это просто тест плохо написан (еще более приятная мысль!)
5) “Случайный человек с улицы” настолько важен, что команда адаптирует документацию именно к нему

Каждый пункт вызывает у меня очень большие сомнения.

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

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

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

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

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

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

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

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

Про идеальные тест-кейсы - 2

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

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

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

Нет правил, насколько детализированными должны быть тесты. Есть спектр решений, а какое решение мы выбираем - зависит от контекста, в котором мы находимся. Context-driven test design:)

Про идеальные тест-кейсы - 3

Какие тесты я называю “еретическими”?

Например, такие:

Summary: [Web] Authentication - Log in with valid credentials

Preconditions:
1. <precondition 1>
2. <precondition 2>

Actions
1. Open login page
2. Input valid credentials

Result
1. Application UI is loaded

Peculiarities
1. Example of credentials: username = <username>, password = <password>
2. <peculiarity 2>
3. <peculiarity 3>

Что тут как будто сразу плохо?
У теста максимально неконкретные результаты.

И в целом как будто много вопросов:

1. Как конкретно мы понимаем, что UI загрузился?
2. Почему вообще используем UI в качестве критерия, а не сообщения в логах, например?
3. Почему мы не проверяем, что мы залогинились именно тем пользователем, которому принадлежат юзернейм и пароль?
4. Кто виноват и что делать?

Теперь берем и помещаем этот тест в контекст.

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

В этом контексте существуют люди. Обычно люди чисто визуально отличают ситуацию “я залогинился, работаем!” и “что-то тут не то, надо поисследовать”.

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

Например:

- Smoke / build acceptance testing билдов/релизов
- Поддержка доставок на продакшен силами QA и/или саппорта, когда нужно поверхностно проверить, что система работает нормально
- Отработка failover процедур
- Работа с новичками: когда онбординг только-только начинается и есть задача дать общее (неглубокое) представление о системе (и не напугать прямо сразу)

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

Почему просто не написать 100500 нормальных тестов на логин и не использовать самые приоритетные для smoke тестирования или онбординга?

Да потому что нормальные тесты, скорее всего, потребуют нормального времени и ресурсов мозга. В каких-то случаях это будет работать, но только если нормальные тесты написаны так, что их можно выполнить буквально за минуту. Если же нормальный тест это (например) проверка работы токена, то, как мне кажется, лучше написать дополнительный максимально простой тест на “просто логин” и использовать его для smoke тестирования и других похожих целей.

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

Зима Podlodka близко! Открытая сессия 29 августа

29 августа (вторник) в 19:00 MSK состоится открытая сессия Подлодки.

Обсудим вопросы по оценке задач и метрикам, которые мы задаем на собеседованиях и ожидания от кандидатов разного уровня.
Приходите на сессию, приносите свои вопросы про оценки/метрики и хоррор стори про собеседования!

https://youtube.com/live/rWeFrIrSC80

Лирическое отступление про детализацию тест-кейса

Я встречала разное понимание того, что же такое детализация теста:

1) Как тест сформулирован: общО - как у меня в примере выше, или конкретно

2) Как много подробностей он содержит.
Один и тот же атомарный сценарий с конкретным результатом можно описать, добавив минимум необходимой информации или максимум вспомогательной информации. Или выбрать любой вариант посередине.

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

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

Podlodka близко!

Итак, контрамарку в партер билет на Подлодку получает @cleo_zed. Поздравляю!:)

Начинаем открытую сессию через полчаса!
https://youtube.com/live/rWeFrIrSC80

Провели открытую сессию, ответили на вопросы (на пару вопросов не успели, ответим на них в комментариях к записи).

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

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

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

Закончилась Подлодка, я наконец немного отдышалось и нашла время записать некоторые впечатления.

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

Я была основным куратором на докладе Валерии Калашниковой «Оценка задач: зачем, кому и как? », докладе Дарья Шельмук «Тайм трекинг: красный флаг или... просто инструмент?»
(И дополнительным куратором на еще одном докладе и воркшопе)

Очень ценный опыт - посмотреть на подготовку конференции изнутри.

Я уже занималась организационными вопросами и кураторством докладов, когда мы организовывали QA Sis Conf в марте-июле, но это была совершенно другая история.

У QA Sis Conf не было определенной темы сезона. Также на QA Sis Conf мы вообще не были ограничены выбором тем и могли включать доклады, которые больше относятся к “Как жить эту жизнь”, а не к контролю качества. Это была конференция, которую сообщество QA Sisters делало для сообщества QA Sisters - и это давало огромное пространство для маневра, меньшую стоимость ошибки и меньшую стоимость непопадания в чьи-то ожидания.

У Подлодки есть ориентация на практическую пользу и тему сезона, вокруг которой выстраиваются все доклады / круглые столы / воркшопы / интервью, это задает требования к теме доклада, которым нужно соответствовать. Важен внешний слушатель, его боли и то, получит он нужное ему решение или нет. Поэтому участие в программном комитете Подлодки - принципиально другой вызов, чем участие в организации QA Sis Conf.

Что было сложно?
Очень сложно было помнить, что курируемый доклад - не мой доклад. Что у спикера может быть (должно быть!) свое мнение. Вообще я думала, что споткнусь об это еще на QA Sis Conf, но нет, там не споткнулась. Видимо, потому, что курировала доклады про автоматизацию и геймдев - довольно далекие от меня темы.

Еще было сложно не вкладываться слишком сильно. Задачи, связанные с конференцией, заняли у меня в общей сложности около 50 часов (планировала потратить около 40). Получается около 20-25 часов в месяц. В будущем решу это планированием.

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

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

Определилась с планами на остаток сентября и ноябрь.

18-21 сентября - пройду курс Rapid Software Testing Explored
1 октября - схожу на оффлайн конференцию QA Challenge Accepted
12 октября - схожу на еще одну оффлайн конфу Istacon
26 октября - выступлю на оффлайн митапе с докладом про профессиональные сообщества (запись будет)
15 - 19 ноября - лечу в Стамбул встретиться с коллегами-админками QA Sisters. Обсудим планы по завоеванию мира развитию сообщества и наконец пообщаемся оффлайн.

(Где-то тут запланирован круглый стол по про процессы и начало работы над следующей QA Sis Conf)

Дальше заворачиваюсь в одеялко и окукливаюсь до начала 2024.

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

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

Но в реальности оказалось, что больше мешает поверхностное знание того, как работает мышление/познание/человеческое общество.

QA Challenge Accepted - 1

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

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

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

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

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

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

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

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

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

Репрезентация у этой конференции не очень: изначально была только одна женщина-спикерка, потом агенда поменялась и не осталось ни одной.
В прошлом году ситуация была похожей: была 1 или 2 спикерки на 10 докладов.

Доклады можно смотреть как из основного зала, так и из шатров снаружи (там есть кресла-мешки и экраны, на которые транслируется запись из основного зала).

Полностью послушала три доклада и Lightning talks, частично (или вполуха) еще два доклада, потом напишу подробнее.