0: 20 0 3. Ну что, начинаем? Контента много, надо успеть. Меня зовут Настя. У меня такая необычная фамилия гуен. Может быть, кто-то меня уже знает. Поэтому всем привет, кто меня знает и слушает мою лекцию. Собст.

1: Фамилия. Фамилия у меня необычная, очень удобная. Если погуглить, ввести в любой из поисковиков мою фамилию ген, то вы найдёте только меня и больше никого. Очень удобно и нужно.

2: Объяснять, как именно меня нужно найти. Собственно, я являюсь руководителем курса калит, в рамках которого сегодня и провожу сегодняшний открытый урок. Немножко расскажу про курс перед тем, как

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

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

5: Вот сегодняшняя лекция про стратегию тестирования является 1 из лекций, точнее не лекций. Сегодня у нас сегодня с вами открытый урок. Вот этот урок является как раз-таки некой интерпретацией.

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

7: Связанные с командой, то есть как создавать команду, как её формировать, развивать и так далее. То есть все про людей, про команду. Затем мы переходим к модулям, которые про понимание продукта, про его бизнесовое, техническое понимание.

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

9: Ей, то есть стратегия тестирования, автоматизация инфраструктуры и так далее. И данная лекция, она является стартовой в рамках как раз-таки модуля, в котором мы строим всю эту стратегию, разбираемся с автоматизацией тестирования. Подразумевает

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

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

12: Весь материал, который ранее был озвучен, пересказать не смогу, иначе мы с вами в тайминг не уложимся. Тайминг у нас с вами полтора часа по формату. Как будем взаимодействовать? Я буду давать какой-то модуль.

13: Ну, в районе, допустим, 15 минут максимум. Затем я буду делать перерыв и отвечать на все ваши вопросы. Поэтому вы в целом можете вопросы сразу писать, то есть давать мне обратную связь. У меня получается чат здесь рядом, на другом экране.

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

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

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

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

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

19: Anna, потому что это, в принципе название лекции. То есть нужно выяснить, что это такое. Я, я дам вам 2 инструмента, это квадраты тестирования, пирамида и пирамида тестирования, то есть

20: Эти инструменты являются базовыми для понимания, для планирования, тестирования и стратегии тестирования для каждого. Поэтому мы их разберём. Расскажу, как ими пользоваться. И в конце мы

21: Сколько хватит времени, разберём различные стратегии тестирования в зависимости от архитектуры, которая есть внутри компании. Говорю, в конце сколько останется времени, потому что все зависит от того, как много будет у вас вопросов, ну, на предыдущих этапах.

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

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

24: Там стратегию тестирования или же ко мне как к консультанту приходит и тоже задаёт вопрос там, вот, насть, помоги нам нанять, или, да, или руководителя тестирования, чтоб он там создал нам стратегию тестирования и

25: Люди все по разному интерпретируют данное слово. Ну то есть я когда даже в группу задаю вопрос, типа, что вы понимаете, под стратегией тестирования все очень разные варианты дают. И перед тем, как я вам расскажу, что это та,

26: Давайте как раз-таки попробуем пообщаться. Напишите, пожалуйста, в чат, что вы понимаете, под стратегией тестирования не нужно гуглить. Просто вот как вы понимаете данный термин, что такое стратегия?

27: Тестирование я подожду на на минутку.

28: Пока вы будете писать, немножко расскажу про свой опыт, чтобы вы понимали контекст. Я с 2012 года прошла все Роли, была и тестировщиком, автоматизатором. Дом, автоматизация руководителем.

29: И так далее. Собственно, мой самый большой опыт управления качеством был в тинькофф бизнес линии, семье, где у меня была команда больше 90 человек. Сейчас я работаю сама на себя являюсь

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

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

32: Хаус. И когда со стороны ok, вижу, уже появились ответы. Стратегия это долгосрочный план тестирования. Стратегия это способ сформировать процесс тестирования так, чтобы

33: Каждый участник этого процесса.

34: Понимал уровень качества своего продукта.

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

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

37: Будем использовать для достижения нужного качества продукта. Угу. В разном контексте разные стратегия тестирования для всего отдела. Цели, планы, этапы. Спускается тактических Шагов. Так, описание.

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

39: В принципе, в принципе, очень все по разному. Но, наверное, если все это вместе обобщить, то можно на выходе-таки получить определение в общении результатов анализа требований. Угу. Угу. Окей. Смотрите.

40: Здесь 1. Ну то есть я не буду сейчас прям явным образом выделять, какой правильный, какой неправильный, наверное, просто мне просто понравилась очень кратко фраза. То есть вот стратегия это нечто, что позволяет нам

41: Достигнуть нужного качества продукта. Я специально убрала серединку, оставила нечто. То есть потому что вот это вот нечто как раз-таки нам сейчас стоит определить, а из чего состоит стратегия. Наверное, можно сказать как раз-таки стратегия это способ

42: Достижение нужного качества продукта. И вот этот вот способ нужно расписать, расписать, презентовать, синхронизировать, чтобы все одинаково понимали, каким именно образом мы достигаем вот какого-то определённого качества продукта.

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

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

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

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

47: На какую дальность ориентируется компания и вы формулируете на вот эту вот цель, определённый путь, как именно вы будете этого пути? То есть здесь речь не про целеполагание, типа, вот как достичь этой цели? Нет здесь

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

