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

1. Собеседование - не экзамен.
Конечно, идеально проходить собеседование, блестяще отвечая на все вопросы - приятно. Чувствуешь себя рокстаром и ещё не выйдя из переговорки начинаешь прикидывать, поместится ли цифра из твоего оффера в longInt переменную.
Но это - только один из исходов. Такой же нормальный, как и тот, когда ты завалил какие-то вопросы, иногда путался и плавал в отдельных темах. И такой же нормальный, когда ты завалил всё и вышел с собеседования чувствуя себя идиотом.
Во первых, собеседование - это попытка за довольно ограниченное количество времени прощупать уровень знаний кандидата. Причем, способы проверки этого уровня знаний субъективные, зависят от собеседующего, компании и конкретной позиции, и далеко не всегда коррелируют с реальной компетентностью человека.
Во вторых, любой исход собеседования - это фидбэк, с которым можно работать. Тебе задали вопросов, на которые ты не смог ответить - окей, это повод вернуться домой и разобраться в этих областях достаточно, что бы в следующий раз ты смог ответить.
В третьих, негативный исход собеседования не означает, что ты - тупой и пошел вон из профессии. Это значит, что конкретно эти ребята не готовы сейчас позвать тебя на эту позицию. Всё.

2. Хватит нервничать и врать.  
Это напрямую проистекает из первого пункта.
Как только цель собеседования меняется с "пройти на отличненько любой ценой" на "показать, чем я могу быть полезен компании" - решается сразу масса вопросов, а стресса становится куда меньше.
Если ты не знаешь ответ на вопрос, который тебе задают - просто так и скажи. Если ты не знаешь, но есть предположения в каком направлении нужно двигаться - так и скажи.
Идеальным исходом собеседование является то, что ты понимаешь, какой кандидат нужен команде, а команда понимает, какой уровень скиллов у тебя есть. Как только идет перекос в любую сторону и какая-либо из сторон старается продать себя лучше, чем есть - начинаются проблемы. В лучшем случае, ты получишь пачку вопросов к которым ты не готов. В худшем - ненадолго получишь работу, к которой ты не готов.

3. Собеседование - для обеих сторон.
Это стандартный тезис, основным посылом которого является то, что проходя собеседование ты так же оцениваешь команду и компанию, как они оценивают тебя. Задавать вопросы - можно и нужно, получать информацию - можно и нужно, встать и уйти если ты понимаешь, что творится какая-то дичь - можно и нужно.
Но в контексте двух предыдущих пунктов я упомяну немного другой момент. Для кандидата любое собеседование, даже проваленное - это экспириенс. Это повод получить новых знаний, это повод проверить свои знания, это повод научиться лучше продавать себя и показывать свои знания.
Проваленное собеседование - повод для личного post mortem, получения новых знаний и саморазвития. В то время, как слишком "успешное" собеседование - тоже довольно тревожный звонок, потому что служит показателем того, что ты уже обладаешь всеми знаниями, которые ожидают от человека на данную позицию. Возникает резонный вопрос: если ты уже знаешь все необходимое для решения твоих рабочих задач, будет ли у тебя возможность и повод развиваться на этой работе?

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

И да, важный пункт, про который я забыл.

4. Хватит ждать, пока вам пришлют фидбэк. Получайте его.
Всё, что происходит в ходе собеседования - уже фидбэк.
Все вопросы, которые оказались для вас сложными - фидбэк.
Все уточняющие вопросы по вашему резюме - повод задуматься, что можно в нем поправить.
Фидбэк, который придет от HR - это только часть. Совсем не главная.

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

