В конце апреля проходила конференция тестировщиков SQAdays. Я люблю эту конференцию за атмосферу сообщества, интересное общение в кулуарах. У тестировщиков оно качественнее, чем у аналитиков, хотя, казалось бы, должно быть наоборот. Но это не значит, что такая атмосфера - на любой конференции тестировщиков. Они - разные, а атмосфера SQAdays - особенная, я это чуствую сам и знаю по отзывам других участников, в том числе тех, кто давно в индустрии и видели много интересного. B замечательно, что у организаторов получается ее сохранить уже на протяжении 30(!) конференций, из которых я был примерно на половине.

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

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

Исправление ситуации предлагается через просвещение.

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

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

Еще было про книги: Савин, с которого обычно начинают - букварь. А еще есть Майерса, Канера, Блэка. И о них стоит знать и читать.

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

Что надо сделать, став тимлидом?

• Осмотреться: задачи, объем работы, сотрудники, с кем надо общаться кроме руководителя и команды.
• Встречи 1:1 с членами команды. На встрече надо выяснить ожидания, и не просто записать - а потом поработать с ними.
• С кем общаться - другие тимлиды, аналитики, разработчики, продукты. Если вы выросли в команде - то, вероятно, представляете это. А если пришли в новую - надо выяснить, бывают неожиданные штуки.
• Сделать план на 1-2 месяца, и на него смотреть. Она сделала не сразу, действовала реактивно - и что-то пропускала. Потом начала планировать.

Дальше был такт про страхи. Осознание страхов - первый шаг к исправлению.

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

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

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

Страх показаться некомпетентным. Она была единственным тимлидом без опыта. И решила для себя ничего не спрашивать у других, чтобы они не заметили незнания. Это было ошибкой, надо спрашивать - проблемы решатся достаточно быстро. Бывает, что расширилась область, и ты ее не знаешь столь хорошо, как знал свой участок. Это - нормально, изучайте, спрашивайте.

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

И дальше были советы про полезные техники. Планирование времени.

• По SMART. Легко и удобно. Если задача не отвечает таким критериям - переделываешь. Пример: Цель обеспечить безупречное качество проекта Пульс. Делим на подпроекты, ставим измеримые критерии качества вместо безупречного.
• Матрица срочности-важности. Только многие менеджеры ставят срочность всем задачам, с этим надо разбираться.
• Переработки и делегирования. Многие не делегируют, полагая что сами сделают лучше. Но! На тимлида валится организационные задачи, и в результате решение задач простаивает. Делегировать стоит то, что не важно, но срочно. Без делегирования начинаешь перерабатывать. на на эти грабли наступила, 10-12 часов в день. И ты идешь к выгоранию. Микроменеджмент. Начальник осуществляет постоянный детальный контроль. Причина - страх начальства, что сотрудники не справятся. А приводит к тому, что сотрудники реально делают только простейшие вещи. Уходите от микроменеджмента.

Продолжение в комменте...

• Конкретна, а не общими словами
• Описательная, а не оценочная
• Нацелена на улучшение ситуации

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

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

• Направлена на работу, а не на человека
• Конкретна, а не общими словами
• Описательная, а не оценочная
• Нацелена на улучшение ситуации

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

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

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

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

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

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

• Сколько стоит добавить автотест, сколько стоит его поддерживать
• Сколько стоит и как быстро можно найти специалиста
• Как быстро новый специалист войдет в работу.

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

Это - объективные метрики. А вот используемые шаблоны программирования - это уже дело вкуса, если на эти метрики оно не влияет.

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

• Принцип ортогональности: сущности не влияют друг на друга. Усложнение сущности А не влияет на ее тень на сущность Б. Тень - это интерфейс взаимодействия.
• Декомпозиция: Слои/уровни - горизонтальная декомпозиция, Usecase - вертикальная декомпозиция. Чем сильнее пирожок разрезан - тем легче и проще он помещается в голове и разрабатывается. Но всегда точка баланса, когда много сущностей - умираем по версионности, играет согласованность изменений.
• Дублирование кода. Все слышали, что это - зло. Don't repeat yourself, единая точка правды. Но! дублирование бывает истинное и ложное, случайное. Например, когда мы начинаем разработку, то идет прозрачное отображение DB-back-front. Но! дальше они могут изменяться по разным причинам, и транспортные объекты могут меняться. Я, правда, хочу отметить, что это вопрос архитектурных принципов. Может быть жесткая политика единства объектов, отражающих бизнес-объекты, изменяющиеся обязательно синхронно, а может быть наоборот, развязывание, независимость слоев.
• Единицы повторного использования - Release.
• Принцип согласованности изменений. В один компонент должны включаться классы, изменяющиеся по одним причинам в одно время. Это принцип единственной ответственности для изменений. Компоненты крупные.
• Простота сопровождения важнее повторного использования.
• Не вынуждайте пользователя компонента зависеть от того, что им не требуется. Не должно быть нужно тащить большой компонент ради красивого бордера. Он в обратную сторону, делает компоненты меньше.
• Принцип устойчивых зависимостей: модули, с трудом поддающиеся изменениям не должны зависеть от моделей, которые сделаны для легких изменений. Мы должны проектировать/предполагать изменчивость модулей на этапе проектирования. И контролировать направления зависимостей. Был пример преобразования архитектуры - когда был выделен стабильный модуль интерфейса и несколько модулей реализации, которые чаще меняются.
• Принцип устойчивой абстракции.

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

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