49: Грубо говоря, применять там вы приняли решение передвигаться теперь только на автомобиле и не тратить ресурсы, допустим, на то, чтобы ходить пешком. Соответственно, ваша цель, может быть дойти из точки а в точку b1 из стратегических

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

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

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

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

54: К примеру, или, допустим, когда у нас доступность всех критичных функции всей критичной функциональности, там на 100% и нет ситуаций, когда у нас нет недоступности какой-то функциональности или когда

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

56: Протестировать её, зарелизить и при этом там пользователь, чтобы не заметил какой-то недоступности. То есть, как правило здесь стратегия, она очень сильно завязана на вашу it стратегию, то есть что внутри вашего бизнеса

57: Из чего состоит ваша it стратегия? То есть, к примеру, там, если у вас фокус на обсервабилити, соответственно, вы со своей, со стороны тестирования должны построить такую стратегию, которая также будет гарантировать эту вот наблюдаемость, то есть, чтобы было качество прозрачно наблюда,

58: Это на всех этапах если у вас, допустим, фокус на time to market, то, соответственно, ваша стратегия будет сфокусирована на то, чтобы способствовать ускорению ат маркета если ваша it сфокусирована на отказоустойчивость, то ваша стратегия

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

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

61: В смысле, не it стратегия, стратегия тестирования. Так, сейчас че то у меня очень, очень странное происходит с презентацией, а вот

62: То есть из чего состоит стратегия тестирования внутри стратегии? Мы должны описать продуктовые, проектные риски и инструменты работы с ними. Ну то есть, как правило, мы для этого используем систему качества.

63: Мы её изучаем, у нас на курсе, собственно, система качества дэвида Дервина. Если что, вы её можете погуглить, там она пятиуровневая, и по ней можно как раз-таки сформулировать 5 основных 5 основных уровней качес.

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

65: Техники, проанализировать наш продукт. Используем модель c4. С помощью этой модели можно как раз-таки понять зоны ответственности в айти инфраструктуре, за которые вы как колит, несёте ответственность, в рамках которых вам нужно выстроить

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

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

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

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

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

71: Используемая методология для фреймворка. У вас также может стратегия очень сильно поменяться. Вот, соответственно, когда вы изучили, какой именно продукт вы создаёте, какие

72: Проектные, продуктовые риски в нём есть с точки зрения бизнеса, какие они допустимы, недопустимы. К примеру, когда вы изучили продукт с точки зрения технологий, то есть изучили его архитектуру, технологический стек, ИНН.

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

74: Уже строить стратегию тестирования. То есть пункт номер 1 это некий реквизит. То есть типа азы, как есть сейчас, чтобы понимать в рамках вообще, чего мы работаем, в рамках каких вводных будет существовать.

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

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

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

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

79: Оптимально выстроить стратегию тестирования для автоматизации там, ну, наиболее подходящую для команды. То есть здесь с помощью неё мы определяем все Роли, которые вовлечены в процесс автоматизации. Какие виды тестирования мы используем? Ну,

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

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

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

83: Вот в рамках 5 пункта, когда вы уже понимаете, какие виды тестирования вам нужны, какой способ автоматизации вы будете использовать именно вот пирамида тестирования, когда вы

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

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

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

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

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

89: Стратегия тестирования должна содержать в себе все вот эти вот 6 пунктов. То есть если у вас чего-то нету, то скорее всего у вас может быть просто план тестирования на какую-то конкретную фичу или, допустим, конкретную систему, то есть

90: Разовая какая-то активность это вот кстати то, что очень часто путают со стратегией тестирования, то есть называют план стратегией, но это не так. План, он, грубо говоря, разовая активность, это сделали и забыли страте.

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

92: Здесь вопрос а есть ли какой-нибудь пример, что может поменяться в стратегии тестирования, если перешли из храма в combo?

93: Ну, смотрите, в компании есть такое понятие, как экспедит лайн. Вот это значит, что, ну, то есть, и плюс в компании есть такая практика, как ип.

94: То есть ограничения по количеству инпрогресс задач, как это может повлиять в скраме? Нет такого понятия экспед экспедит лайн в скраме, грубо говоря, вы работаете 1, то есть

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

96: Dili, допустим провели и вы понимаете над чем вы сегодня работаете? В канбане же может возникнуть ситуация, что, допустим, влетела задачка в expert line и для всех, кто, допустим, в рамках вот этого канбана работает, это будет обозначать для

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

98: Да, это согласовал, ну, продакт совместно с командой это согласовал. То есть, вы понимаете, что нет смысла там делать дальше свою работу. Если вы, допустим, это сейчас не сделаете, это 1 момент, 2 момент, который там в том числе влияет, это vip

99: Скрам это фактически вип лимит 1. Ну то есть вы строите процесс свой таким образом, чтобы не увеличивать количество одновременной работы. То есть 1 там задачу сделали, там 1 историю сделали, переключились друго.

100: В канбане, там, если вы определили, что у вас vip лимит, допустим, на тестирование 6, то тестировщик одновременно, может там, не знаю, 6 задач тестировать и переключаться между ними с точки зрения скрам, это будет уже считаться неправильно. То есть, по идее, с точки зрения

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

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