Не проходит недели, что бы в каком-нибудь из QAшных сообществ не произошел холивар на тему овертаймов, срочных хотфиксов посреди выходного и прочих радостей жизни, с которыми сталкивались, наверное, все.
Традиционно звучат тезисы про то, что такие кейсы - результат косяков менеджемента, про двойную оплату овертаймов, про ворк/лайф баланс и про то, что тратить своё личное время "пахая за спасибо на дядю" - удел для наивных студентов и ноулайферов.
Ниже моё личное мнение, к которому совсем не обязательно прислушиваться. Это просто ещё одна точка зрения.
Так вот, ребята. Это всё, конечно, так.
Регулярные факапы и овертаймы говорят о том, что что-то идёт явно не так.
Соблюдение ТК и дополнительная оплата овертаймов - хорошее дело. Ворк/лайф баланс - важно.
И тратить своё личное время никто никому не обязан.
Проблема в том, что как только ты встаешь в позу по этому поводу - ты, как бы, начинаешь получать такое же отношение в ответ.
За время своего трудового стажа я, должен признать, наовертаймил ещё, наверное, на пару лет. По разным причинам. Иногда мне было действительно интересно то, что я делаю и я просто работал в своё удовольствие.
Иногда я понимал, что нафакапил и подставляю команду и пора было закрывать свои же косяки. Иногда потому, что были факапы менеджмента, коллег или ещё кого-то. Иногда потому, что ко мне приходили и просили повпахивать до победного.
Почти во всех этих случаях овертаймить было моим решением.
И примерно всегда я получал в ответ то же отношение, с которым подходил к работе.
Гибкий график, к которому мы все так привыкли, обычно никак не описан с точки зрения ТК и трудового договора. Желание свалить пораньше или придти попозже, а не сидеть 9 жопочасов - тоже ситуация, к которой я привык.
Непродуктивные дни, когда твоё залипание в монитор и копание с петпроджектами оплачивается, а делать задачи просто нету моральных сил - история, которая со мной тоже случается.
Отгулы когда мне это нужно и банальное "ребят, у меня тут жопа, мне нужна зарплата на неделю раньше" - бывало всякое.
И знаете, мне кажется, что такое отношение со стороны руководителей и работодателя гораздо важнее, чем получить дневную оплату за то, что потратил пару часов своего выходного дня на тестирование хотфикса, который поднимет прод.

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

Новый любимый вопрос для собеседований:
- Какие лучше всего использовать фреймворки, если стоит задача автоматизировать тесты (фронтенд\бэкенд\мобилы\контракты)?

Ожидаемый ответ:
Лучше всего - никакие.

В продолжение предыдущего поста.

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

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

Но, теперь к главному и самому дискуссионному вопросу.
Почему бы я хотел услышать в ответ "Лучше всего - никакие".
Спойлер: это не про то, что тестовые фреймворки - зло и надо писать всё самому.
Я ожидаю услышать этот ответ, потому что оптимальным решением любой задачи будет самое простое и выдающее при этом необходимый результат.
Классные ребята, в далеких 90х сформировавшие основные концепции экстримального программирования, описали это простым тезисом:
“do the simplest thing that could possibly work”.
Позднее этот тезис лег в основу всяких крутых паттернов и принципов вроде KISS и YAGNI.
Про это написаны миллионы текстов, но они все ещё не способны победить аргументы в стиле "а вот будет у нас через три года миллион тестов и всё".
Если тебе нужен скейтборд сейчас, а через год понадобится космолет - сделай сначала скейтборд.
Допиливай его по мере необходимости, занимайся рефакторингом, оцени и осознай, что именно тебе понадобится что бы превратить его в космолет.
Но сначала сделай просто.
Реалии разработки таковы, что, вполне возможно, через год твоего проекта не будет.
Или будет, но ему нужен будет совсем другой космолет. Или не космолет, а звезда смерти.
Но пока для твоих задач хватает скейтборда - пользуйся, черт подери, им.

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

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

В завершение, хорошая книжка на почитать:
Extreme Programming Explained: Embrace Change by Kent Beck, Cynthia Andres

Немного боли про opensource и, частично, про его тестирование.  

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

К сожалению, довольно редко команда, как и человек, озвучивший этот вопрос, понимает объём работы, стоящий за выпуском чего-то в опенсорс. Спойлер: этот объем колоссален.  
Выпуск и поддержка опенсорс продукта - это совсем другой процесс, нежели разработка проприетарного SaaS или внутреннего продукта.
У тебя другие цели, другие риски, другие приоритеты и совсем другие подводные камни.
Тут кроется действительно много нюансов, с которыми в повседневной работе сталкиваются далеко не все.

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

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

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

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

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

Как все вы заметили - я довольно редко пишу в этот канал.
Иногда это связано с недостатком времени, иногда с отсутствием идей для постов.
Впереди много работы и планов на тему того, как это исправить и привести в порядок, поэтому stay tuned.
А пока что пост, на который меня вдохновил один из холиваров в QA Junior чатике.
Он не совсем про тестирование, но и про него в том числе.

Про работу в распределенных командах.

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