• Подключаться на Планировании, а не потом, когда настало время тестировать.
• На планировании надо думать и спрашивать "как будем тестировать, где будут тестовые данные". И это важный вопрос и для разработчиков тоже - они заранее знают критерии приемки.
• Передача задач в тестирование - надо проговорить, что на этот момент будет, например, актуальная документации. У них в некоторых командах есть QA Notes разработчиков.
• Когда выбирают какой-то новый фреймворк или технические устройства - есть ли драйвер для автотестов? Разработчики при выборе об этом могут не думать.
• Все знают - нужны хорошие локаторы. Но у них классы - обфуцированы, чтобы защититься от внешних атак, чтобы не ходили боты. Но! у них есть атрибут qa-id, который делает удобные локаторы, но которые появляются только если приложение запущено в режиме автотестов. Только надо не забывать, чтобы разработчики эти локаторы добавляли.
• Тестовые данные - надо проговорить в момент планирования. Для их создания или запроса - бэкдорные ручки. Чтобы найти ЮЛ, или группы товаров. Один вход создает, другой - забирает, и за ними - запросы в БД. Которые пишут разработчики. Их можно собрать в один сервис, и проектировать целостно. Об этом будет отдельный доклад.
• Тестовые варианты. В lazada - была технология шоу-румы: целый интернет-магазин поднимали в кубер-кластере. И под каждую задачу можно было поднять по кнопке. Это удобно, но дорого. В озоне - сервис-меш. В начале цепочке вызова ставят специальный заголовок, чтобы у конкретных сервисов взяли тестовую версию вместо основной.
• Снятие барьеров. Логин, оплата, смс, email, капча. Их надо облегчить, потому что мы же не тестируем авторизацию или смс. Нужно, чтобы приложение это поддерживало, например, магический логин или эмулировало результат оплат. Но при этом реальные оплаты тоже надо тестировать - только там может быть смысл уменьшения барьеров, либо автоматический возврат для тестовых оплат - и это надо проговорить с разработчиками. СМС - без них, или флагами превращать в email если надо проверить содержание смс. Капчи тоже надо уметь отключить. Но эти механизмы тоже надо тестировать - как и бэкдор.
• Тестировать нужно не только в тестовом контуре, но и на проде. Потому что многое конфигурируется шаблонами, без изменения кода, это делают менеджеры - и только на проде.
• Надо выбирать совместимые технологии. Если разработка на Go - используйте Go. А если вы выбрали python - это будут ваши проблемы. Если фронт и бэк на разных языках - изучайте оба, и это - возможность.

Success story интеграции процесса разработки и тестирования через автоматизацию. Около года назад каждый спринт был маленьким водопадом. Начали с этим разбираться. И сейчас совместили разработку и тестирование так, что ручное тестирование занимает всего 1 час.

Команда была 2 аналитика 5 разработчиков 3 тестировщика и техлид, Web-приложение, фронт и бэк, интеграция, на микросервисах. Поддержка тоже на команде. Год назад регресс занимал 3 дня каждый спринт, не было тестов UI и API, а unit - формальный ради покрытия. Плюс тестирование часто не успевало, разработчики кодили до последнего момента, и задачи съезжали.

Это решили изменить. И у них получилось.

• Тестировщики пишут UI автотесты. Параллельно с разработкой. Но! Они пишутся долго и не самые стабильные. Поэтому они превратились в еще больший техдолг.
• Интеграционные автотесты - они двинули дело вперед, потому что не только задачи текущего спринта, но и регресс. И интеграционные тесты оказались устойчивее UI
• И тут один тестировщик ушел. B чтобы не просесть в тестировании, разработчики начали писать автотесты. Код автотестов стал качетсвеннее. И автотесты закрыли почти весь регресс. По сути объединение разработки и тестирования.
• И тут ушел еще один тестировщик. попробовали привлекать аналитиков - но просели по анализу. И начали анализ дефектов из тестов и прода: могли ли его найти раньше, могли ли его не допустить.
• И тут поняли, что часть дефектов могли бы найти на юнит-тестов. И они увязали юнит-тесты с тест-кейсами. Разработчики с тестировщиками пишут осмысленные юнит-тесты. Начали анализировать каждый кейс до взаимодействия модулей, чтобы набор юнит-тестов покрывал тест-кейс. И покрытие автотестами возросло, при этом необходимость в части интеграционных автотестов ушла.
• На уровне интеграционных тестов - моки.
• Дефекты, которые были следствиями багов в UI-компонентов - модульные тесты на UI. И стало не нужны часть тестов на UI.

И сейчас у них 5 разработчиков и 1 тестировщик, и ручное тестирование - только час времени за спринт.

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

• Понимание работы устройства и взаимных влияний. Производительность точки доступа роутера, к которой подключено 20-40 устройств - на него влияет, если в зоне действия кто-то слушает музыку по bluetooth, и это надо представлять и делать тесткейсы с учетом этого.
• Тестирование скриптами для api - rest и soa, web для админки устройства и unix, потому что обычно стоит какая-то версия linux.
• Навыки работы с паяльником - далеко не всегда разъемы распаяны на устройствах, а бывает нужно подключиться когда оно, например, превратилось в кирпич при обновлении и надо разобраться что произошло.

Виды оборудования.

• Черный ящик - закрытое ПО для работы с неразборным устройством. Мы должны уметь проверить пользовательский режим
• Серый ящик - стоят драйвера и что-то базовое, а мы поверх ставим свою прошивку. И надо тестировать уровень драйверов и прошивку.
• Белый ящик - поставлено только железо, драйвера и весь софт и пишем мы. Наиболее сложный случай.

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