103: Кредиту, тестинг, тестинг, допустим, редиту, регресс, тестинг, регресс, тестинг и так далее. Вот, ска, команды, это, как правило, там, 3 com, 3 колонки, там, to do, in progress, да, ну, из разряда. То есть, если команда придерживается,

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

105: А метод смотреть, что он, допустим, предлагает, и смотреть, как это будет отличаться, если, допустим, команда со скрам переходит на него.

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

107: На весь отдел. Смотрите, может быть стратегия тестирования внутри компании, и она тогда нацелена на скорее. То есть там, скорее всего, будет привязка к it стратегии. Ну то есть, к примеру, возьмём большой банк какой

108: Нибудь нём, допустим, it подразделение 2000 человек у него есть внутри этого it подразделения, есть, там, не знаю, дирекция тестирования, внутри которой там 100, 200 человек, соответственно, там, внутри, допустим, it подраз.

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

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

111: Мы могли обрабатывать большее количество задач, ну, там, с точки зрения тестирования, но при этом не увеличивать штат. Так могут возникнуть разные идеи. К примеру, там в рамках сессии пришла идея, что

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

113: Инженера. Соответственно, здесь у нас рождается стратегия на всю компанию, что теперь везде, где есть бэк, это все тестируют сами разработчики, везде, где есть вэб, это все тестируют, автоматизируют сами тестировщики. Вот это уже будет часть стратегии от общей, то есть куда

114: Какой-то общий путь, куда будет идти вся компания, неважно какие команды, группы и так далее. Это решение принято на всю компанию, это часть стратегии. Вот, но при этом именно стратегия обеспечения качества продукта.

115: 3 какой-то, допустим, команды или, допустим, группы команд, может быть другой. Ну, то есть, допустим, в 1 команде принято решение, что, допустим, там качество должно быть, ну, там, про

116: Допустим, клиентский и мобильное приложение, и там приняли решение, что там оценка в апп стор или в google play не должна падать меньше чем 4 и 6, к примеру, вот это 1, допустим.

117: Метрических показателей качества, допустим, по этому продукту. Другой, допустим, продукт это внутренний продукт. И там, собственно, все равно на то, как будет реагировать внутренний пользователь, там скорее будет метрики, качества. Это, допустим,

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

119: В 1 будет там фокус на ux, на ui, потому что именно это влияет на оценки, на регресс. То есть там точно должны быть люди, которые вручную это будут тестировать, потому что отследить

120: Все, автотест гарантирует, что visual работает корректно, невозможно на стороне мобилки, а во 2 случае, где у нас внутреннее приложение, там может быть фокус будет на повсеместную автоматизацию и там ручного труда будет очень мало, то есть 2 совершенно

121: Стратегии тестирования, потому что это 2 совершенно разных набора критериев качества.

122: Так как вы считаете, что должно быть общего? А так это я уже прочитала.

123: Угу. Ну вот вопрос про общего стратегия тестирования компании, это я ответила. Так, нужно ли стратегию тестирования формировать по дестоп веб отдельно? Или это 1 направление на все продукты компании? Смотрите, дестоп и веб это платформы или

124: Система, как ещё иногда называют, это не продукт. Ну то есть, если у вас один и тот же продукт, там, грубо говоря, один и тот же стик холдер, но дестоп и веб это просто, грубо говоря, раз

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

126: В этом случае у вас 1 продукт, но 2 платформы, соответственно, стратегия тестирования будет 1. Вы должны будете продумать и как тестировать дестоп, и как тестировать веб часть. Что же касается ситуации, когда, допустим,

127: В дестоп это клиентская часть, то, что видит клиент, а, допустим, веб часть, там сидят операторы. Ну, к примеру, как это бывает часто с чатом. У тебя есть какая-то дестопа, часть там, не знаю, к примеру, чат, где ты чатишься. С другой стороны, там у тебя сидит оператор.

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

129: То есть в случае, если вы все равно в рамках 1 команды это создаёте, то, скорее всего, это будет как 1 продукт, и, соответственно, у вас будет 1 стратегия тестирования.

130: Так, а канбан, получается, описание работы с досками тоже можно отнести к стратегии? Да, да, конечно. То есть это даже не просто описание, это workflow, то есть каким образом у вас двигаются задачи, то есть с какого, с какого статуса?

131: Какой переходит там именно какие есть правила, какие бывают блокировки, какие там бывают сел и так далее.

132: Что делать, если компания сама не знает, какой конкретно из она использует, смешивая разные виды аджайла, как в этой ситуации выстроить стратегию тестирования, если нет чёткой опоры Ровно для этого вам нужно понимать.

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

134: Или, допустим, у вас это скрам, скрам банк появился, ну то есть случился, то есть, понимая вот эти вот причинно следственные связи, вы будете лучше понимать, какой процесс тестирования вам подойдёт. Это не значит, что вы такие под копирку, типа вот есть

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

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

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

138: Так, ну я вроде бы ответила, да, про смешивание разных видов. Здесь вам просто нужно понимать, как работает connect, допустим, скрам или что-то другое. Если вы приходите в компанию, вам говорят у нас safe, значит, будьте добры.

139: Сходите на сайт сейфа, прочитайте всю документацию по сейфу, чтобы понимать, про что вообще идёт речь и понимать, какие, допустим, правила или требования накладывает сейф перед тем, как выстраивать какой-то процесс, выстраивать стратегию.

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