Основной проблемой, конечно же, является поддержание коммуникации, синхронизации и общего контекста между людьми.
Ещё сильнее эта проблема начинает работать, когда команда частично распределена.
Как только хотя бы один член команды уходит на удаленку это значит, что все встречи, митинги и обсуждения должны проводиться только в онлайне.
Никаких больше разговоров про работу в курилке, у кулера или на обеде. Просто потому, что итогом этого становится то, что человек выпадает из контекста и уже не знает, почему были приняты те или иные решения.
Никаких больше командных посиделок в баре и корпоративов, если вы не можете обеспечить возможность присутствия удаленных членов команды.
Никаких больше "давай подойду голосом обсудим".
Если всего этого нет, то на каждый юнит своей распределенной команды, кроме основного, тебе надо тратить 4-5 часов в неделю.
Просто на то, что бы транслировать всё, что было пропущено.
Может помочь привычка фиксирования результатов встреч и дублирования всего, что было обсуждено голосом в чаты\почты\вики, но, это всё равно приводит к тому, что люди вне офиса узнают о происходящем пост-фактум (причем, обычно, не сразу).
Эти изменения не являются проблемой, и довольно часто несут в себе больше плюсов, чем минусов, но это большая процессная работа, которую надо вести с командой и бить по рукам тех, кто не следует этим правилам.
Есть и менее очевидные истории, например, возможность удаленной работы требует серьезных изменений в процессе онбординга, потому что уже не получится сесть рядом с новичком и показать всё самое важное.
Про то, как правильно строить работу распределенных команд отлично рассказывают ребята из Stackoverflow, в том числе в своём блоге.  

Вторая проблема кроется в том, что несмотря на популярность идеи удаленки, есть довольно мало людей действительно способных продуктивно работать не в офисе, особенно если работа идёт не в формате "транслирую ТЗ в код".
По этому поводу тоже есть множество постов, которые сводятся к тому, что работа дома - довольно непривычный для людей паттерн.
Это требует самодисциплины, организации рабочего места дома, объяснения себе и окружающим что "Ребята, меня не трогать, я работаю".
И с одной стороны Remote First\Remote Friendly политика дает компании доступ к кандидатам со всего света, с другой стороны - заставляет придумывать, как на этапе отбора находить людей, которые действительно готовы к удаленной работе, потому что проверять это на практике - оказывается слишком дорого для компании.
При этом есть мнение, что по факту рынок кандидатов сужается по сравнению с поиском людей в офис в условной Москве или Питере.

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

Теперь давайте представим, что вам нужно организовать ферму мобильных девайсов для отладки и тестирования в команде, которая живёт в 12 разных точках планеты. Часть кейсов закроют эмуляторы, другую - существующие сервисы типа SauceLabs, для части можно будет собрать велосипед для удаленного доступа на девайсы. Но при этом возможность подойти, забрать нужный тебе девайс и поработать с ним это не заменяет.
Добавим к этому стабильную сеть, мониторы, переходники (а в некоторых случаях ещё отладочные платы и прочее) и получаем тот ещё квест.

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

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

Меняем процессы?

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

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

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

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

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

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

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

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

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

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

Короткая история о профессиональном признании и тесном IT мире.

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

Кажется, друзья, это успех.

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

Тестирование является довольно легкой точкой для входа в айти.
Помимо миллиона курсов, обещающих сверхзарплаты через 2 недели, а также большого количества соискателей, прочитавших одного только Савина, это рождает ещё и устойчивое мнение что QA - это просто.
Действительно, сформировать какой-то необходимый минимум для тестирования проекта - довольно объемная, но не такая уж и сложная, задача.
Только QA - это немножечко больше, чем тесты на API, девять с половиной ручек селениума и тестраннер прикрученный к CI.
Качество стоит дорого, а его обеспечение требует мозгов, скиллов и способности решать задачи, а не просто пилить покрытие тестами ради покрытия тестами.
Сделать тесты эффективными, быстрыми, масштабируемыми и прозрачными для всех, чью работу они затрагивают - сложно.
Сформировать такой набор тестов и тестовых данных, чтобы тестирование действительно говорило об уровне качества системы, а не просто показывало красивый список зеленых тестов, пока пользователи и бизнес продолжают страдать - сложнее, чем научиться применять граничные значения и классы эквивалентности.
Добиться того, чтобы на каждое падение не приходилось проводить длительный root cause analysis - тонна работы, как со стороны самих тестов, так и со стороны тестируемой системы.
Если QA-инженер не обладает достаточной экспертизой, чтобы решить как это должно быть сделано, то все эти задачи так и останутся нерешенными.
Всё перечисленное выше - то, что на поверхности.
Помимо этого есть куча направлений работы и множество задач, ограниченных только вашими скиллами, желанием и способностью объяснить окружающим, и себе, зачем это нужно.

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

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

