Мне жаль, что ваш опыт работы заключается в таких проектах, как вы описали.
Если в команде нет требований к минимальному покрытию unit-тестами, и коммуникация развита так, что нет возможности донести необходимые для поддержания качества требования, то вам стоит начать с базовых процессов построения качества в команде. Удачи вам в этом!
Спасибо, что поделились опытом! Полностью согласна про косвенные бонусы, у нас сильно выросло взаимопонимание при разборе задач, стали говорить на одном языке, если можно так выразиться. Масштабировать пока не пробовали, будем над этим работать. Удачи вам в ваших проектах)
Привет, спасибо за вопрос! Да, такой подход действительно требует большого количества времени. Проработка тестов в начале частично сократит конечную работу и, по моему опыту, уменьшит количество итераций тестирования т.к. большинство корнер-кейсов уже будет предусмотрено.
Но в общем и целом времени это займет больше, поэтому важно договориться с командой. Выгода по времени будет в перспективе — благодаря высокому покрытию автотестами, будет меньше трудозатрат на поддержку качества, но посчитать это довольно сложно.
Т.е. Вы столкнулись с проблемой привязки номера, вам помогла поддержка, и вы с весны ждали рандомную статью от сотрудника Авито, чтобы написать, что ей грош цена, раз вы с этим столкнулись?) Как именно этот комментарий относится к технологии покрытия микросервисов тестами?
Давайте действительно попробуем сформулировать таким образом (тут есть смысл говорить про практики Agile-testing):
«Shift left следует использовать в Agile и не нужно использовать в Waterfall потому, что это противоречит принципу последовательности процессов в Waterfall.»
В то же время, если говорить о другой практике, например, про пирамиду тестирования, то её вполне можно использовать и в waterfall подходе. Есть и другие, часть которых противоречит, часть подразумевает включение тестировщика в начальные этапы, например, «встреча 3-х амиго», а часть вполне можно использовать в отрыве от подхода, например, исследовательское тестирование.
Т.е. Некоторые практики, применяемые в Agile, которые мы хотели включить в свои процессы, противоречат последовательному построению этих процессов, и в целом у нас не было идеи удержаться в рамках какого-либо подхода.
Agile-подход это грубо говоря набор практик и ценностей, которые, конечно, можно применять еще где-либо, но по нашему опыту, вместе они работают вполне эффективно. И нет необходимости применять отдельно практику из этого подхода, когда можно перейти на методологию в целом. Но если вам так удобно, и вы хотите сохранить подход, прикрутив к нему другие практики, то мне было бы интересно узнать как это работает и почему именно так.
«Вы сами себе противоречите.
Подпись под картинкой: «Одна выделенная стрелочка — один поход — одна проверка в unit тесте»»
— На картинке обозначено взаимодействие сервиса, со стрелочкой лишь пример, как это можно применить. При желании, на ней можно добавить обозначения тестов разных уровней, но я этого не делала и такого смысла в неё не вкладывала.
«Это тоже очень сильное заявление, которое больше запутывает, чем дает понимания того, что вы делаете и зачем это надо.»
— Я действительно опускала датасеты из e2e-тестов на уровень юнит-тестов. Этот пункт в разделе статьи «как решали сложность в понимании unit-тестов», так мы повышали компетенцию в том, что можно опустить на этот уровень. На новую функциональность, когда кода еще нет, QA unit-тесты не пишет.
«Практика есть у вас, судя по статье(хотя я спрашивал про интеграцию, а не про юнит, ну да ладно)».
— Я не пишу интеграционные тесты на бэкэнд, поэтому и не приводила их в пример.
«В отрыве от контекста и без понимания как эффективно(а не тестировщик глазами) мапить юниты на, как минимум, интеграционные говорить о целесообразности такого подхода нельзя(если только мы не говорим о продукте где не предъявляются высокие требования к качеству).»
— Как маппить автотесты разного уровня — тема для отдельной статьи, моя статья на этот вопрос не отвечает, а рассказывает о процессах внедрения подхода agile-тестирования.
Привет!
На картинке нарисована не схема тестирования, а общее взаимодействие сервиса. Тесты на ней не обозначены. Мы нарисовали её для общего понимания, что нам нужно будет покрыть.
Unit-тесты выделены в статье, так как с пониманием остальных уровней тестов проблем не возникло. То есть мы выделили интеграционные, компонентные, e2e тесты, а вот с пониманием, что можно опустить на юниты, возникли трудности.
QA, не пишет unit-тесты, поскольку они зависят от структуры кода. Если у вас есть практика, где такое происходит, то мне было бы интересно узнать, как это работает.
Обязательная часть методологии — это практика движения тестов на более низкие уровни. Изначально у нас было много e2e тестов, потому мы их опускаем.
Знаю, что на теме уровней автотестов возникает много столкновений. Под юнит-тестом мы понимаем атомарную проверку внутренней работы сервиса :)
В статье я сравнила подходы Waterfall и Agile. Agile в нашем случае сработал лучше: мы научились предотвращать ошибки на более ранних этапах и избавили тестировщика от монотонной работы. По времени, конечно, ускорились не сразу. Вначале и вовсе замедлились. Но мы понимали, что этот подход увеличивает скорость в долгосрочной перспективе — за счет хорошего покрытия автотестами.
Сравнить с какими-то другими методологиями я не могу — их не использовала. Если напишите пример из методики, которая вас интересует, или применение таких же практик, в другом подходе, то смогу вам ответить точнее :)
Привет! Да, мы используем TMS. Правда, у нас свой собственный инструмент. Отдельная команда подпиливает его для наших нужд.
Мы стараемся хранить тест-кейсы всех уровней в одном месте, чтобы видеть общую картину. При создании (ручном или автоматическом) мы указываем тип тесткейса — e2e/component/integration/unit, там же у нас видно покрытие. Пропорции пирамид смотрим уже в Grafana.
На данный момент столкнулись с тем, что некоторые unit тесты не содержат никакой бизнес-логики, и вопрос об их хранении в общем месте — спорный. Это уже на ваше усмотрение, зависит от цели хранения тесткейсов.
Некоторые другие TMS, насколько я знаю, тоже имеют поле «Тип тесткейса». Например, PractiTest, либо можно пользоваться любой другой удобной маркировкой.
Если захотите узнать чуть больше про нашу тестохранилку, то советую почитать статью моего коллеги Вадима Шашина What Does Our Test Case Management System Look Like?
Не знакома со взглядами Егора Бугаенко, но обязательно ознакомлюсь. Спасибо!
Но против такого подхода не имею ничего против. Как минимум, если не писать автотесты, то ревьюить точно надо. Так ты уверен, что конкретно тест проверяет, а что он мокает.
Насчет код-ревью вопрос спорный. С одной стороны, тратится больше времени (тестировщик будет читать код медленнее, если не рассматривать вариант с senior developer’ом), с другой — повышение компетенции. Почти уверена, что если бы тестировщики участвовали в ревью кода — выхлоп в нахождении багов на этом уровне точно был бы. Остается оценить затраты на обучение тестировщика и применение этого навыка в будущем.
А если рассматривать такой вариант, то выгода компании тоже спорная, ведь senior developer в тестировании, как мне видится, будет элементарно дороже.
Это вопрос на «поразмышлять» и немного выходит за рамки темы. Кажется, что каждому своё :)
Конечный флоу:
1. Постановка задачи.
2. PBR-встреча, или по-русски: встреча, на которой мы оцениваем задачи, обсуждаем их постановку, задаем друг другу вопросы, проговариваем риски.
3. Задача следует в бэклог.
Мне понятно, почему возникло непонимание. Действительно, не все осветила. Спасибо за этот вопрос. Дело в том, что мы решили, что ответственный за постановку задачи теперь тот, кто ее пишет, а не тестировщик. А уже на PBR встрече я (или другой член команды) можем внести коррективы. Это, скорее, про работу команды: можно это и не вводить, но с какого-то момента задача просто стала лучше описываться.
Так привыкла к этим терминам, что не заметила, как плотно они вошли в мою речь — у нас давно ввели Scrum )
В моем случае внедрение подхода прошло спокойно — в соседней команде уже успешно его применяли, и мы это видели. Какой-то формальной процедуры согласования у нас нет. Только если на прохождение мастер-класса. У нас всё просто: если ты хорошо выполняешь свою работу и в срок — то делай её хоть с помощью бубна (немножко утрированно, но в целом подход такой).
Но, тем не менее, я считаю, что аргументировать преимущества — важно. В чем плюсы:
1. Увеличение скорости тестирования. Скорость будет увеличиваться за счет уменьшения итераций, поскольку очевидные кейсы будут покрыты автотестами, а крайние моменты будут обсуждены в момент описания задачи, и разработчик сможет их предусмотреть.
2. В перспективе, активное уменьшение регрессионного тестирования. Регресс автотестами в разы стабильнее и быстрее ручного — думаю, это очевидно.
3. Стабильный уровень качества. Он также будет зависеть от ваших автотестов, но если бизнес-логика постоянно пересекается — автотесты гарантируют прохождение основных кейсов.
В моей команде никто не сопротивлялся. Но по опыту ребят из нашего внутреннего комьюнити, скажу, что для разработчика преимущества не всегда очевидны. Мотивировать его можно уменьшением итераций тестирования. Это действительно так (в моем случае — от нуля до двух итераций максимум). Мало кому нравится переключаться обратно на задачу для фикса.
Имею в виду основной бэклог. То, что взято в спринт — уже должно быть описано.
Сейчас у нас in progress означает разработку, написание автотестов и их прогон. Колонку in development не используем. In testing — это задачи, готовые к исследовательскому тестированию.
На самом деле, это скорее вопрос к процессам. Они могут сильно отличаться от наших. Главное, что вы не тестируете руками кейсы, которые полезно было бы заранее покрыть автотестами.
Основная работа происходит, когда задача еще лежит в бэклоге. При попадании на доску — это уже задача с описанными критериями, соответственно, переход в InProgress означает и разработку автотестов.
Если у вас есть колонка «Test», то можно перемещать туда задачи на исследовательское тестирование, либо совсем исключить колонку и пользоваться только «InProgress» — что как раз отражает радикальный Agile testing.
Насчет программного метода не совсем поняла — не пользовалась этим инструментом. Если я не ответила на ваш вопрос — опишите, пожалуйста, что именно вы бы хотели перенести программно.
Мне жаль, что ваш опыт работы заключается в таких проектах, как вы описали.
Если в команде нет требований к минимальному покрытию unit-тестами, и коммуникация развита так, что нет возможности донести необходимые для поддержания качества требования, то вам стоит начать с базовых процессов построения качества в команде. Удачи вам в этом!
Спасибо, что поделились опытом!
Полностью согласна про косвенные бонусы, у нас сильно выросло взаимопонимание при разборе задач, стали говорить на одном языке, если можно так выразиться. Масштабировать пока не пробовали, будем над этим работать. Удачи вам в ваших проектах)
Привет, спасибо за вопрос! Да, такой подход действительно требует большого количества времени. Проработка тестов в начале частично сократит конечную работу и, по моему опыту, уменьшит количество итераций тестирования т.к. большинство корнер-кейсов уже будет предусмотрено.
Но в общем и целом времени это займет больше, поэтому важно договориться с командой. Выгода по времени будет в перспективе — благодаря высокому покрытию автотестами, будет меньше трудозатрат на поддержку качества, но посчитать это довольно сложно.
«Shift left следует использовать в Agile и не нужно использовать в Waterfall потому, что это противоречит принципу последовательности процессов в Waterfall.»
В то же время, если говорить о другой практике, например, про пирамиду тестирования, то её вполне можно использовать и в waterfall подходе. Есть и другие, часть которых противоречит, часть подразумевает включение тестировщика в начальные этапы, например, «встреча 3-х амиго», а часть вполне можно использовать в отрыве от подхода, например, исследовательское тестирование.
Т.е. Некоторые практики, применяемые в Agile, которые мы хотели включить в свои процессы, противоречат последовательному построению этих процессов, и в целом у нас не было идеи удержаться в рамках какого-либо подхода.
Agile-подход это грубо говоря набор практик и ценностей, которые, конечно, можно применять еще где-либо, но по нашему опыту, вместе они работают вполне эффективно. И нет необходимости применять отдельно практику из этого подхода, когда можно перейти на методологию в целом. Но если вам так удобно, и вы хотите сохранить подход, прикрутив к нему другие практики, то мне было бы интересно узнать как это работает и почему именно так.
«Вы сами себе противоречите.
Подпись под картинкой: «Одна выделенная стрелочка — один поход — одна проверка в unit тесте»»
— На картинке обозначено взаимодействие сервиса, со стрелочкой лишь пример, как это можно применить. При желании, на ней можно добавить обозначения тестов разных уровней, но я этого не делала и такого смысла в неё не вкладывала.
«Это тоже очень сильное заявление, которое больше запутывает, чем дает понимания того, что вы делаете и зачем это надо.»
— Я действительно опускала датасеты из e2e-тестов на уровень юнит-тестов. Этот пункт в разделе статьи «как решали сложность в понимании unit-тестов», так мы повышали компетенцию в том, что можно опустить на этот уровень. На новую функциональность, когда кода еще нет, QA unit-тесты не пишет.
«Практика есть у вас, судя по статье(хотя я спрашивал про интеграцию, а не про юнит, ну да ладно)».
— Я не пишу интеграционные тесты на бэкэнд, поэтому и не приводила их в пример.
«В отрыве от контекста и без понимания как эффективно(а не тестировщик глазами) мапить юниты на, как минимум, интеграционные говорить о целесообразности такого подхода нельзя(если только мы не говорим о продукте где не предъявляются высокие требования к качеству).»
— Как маппить автотесты разного уровня — тема для отдельной статьи, моя статья на этот вопрос не отвечает, а рассказывает о процессах внедрения подхода agile-тестирования.
Хорошего дня!
На картинке нарисована не схема тестирования, а общее взаимодействие сервиса. Тесты на ней не обозначены. Мы нарисовали её для общего понимания, что нам нужно будет покрыть.
Unit-тесты выделены в статье, так как с пониманием остальных уровней тестов проблем не возникло. То есть мы выделили интеграционные, компонентные, e2e тесты, а вот с пониманием, что можно опустить на юниты, возникли трудности.
QA, не пишет unit-тесты, поскольку они зависят от структуры кода. Если у вас есть практика, где такое происходит, то мне было бы интересно узнать, как это работает.
Обязательная часть методологии — это практика движения тестов на более низкие уровни. Изначально у нас было много e2e тестов, потому мы их опускаем.
Знаю, что на теме уровней автотестов возникает много столкновений. Под юнит-тестом мы понимаем атомарную проверку внутренней работы сервиса :)
Сравнить с какими-то другими методологиями я не могу — их не использовала. Если напишите пример из методики, которая вас интересует, или применение таких же практик, в другом подходе, то смогу вам ответить точнее :)
Мы стараемся хранить тест-кейсы всех уровней в одном месте, чтобы видеть общую картину. При создании (ручном или автоматическом) мы указываем тип тесткейса — e2e/component/integration/unit, там же у нас видно покрытие. Пропорции пирамид смотрим уже в Grafana.
На данный момент столкнулись с тем, что некоторые unit тесты не содержат никакой бизнес-логики, и вопрос об их хранении в общем месте — спорный. Это уже на ваше усмотрение, зависит от цели хранения тесткейсов.
Некоторые другие TMS, насколько я знаю, тоже имеют поле «Тип тесткейса». Например, PractiTest, либо можно пользоваться любой другой удобной маркировкой.
Если захотите узнать чуть больше про нашу тестохранилку, то советую почитать статью моего коллеги Вадима Шашина What Does Our Test Case Management System Look Like?
Но против такого подхода не имею ничего против. Как минимум, если не писать автотесты, то ревьюить точно надо. Так ты уверен, что конкретно тест проверяет, а что он мокает.
Насчет код-ревью вопрос спорный. С одной стороны, тратится больше времени (тестировщик будет читать код медленнее, если не рассматривать вариант с senior developer’ом), с другой — повышение компетенции. Почти уверена, что если бы тестировщики участвовали в ревью кода — выхлоп в нахождении багов на этом уровне точно был бы. Остается оценить затраты на обучение тестировщика и применение этого навыка в будущем.
А если рассматривать такой вариант, то выгода компании тоже спорная, ведь senior developer в тестировании, как мне видится, будет элементарно дороже.
Это вопрос на «поразмышлять» и немного выходит за рамки темы. Кажется, что каждому своё :)
1. Постановка задачи.
2. PBR-встреча, или по-русски: встреча, на которой мы оцениваем задачи, обсуждаем их постановку, задаем друг другу вопросы, проговариваем риски.
3. Задача следует в бэклог.
Мне понятно, почему возникло непонимание. Действительно, не все осветила. Спасибо за этот вопрос. Дело в том, что мы решили, что ответственный за постановку задачи теперь тот, кто ее пишет, а не тестировщик. А уже на PBR встрече я (или другой член команды) можем внести коррективы. Это, скорее, про работу команды: можно это и не вводить, но с какого-то момента задача просто стала лучше описываться.
В моем случае внедрение подхода прошло спокойно — в соседней команде уже успешно его применяли, и мы это видели. Какой-то формальной процедуры согласования у нас нет. Только если на прохождение мастер-класса. У нас всё просто: если ты хорошо выполняешь свою работу и в срок — то делай её хоть с помощью бубна (немножко утрированно, но в целом подход такой).
Но, тем не менее, я считаю, что аргументировать преимущества — важно. В чем плюсы:
1. Увеличение скорости тестирования. Скорость будет увеличиваться за счет уменьшения итераций, поскольку очевидные кейсы будут покрыты автотестами, а крайние моменты будут обсуждены в момент описания задачи, и разработчик сможет их предусмотреть.
2. В перспективе, активное уменьшение регрессионного тестирования. Регресс автотестами в разы стабильнее и быстрее ручного — думаю, это очевидно.
3. Стабильный уровень качества. Он также будет зависеть от ваших автотестов, но если бизнес-логика постоянно пересекается — автотесты гарантируют прохождение основных кейсов.
В моей команде никто не сопротивлялся. Но по опыту ребят из нашего внутреннего комьюнити, скажу, что для разработчика преимущества не всегда очевидны. Мотивировать его можно уменьшением итераций тестирования. Это действительно так (в моем случае — от нуля до двух итераций максимум). Мало кому нравится переключаться обратно на задачу для фикса.
Сейчас у нас in progress означает разработку, написание автотестов и их прогон. Колонку in development не используем. In testing — это задачи, готовые к исследовательскому тестированию.
На самом деле, это скорее вопрос к процессам. Они могут сильно отличаться от наших. Главное, что вы не тестируете руками кейсы, которые полезно было бы заранее покрыть автотестами.
Основная работа происходит, когда задача еще лежит в бэклоге. При попадании на доску — это уже задача с описанными критериями, соответственно, переход в InProgress означает и разработку автотестов.
Если у вас есть колонка «Test», то можно перемещать туда задачи на исследовательское тестирование, либо совсем исключить колонку и пользоваться только «InProgress» — что как раз отражает радикальный Agile testing.
Насчет программного метода не совсем поняла — не пользовалась этим инструментом. Если я не ответила на ваш вопрос — опишите, пожалуйста, что именно вы бы хотели перенести программно.