141: Который в восьмидесятых годах, по моему, в восьмидесятых годах, по моему, 84 был, если я не путаю, сформулировал 14 принципов качества, ну или конкретно менеджмента, просто в списке этих принципов описаны.

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

143: Подход к обеспечению качества фактически должны лежать в основе вашего управления в основе построения вашей стратегии фактически чем отличается роль kid от обычного к инженера?

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

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

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

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

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

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

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

151: Ценность, ценность, продуктовую ценность, там ценность для компании, но при этом сокращать расходы. И вот здесь на слайде выписаны основные принципы, на которые нужно ориентироваться. Я сейчас проговорю там самые важные. То есть 1 это

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

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

154: Вы будете узнавать и видеть результат, тем быстрее вы сможете

155: Исправить его. Ну то есть потери, которые будут происходить, они уже будут, грубо говоря, не 2 месяца, не 2 недели, а, допустим, 1 день. То есть всего 1 день вы зря проработали, но зато быстро об этом узнали. И это не так критично для бизнеса. Вот.

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

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

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

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

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

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

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

163: Ну вот как бы вот этот принцип, он точно не про нас. Ну как бы мы как Лиды, мы должны всегда смотреть, искать то, что можно улучшить, оптимизировать. И для того, чтобы как раз-таки следовать этим принципам, есть 5 основных Шагов. 1, это

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

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

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

167: 5 основных Шагов. И, собственно, эти шаги, они позволяют нам фактически определить, что в рамках нашей стратегии тестирования нужно улучшать, ну то есть на чем нужно сфокусироваться.

168: 1 из заданий в рамках нашего курса является как раз-таки проектная работа, мы её делаем в конце курса, и в этой проектной работе у нас студенты как раз-таки делают анализ существующей системы именно по всем вот этим вот пунктам.

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

170: Это то, что вы должны, собственно, как Лиды делать на постоянной основе. Итак, давайте я здесь много про лин останавливаться не буду. Хочется успеть разобрать бережли, квадрат тестирования и пирамиды.

171: Тестирование, которое я вам анонсировала. Про, вы можете, в принципе, потом почитать в презентации, либо почитать в интернете, поискать информацию. В принципе, её достаточно много, она доступная. Ну и всегда нужно помнить важный момент.

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

173: Усилий максимального результата. Вот это, наверное, основное утп, которое выделяет вас как Лида относительно какого-то обычного инженера. Грубо говоря, если вы научитесь, это де,

174: То это благодаря этому вы можете позиционировать себя либо как там эксперта, либо у вас уже, получается, появились определённые знания, которые позволяют вам видеть вот эти вот

175: Как, в принципе, это 20% усилий, которые нужно сделать, чтобы получить 80% результата.

176: Итак, давайте пока отвечу на вопрос на курсе больше рассматривается клит команды или QR руководителя большого отдела, мы рассматриваем и то и то, ну то есть в начале курса мы делаем знакомство.

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

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

179: Там от 10, 15%. Это уже очень опытные ребята, то мы даём материал, то есть выстраиваем баланс таким образом, чтобы понятно было и новичкам, но интересно было и опытным. Вот

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

181: Как если начать там что-то делать, будут потери и нужно проанализировать проекты, чтобы определить эти места, например, когда дают в тестировании задачу, которая 100% не проверит силами выделенных ресурсов, желаемый бизнесом.

182: Срок лучше сосредоточиться на других областях. Ну, собственно, да, я про это и говорила, что вам нужно определять те самые 20% приложения усилий, чтобы дать, ну, достичь Ровно те результаты, которых хочет.

183: Сейчас.

184: Как вы считаете, и должен формировать детализированные план тестирования уровня или может делегировать это команды зависит от того, на каком уровне делегирования вы работаете. У делегирования есть 7 уровней. И если

185: Вы, допустим, пришли в команду, и у вас команда там стажёров, то для стажёров вам придётся сначала формировать низкоуровневые планы тестирования. То есть это 1 уровень делегирования, когда вы прям чётко объясняете задачу с детальным планом, что нужно сделать.

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

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

188: Говорить не нужно. И то есть смотрите сами, чтобы они сами учились определять, в какой момент им нужно, допустим, включиться и что-то сделать. Ну и то есть там есть прям определённых 7 Шагов, то есть тоже там 7 уровней делегирования легко гуглится. Можете почитать.

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

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

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

192: Окей, давайте пойдём дальше. Итак, я вам уже анонсировала такой инструмент для планирования тестирования, как квадрат тестирования. То есть вспоминаем, мы с вами изучили

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

194: Наилучшие действия нам нужно сделать, чтобы принести максимум результата. Что такое квадраты тестирования? Выглядят они следующим образом. Это у нас 4 квадрата матрицы по факту ку 1 ку 2 ку 3 ку 4.

195: Здесь у меня на слайдах описание по 2, по 3 4. Сейчас я окей, давайте сфокусируемся пока только на этом слайде я расскажу вообще, что значит.

196: Квадраты и как их читать, как использовать в работе.

197: Итак.

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

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

200: Давайте посмотрим с точки зрения горизонтали. Я сейчас хочу чуть чуть порисовать, вот так сделаю.

201: Допустим, мы смотрим на вот эту горизонталь, вот эти вот квадраты, это ку 1 ку 4, это технологические квадраты, они ориентированы на технологии, они фактически способствуют развитию про