#qanotquitefordummies

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

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

Но:
- Какой Expected Result будет в таких тестах? Что мы считаем "успешным" взятием детали?
Ведь деталь можно взять с разных точек захвата, с разной силой сжатия, под определенным углом, с разной степенью фиксации в пальцах.

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

И это не самое интересное.
Самое интересное начинается, когда задаешься вопросом "а с помощью чего мы будем всё это проверять?"
Часть проблем решается тем, что у нас есть классный симулятор, служащий для нас виртуальным тестовым окружением.
Но это не может, к сожалению, заменить работу на реальном железе.
Например, получить положение объекта с субмиллиметровой точностью в физическом окружении уже немножко сложнее.

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

А мы просто хотели научить робота брать детальку.

В предыдущих постах я несколько раз упоминал, что одна из задач QA - сделать качество измеримым и прозрачным.
Хочется проговорить про это немного подробнее.  
Начать стоит с того, что единственный, на мой взгляд, способ создать действительно крутой продукт - строить его исходя из цифр.
Важно понимать зачем делать определенную фичу, почему она делается именно так и какой результат должен быть получен.
Бизнесовые, продуктовые и технические метрики, а/б-тесты, инструменты для простой проверки гипотез, анализ аудитории, customer journey и прочее.
Все это позволяет понять, что действительно добавляет value продукту, на что стоит тратить ресурсы, и, что не менее важно, насколько полученный результат соответствует ожиданиям.
С качеством это работает так же.
Написать какой-то набор тестов, закинуть их в тестрейл или CI систему и сказать "ну, теперь если тесты зеленые - то всё окей" - недостаточно.
Задача QA здесь - создать такие процессы и инструменты, с помощью которых каждый заинтересованный член команды сможет быстро и просто увидеть состояние качества продукта.
Из этой задачи и возникают вопросы: как измерять качество и как сделать результаты этих измерений прозрачными и понятными.

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

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

Метрики приложения. Любой участок приложения, не покрытый метриками - это черный ящик. Всё, что мы можем о нём сказать сводится к "оно вроде работает". Если для вашего приложения ещё не сформирован набор метрик, критерии оценки и пороговые значениия для этих метрик - самое время пушить их формирование.
Если они уже существуют - убедиться, что ваши тесты учитывают и отражают эти самые метрики. Деградация новой версии приложения с точки зрения метрик - такой же повод блокировать релиз, как и падение функциональных тестов.
Некоторые из метрик довольно сложно проверять в рамках тестовых окружений. Здесь сильно помогают feature flags, позволяющие проверять гипотезы только на части аудитории.  

User & Business Needs. Потребность пользователя - очень эфемерная сущность. Но невозможно обеспечивать качество, если ты не анализируешь как в действительности пользуются твоим приложением.
Здесь помогают UX- и a/b- тесты, тепловые карты, анализ поведения пользователей, фокус-группы, общение с пользователя, обработка и анализ обращений и отзывов пользователей и многое другое.
Основная проблема - ресурсоемкость, организация правильных UX-тестов и фокус групп требует чертовски много ресурсов.
Первое, что стоит сделать - наладить процессы получения информации. Больше обсуждать реальные сценарии использования, построить процесс взаимодействия с техподдержкой, анализировать фидбэк пользователей.
Нельзя забывать, что потребности бизнеса могут не совпадать, а иногда и противоречить потребностям пользователей. Общение с бизнесом, понимание его нужд и проблем, а так же налаженный процесс обмена фидбэком - критически важная часть обеспечения качества продукта.

Существующие проблемы. Сложность с фидбэком пользователей в том, что писать в техподдержку будет ~10% пользователей, а остальные 90% - уйдут в другое приложение, если могут, или будут молча страдать.
Здесь может помочь анализ и мониторинг логов приложения, инструменты агрегации ошибок (напр. Sentry), динамика дефектов и прочее.
Отслеживание точек потери пользователя, аномально высоких окончаний сессии, распределения багов и ошибок по сценариям и компонентам сервиса - всё это позволяет понять, где можно начинать искать проблемы.

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

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

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

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