202: Без вот этих вот квадратов продукту будет сложно иметь устойчивый фундамент. Фактически это те квадраты, которые влияют на архитектуру. Ну то есть 1 из

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

204: Понятно, где выстреливает технический долг. Он очень сильно, в том числе завязан на архитектуру. Соответственно, вот те тесты, которые у нас находятся в квадрате ку 1 ку 4, это тесты, которые способствуют эволюции архитектуры, они способствуют развитию технологического

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

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

207: Процессы о том, что, допустим, нужны ещё и тесты из квадрата ку 1 и q 4, потому что они способствуют развитию продукта, его устойчивому развитию, то есть способствуют скорости изменений скорости развития продукта.

208: Следующая горизонталь у нас, которая находится вверху, это квадраты ку 2 и q 3, что дают нам эти квадраты, они фактически, то есть, как вы видите, здесь у нас написано бизнес фейсинг, то есть это бизнес, ориентированные тесты.

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

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

211: Результатом. То есть, как правило, есть кто клиентская часть, на которую мы можем ориентироваться и с которой можем работать. Это 1, допустим, разрез на то, как можно классифицировать все виды Тестов. 2 разрез это

212: Вертикаль 1 вертикаль и 2 вертикаль если мы посмотрим на вертикали ку 1 и q 2, то это те тесты, которые, как правило, выполняются до сборки, то есть до наличия.

213: То готового конечного билда, который мы устанавливаем. Пример на продакшн. Вот. Чаще всего это все те тесты, которые можно автоматизировать, если смотреть на более современные так, технологии.

214: Здесь можно смело говорить, что здесь находятся те тесты, которые мы выполняем там чуть ли не до сборки то, что у нас находится в квадратах ку 3 и q 4 это уже те тесты, которые.

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

216: Соответственно, вообще, зачем всю эту информацию вам рассказывала? То есть, как понимаем мы эти квадраты, то есть для того, чтобы сбалансировать вот это вот качество продукта и запланировать необходимые виды тестирования у вас

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

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

219: AVKVADRATEU4 проверить, насколько ваша архитектура вообще закрывает ожидания клиентские, там, скорость работы, безопасность и так далее. Часто бывает, что мы

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

221: Об этом не знает и вообще не задумывается. А вот этого нет, потому что типа времени нету. Ну и вот здесь тогда и прям намечается этот вот серьёзный дисбаланс. То есть видно, что на что-то мы вложились, в что-то не вложились, ну то есть прям полного покры.

222: С точки зрения того, как мы обеспечиваем качество, его на самом деле нету. Вот, поэтому, когда вы планируете тестирование, вот рекомендую использовать вот эти вот квадраты, потому что они позволяют как раз-таки вам не проглядеть

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

224: Ну, то есть, ко 1 у нас юни, тесты, компонентные тесты, это как раз-таки те тесты, которые, как правило, выполняются разработчиками, выполняются до сборки какого-то билда. И, соответственно, это те тесты, которые напрямую вли,

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

226: Высокая, то есть, типа разработчик смотрит и не может дать оценку, потому что не знает, а где у него выстрелит. Вот, потому что тесты это в том числе ещё и документация. 2 квадрат выделен на слайде, это уже тесты.

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

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

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

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

231: А ux это пользовательский путь, что к примеру мы не заставляем пользователя делать лишние действия, которые мы можем сделать за него, к примеру, у вас есть все паспортные данные клиента и вы можете автоматически эти паспортные данные заполнять, но продакт об этом забыл сказать и

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

233: И в 4 квадрате у нас с вами уже, как правило, те виды Тестов, которые завязаны уже на готовый инкремент, и они также завязаны на нефункциональные виды качества, такие как

234: Тельность, нагрузочное тестирование, безопасность, к примеру, сесали. Ну, то есть, насколько у нас product можно использовать людям с ограниченными возможностями и так далее, там

235: Как видите, там тестирование, инсталляция, Миграция данных, соответственно, когда вы планируете какую-то стратегию,

236: То вы описываете все те виды, которые вам нужны в том или Ином квадрате.

237: Так, давайте посмотрю на вопросы.

238: У вас тут много получилось так?

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

240: Угу.

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

242: Сама модель не новая, она была придумана, по моему, в 2003 году. Гойко аджич эту модель немножко модернизировал. То есть вы, если там любите смотреть на источники, можете посмотреть ещё на модель ко аджич, у него немножко вот эти вот виды Тестов, которые здесь написаны в квадра,

243: Они отличаются. То есть он предлагает немножко другой взгляд. Ну там концепция модели та же самая, просто наполнение квадратов немножко разное. Вот так.

244: Трассировка требований. Можете чуть подробнее, стоит ли её включать в стратегию и когда, какие инструменты посоветуете? Ну, смотрите, что такое трассировка требований, трассировка требований как инструмент. Вам просто необходима, чтобы понять ваше тестовое покрытие.

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

246: Есть моя лекция про тестовое покрытие. Вы можете посмотреть эту лекцию, я там, ну там целая лекция на эту тему. Вот. И в рамках курса у нас также есть 1 из лекций, где мы определяем вообще способ построения тестовой модели, и там

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

248: Тестом функциональность, протестировать, компонентным тестом и так далее. И здесь важно отслеживать, какие требования вы тестируете, а какие не тестируете. И часто бывает такое, что тестировщик просто смо,

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

250: Берут их хлоп. Ну, там, не знаю, прочитали 1 историю, 1, 1 тест сделали, а эту историю можно там, не знаю, декомпозировать на 10 разных требований. Соответственно, получится 10 кейсов. Поэтому трассировка требований это точно обязательный инструмент, который колет должен использовать.

251: Своей работе. Вот, соответственно, с помощью этого инструмента вы сможете подсчитать тестовое покрытие и сможете более объективно давать оценку качеству существующей тестовой модели и работе своих тестировщиков. Это, наверное, ответ на этот вопрос.

252: Так, итак, пока оставлю выводы по квадратам, давайте тогда отвечу на вопросы, которые я вижу, что накопилось.

253: Давайте восстановим контекст. Был вопрос про делегирование. Как быть в курсе всех изменений продукта без подобного подробного погружения? Если разработка плотная, здесь отвечают мне знаком. Прошлый вопрос частично помогает. Если есть вариант того, что

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

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

256: Когда команда формирует бэклог спринта обозначает цели спринта, которые она должна сделать, и потом прийти, допустим, в команду, на, ну, на обзор спринта и посмотреть, что в итоге у команды получилось, если видите, что команда много чего

257: Не сделал. Можете прийти к команде на ретроспективу и посмотреть, не было ли там затыков в их проблемах, именно связанных из за тестирования, чтобы своевременно, допустим, включиться. Это если мы говорим про скрам, если говорить про канбан, то канбан он даёт не

258: Которое визибилити, то есть вы можете отслеживать, что происходит. И точно также можете делать там демонстрации результатов совместно с командой можете сделать ревью квестов или review тестовой модели, там по мере готовности, допустим,

259: Для того, чтобы была какая-то передача знаний 1 человека другому и так далее. Ну то есть здесь очень большой вопрос. На этот вопрос можно реально отвечать очень долго. Вот как бы вопрос подразумевает целую лекцию, которая у нас про

260: Взаимозаменяемость людьми и передача знаний. Так с какого размера команды стоит выращивать помощников? Новый слой Ледов между собой специалистами? В среднем команда это 5.

261: 7 человек. То есть при таком количестве, в принципе, можете справляться самостоятельно. При большем количестве, скорее всего, уже будете не справляться. То есть, к примеру, там 10 человек, это уже значит, что у вас хотя бы 1 помощник должен быть. Ну, в целом, я слы,

262: Такую точку зрения, что типа 4 человека. 1 криолит, ну, это, наверное, большая роскошь, с моей точки зрения. То есть, если процессы хорошо налажены, то можно 5, 7 человек, 1 криолит, как-то так. Угу. Спасибо за ответ. Там отвечаю на ваш

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

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

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

266: Можно иногда приходить на встречу командам ну к примеру у вас там 5 команд, очевидно, что внутри каждой команды вы не сможете находиться и здесь можно сделать такое упражнение, что, допустим на one two Ван, ну хотя это, наверное не самая лучшая идея на one two ва.

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

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

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

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

271: Так, дальше вопрос. Поддержу. Вопрос про делегирование. Быть в курсе всех изменений. Работа в команде единственным тестировщиком. Пока не понимаю, как может быть по другому команду тестировщиков планируем расширить. И тут ступор. А как?

272: Пустить, не знать, все так же, как продуктоно. Тоже надо знать все и понимать, что, как и где работает. Кажется, что надо тоже самое. Смотрите, когда вы пытаетесь все контролировать, вы не доверяете команде, когда вы не доверяете команде, вы не позво.

273: Ей развиваться. Основной скилл 1 из необходимых Скилов хорошего, да, это выращивать самоорганизованные, эффективные команды и эффективность команды. То есть её производительность, она в том числе, как раз-таки зависит от тог,

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

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

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

277: Без тебя или нет, потому что часто бывает, что человек уходит и процесс разваливается, потому что он на самом деле процесс построил. Ну то есть он не построил процесс, он сделал какую-то систему, которой он руководил. И как только он пропал, эта система перестала существовать по

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

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

280: Ну, как бы на ручном приводе далеко это все не уедет.

281: Так.

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

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

284: Передаёте, у людей появляется, ну там в английском есть слово кантабиле. То есть ответственность, они не могут от этого отказаться. И они понимают, что это, грубо говоря, принадлежит им и

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

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

287: Тебе предлагают более высокую зарплату.

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

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

290: Lida или там руководитель отдела тестирования. Здесь часто ребята такие говорят, типа, как это пойти и задать вопросы, чего они от меня ждут? Это страшно, но это очень действенно, когда вы приходите и задаёте вопрос, типа там продуктов.

291: Там по или со типа чего ты от меня хочешь? То есть какую работу я по твоему мнению должен выполнять или там что, как ты поймёшь, что я как клит хорошо справился со своей работой и вы можете очень сильно удивиться, когда вы услышите

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

293: Ровно для этого нужны формальные критерии качества не субъективные. Типа, кажется, что качественно, а какие-то объективные, которые будут однозначно всеми одинаково пониматься. И тогда вы можете прийти и сказать, мы стремимся вот к этому.

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

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

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

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

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

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

300: Он это делает, твоя задача научить этого человека, но не делать это за него.

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

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

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

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

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

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

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

308: На, допустим, изучение ранее написанного кода, на, допустим, отладку каких-то проблем, которые связаны с тем, что своевременно это не порешали на, допустим, поиск документации, потому что её своевременно не написали. И так

309: Далее. Так, можно ли выделять Лидов не в командах, а на целое направление, в которых 5 и больше тестеров? Да, да, обычно так это и происходит, что лид, он скорее видит какой-то продукт, а продукт, допустим, разрабатывает

310: Пятью командами, в каждой из команд есть, допустим, свой тестировщик, допустим, 1 тестирует платежи, другой знает там выписку, 3, допустим, главную страницу, 4, там, справку и так далее. А литом полностью следит за тем, как разрабатывается и обеспечивается.

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

312: Необходим, чтобы понять корень проблемы. Сейчас извиняюсь.

313: Период времени. Ну, за, я бы, я бы отталкивалась скорее от релизного цикла. Ну, то есть, если релизный цикл, там 2 недели, то я бы понаблюдала, грубо говоря, 2 спринта, ну, то есть 1 спринт.

314: Это может быть 1 операция, это может быть там случайность 2, это все-таки уже похоже на там тенденцию какую-то вот то есть 2, 3 спринта это точно повод. Ну то есть если вы видите деградацию и отсутствие какой-то ни

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

316: Что ты делаешь? Это не так, а именно через инструмент ретроспективы. Когда ты проводишь сессию, задаёшь вопрос таким образом, чтобы люди сами задумались о проблеме и попытались после этого пойти и что-то изменить. То есть не вы им сказали, а они сами это поняли и сами приняли решение это чинить.

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

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

319: Также может находиться пункт про людей, то есть текущий состав команды. И, допустим, у вас стратегия может быть вырасти, допустим, с 20 человек до 100 человек. То есть это может стать, допустим, ваша, ну, целью вашего, допустим, отдела тестирования, как вытекаю

320: Пункт всей вообще it стратегии. И в этом случае тогда у вас пойдёт, допустим, построение какой-нибудь системы наставничества, менторинга, построение процесса онбординга, выстраивание процесса.

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

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

323: Давать какое-то оценочное значение. В течение какого времени можете вывести нового человека? Ну, к примеру, там за 3 месяца вы можете гарантировать бизнесу, что выйдете в его команду человека или, допустим, за месяц.

324: Пирамиду успеем сегодня. Ага, да, да, мы сейчас давайте перейдём к пирамиде.

325: Так вот, этот вопрос про признаки команд. Давайте я тогда про него расскажу и давайте перейдём к пирамиде пирамида тестирования. Смотрите, мы как мы сейчас с вами сделаем. Я сейчас рассказываю про пирамиду, вы можете дальше набрасывать вопросы, потом я отвечаю на все вопросы, ну то есть мы как раз

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

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

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

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

330: Пирамида. И отсюда иногда у людей рвётся шаблон, когда ты им показываешь ромб и говоришь пирамида тестирования. Поэтому лучше использовать фигуры тестирования. Давайте дам небольшой исторический контекст фигуры тестирования.

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

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

333: Тех радар инженерной практики и так далее. В 2012 году его статью опубликовал, в собственном блоге, чуть более доработал, ну, чуть чуть её модернизировал. И, собственно, с тех пор это стало таким мейнстримом.

334: Важный нюанс, когда эту модель придумывали, это был, во первых, 2008, 2012 год. Во вторых, оба этих человека и малкон, и Мартин фаулер, бэкендеры, они не учитывали фронтенд, соответственно,

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

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

337: Как раз-таки скажу, то есть что такое пирамида пирамида, она объясняет нам, в каком соотношении мы должны использовать те или иные виды тестирования для обеспечения тестового покрытия. То есть мы должны фокусироваться на

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

339: Инструмент статистического анализа, то есть тесты которые достаточно дёшево пишутся они быстро дают обратную связь ну че там unit test доли секунды выполнится ты уже знаешь что у тебя проверилось требование или нет вот и соответственно таких Тестов.

340: Должно быть больше. Ну то есть вся эта пирамида, то есть вся вот эта фигура, это 100% вашего тестового покрытия, то есть 100% всех возможных кейсов, которые у вас должны быть фактически с помощью этой модели. Вы можете договориться, что, допустим, вот здесь у вас там 1 набор проверок осуществляет

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

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

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

344: Там 100% всех возможных кейсов, и мы за качество хотим, чтобы отвечала вся команда, к примеру, там разработчики, автотестеры и тестировщики. И мы распределяем, кто, какие виды Тестов у нас будет автоматизировать. Вот здесь у меня на

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

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

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

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

349: Применение, по моему, у меня про это тоже есть вебинар, я думаю, там как раз-таки в офисе можно будет посмотреть.

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

351: Мне рассказать про пирамиду нечего.

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

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

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

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

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

357: Шарит. Соответственно, если вы сейчас работаете в продукте, у вас, допустим, перекос в сторону тестирования, то там следующее место работы, там выберите, чтобы был перекос в сторону либо процессов, либо, допустим, в сторону техники, чтобы прокачать именно недостающие области.

358: Потому что высокооплачиваемые специалисты это, как правило, те специалисты, у которых вот именно в 3 этих областях, то есть менеджмент, процессы и техническая часть, она как бы, то есть вы попадаете в серединку вот этих вот пересечения этих 3 зон, ну и, соответственно,

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

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

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

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

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

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

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

366: На её деградацию. Что ещё может понадобиться? Здесь понадобятся практики. Она про типа блюдо или канарины релизов. Собственно, нужно смотреть в этом направлении. Это если говорить

367: Про, ну, то есть то, что обычно называют девопс практиками с точки зрения организации процесса тестирования. Здесь рекомендую присмотреться в сторону контрактной разработки, контрактного тестирования, потому что данный вид тестирования появи,

368: Скорее, как ответ на микросервисную разработку, то есть использовать and тестирование в контра микросервисной архитектуре скорее неправильно и нужно в микросервисной архитектуре нужно строить.

369: Вокруг контрактного тестирования.

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

371: Софта тестинг, у него, по моему, есть серия книг про аванс софта тестинг. По моему, 4 Тома на ореле. Они легко гуглятся.

372: Так, ну вроде бы все, на все вопросы ответила. Если нет вопросов, можно завершать тогда с вами у нас 21 34, я практически уложилась. Давайте расскажу тогда, что

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

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

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

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

377: У меня на этом для вас все. Если есть какие-то вопросы, можем ещё на них чуть чуть поотвечать.

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

379: И улучшать его. Ну то есть улучшение, оно ж не только в автоматизации тестирования, собственно, улучшение может заключаться и в том. Так я сейчас вам

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

381: Многие практики, которые вообще внедряются в работе рабо в процессе работы, да, они вообще могут быть не завязаны на автоматизацию тестирования.

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

383: Так, вижу. Здесь ещё 1 вопрос. Насколько хорошо полит должен знать автоматизацию, если он начал с ручного, вы не обязаны уметь писать код, но вы должны хотя бы понимать, как работает.

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

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

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

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

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

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

390: Все, вопрос.

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

392: Разговариваю здесь, а я разговариваю с живыми людьми. Для меня, как для преподавателя. Это самая лучшая обратная связь. Так вижу вопрос, будет ли на курсе запись уроков, если пропустила занятие. Конечно, будет. Мы понимаем, что все мы люди, и у всех у нас иногда бывает день рождения или

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

394: То прослушиваете все потом в записи. То есть мы также проводим зум, все это записывается, выкладывается. Вы можете посмотреть это в записи. Единственное просто, да, то есть здесь в этом случае вы теряете возможность поучаствовать в практике, потому что вся практика у нас завязана на interactive. То есть мы, как правило,

395: Работаем в зуме, в сессионных комнатах, в мира. Ну то есть это 2 основные инструменты зум и мира.

396: Так, полезен ли будет курс без доступа к метрикам, окупаемости продукта и связь с заказчиками? Да, довольно много заданий на эту тему. Да, будет полезен обычно. Мы просто, ну, задание, оно общее, на все такие вопросы.

397: В конце задания. Ну то есть в конце урока, перед разбором домашнего задания, мы комментируем, как выполнять это домашнее задание тем, у кого нет доступа к этой информации. Вот. Ну то есть здесь просто будут небольшие оговорки конкретно для вас.

398: Курс только для Ледов, плохо понимаю вопрос что значит только для Ледов?

399: Для, для руководителей тестирования, но точно не для директоров тестирования. Ну то есть директорам тестирования, скорее всего, будет здесь не очень интересно.

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

401: Даём столько материала, и мы, у нас получается динамичная глубина материала. То есть мы сначала на самой 1 лекции делаем, грубо говоря, некий срез, то есть смотрим на состав группы, и уже по этому составу каждый из преподавателей уже понимает,

402: На каком уровне детализации глубины материала давать вам уже контент?

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

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

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

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

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

408: Задача, что вам нужно построить стратегию обеспечения качества на свой продукт. И вы понимаете, что, допустим, 1 из критериев качеств у вас стоит этот, как его обеспечение, допустим, высоко

409: Пропускной способности, допустим, для там 10000 клиентов, а сейчас у вас там только 5000 клиентов, допустим, могут осуществлять транзакцию. В этом случае мы не будем рассказывать вам, как проводить нагрузочное тестирование. Для этого вам нужно будет пойти на курс по нагрузочному тестированию, но мы расскажем

410: Вам как спланировать эту работу, как там организовать коммуникацию, как настроить процесс? Потому что колит это не значит, что вы должны быть экспертом во всем. Ваша основная функция это понять, что нужно и скоорди.

411: И настроить, сделать так, чтобы это работало. Но если вам нужно, допустим, не знаю, юни тесты, это не значит, что вы их будете писать. Это значит, вам нужно пойти к какому-то разработчику, замотивировать его на написание юнит Тестов. Убедить, почему это там нужно и необходимо.

412: И сделать так, чтобы вы там качество, начало, там улучшаться по мере написания ни Тестов. Вот.

413: Хороший вопрос тут появился, если нет возможности сейчас общаться с холдерами, так как в декрете как выполнить домашнее задание?

414: Можно просто абстрактно сделать без проекта. Вы можете попытаться отрефлексировать опыт, который был ранее у вас, но, наверное, пользы вы получите значительно больше, если, если бы вы проект выполняли.

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

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

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

418: Задания, они подразумевают некоторую рефлексию реального опыта.

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

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

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

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

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