0: Всем привет. Меня зовут Лёша Наседин. Я занимаюсь тестированием в команде браузера. Сегодня я вам буду рассказывать немного про тестирование. Значит, план нашего занятия следующий. Сначала я расскажу некоторую. Вы

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

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

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

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

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

6: То, что, ну, своё изменение. И вместе с этим из команды ушёл 1, 1 из 3 тестировщиков. На самом деле он мог заболеть. Неважно, что с ним конкретно произошло. И за некоторое время до релиза прибежал менеджер с горящими глазами, который говорит о

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

8: Протестированный продукт. И после этого у части пользователей пропал их контент. В этой истории есть много факапов, 1 из которых это

9: Незнание разработчиком основных. Ну, то, что разработчика не посвятили в основные регламенты, не рассказали ему, что и как нужно делать. Есть, очевидно, проблема с тестовой документацией. Собственно, ушёл 1, 1 из 3 тестеров.

10: И что-то не проверили, недопроверили. Есть также проблема с процессом менеджер.

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

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

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

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

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

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

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

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

19: Минимизировать риски в этом месте. Для начала давайте поговорим о том, что такое тестирование. Тестирование формально это процедура проверки, сравнения, фактического результата и

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

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

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

23: 1, 2, 2 с половиной. Ну вот где-то 2 с половиной человека. Хорошо. Смотрите, у нас есть какое-то программное обеспечение, оно состоит из функций. Ну в смысле.

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

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

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

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

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

29: Проверялось юнит тестами, написав на это в 1000 раз больше Тестов. Ну, потому что у нас модулей много, они между собой как-то взаимодействуют, могут принимать большое количество состояний. И тут получается такая Комбина

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

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

32: Начинает падать тест, да, за ним тоже надо следить. Его тоже нужно вовремя приводить в порядок. Следующий уровень тестирования системное. Это когда мы проверяем приложение целиком.

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

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

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

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

37: Следующий вид тестирования. Предположим, у нас есть тоже приложение, оно к в него приходит, там 1000 пользователей. Сегодня, завтра приходит 5000 и так далее. Постепенно количество пользователей растёт и в некоторый момент приложение ломается.

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

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

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

41: Момент их пришло слишком много, приложение упало, и упало оно между стадиями синхронизации.

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

43: Нельзя восстановить или же оно, скажем так, легко приводится в работоспособность.

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

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

46: Товаров. Для для этого есть конфигурационное тестирование.

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

48: Чтобы купить товар, такие проблемы выявляются юзабилити тестированием.

49: Есть ещё 1 вид тестирования, который, значит, у нас все тоже приложение, им пользуются. Все прекрасно. Оно неделю работает, 2 недели работает, а потом падает, конечно же, не проблема.

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

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

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

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

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

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

56: Мы проходим довольно, ну, почти максимальный набор Тестов по фиче, чтобы понять, она вообще работает как надо или нет. Следующий вид тестирования регрессионная. Предположим, у нас вот та фича, которую мы тестировали на предыдущем шаге, она

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

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

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

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

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

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

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

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

65: Только юнит тесты, ну и то они, наверное, думают, что умеют.

66: Взяли тестировщиков, взяли ручные тест кейсы и сказали разработчикам, что вот эти кейсы надо автоматизировать на нашем фреймворке для юнит Тестов. Разработчики сказали, окей, сделаем. Ушли делать. Через некоторое время сделали у них

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

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

69: Нельзя автоматизировать строго по ручным кейсам ручные кейсы. Они пишутся ручниками для того, чтобы их проходить руками. Хороший пример автоматизации. Есть 2 хороших подхода. 1 подход это

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

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

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

73: Это не хотел выносить. Есть ещё такой вид. Исследовательское тестирование, оно очень специфичное, оно очень сильно завязано на уровень экспертизы ручного тестировщика. Оно не заменяет тестирование по тест кейсам. Почему?

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

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

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

77: То есть в кейсах все понятно. Можно условно написать ещё 1 кейс. Тут, ну, вероятно, экспертиза тестировщика пополнится от этого кейса, но мы начнём в нём сильно сомневаться. Вот.

78: Практиковать такой метод тестирования стоит.

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

80: Сам посмотрит глазами, что там сделали. Ну то есть работает ли то, то, что он так долго ввёл. Вот про виды тестирования. Все, я не стал рассказывать про всевозможные штуки для

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

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

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

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

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

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

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

88: Кого? Ну, то есть вот кто, скажем так, задействован вот в процессах, которые возникают в промежутке, или, ну, конечно, те, которые будут подсвечены, и начнём мы с 1 процесса тз.

89: Написано с 1 этапа тз написано, и вот что с ним делать дальше есть такое тестирование, про которое я не рассказал. Это тестирование требований, то, собственно, в чьей зоне ответственности вот вся эта деятельность, это

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

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

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

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

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

95: Кто из вас знает, что такое морда в контексте яндекса? Ага. Вам про это, наверное, рассказывали, нет.

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

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

98: Ну, короче, произвести вычитку тз. 2 важный вопрос. Это блокирует ли этот процесс следующую стадию производства? То есть, готовы ли вы потенциал, ну, приступить к следующей стадии, учитывая то, что

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

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

101: Нужно узнать у тестировщика, сколько времени на это потребуется. Это время нужно заложить в планирование, ну, собственно, производства фичи. И самый важный вопрос. Это в каком виде тестирование выдаёт результат? Тестирование может

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

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

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

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

106: Разработчика, который в лице архитектора, который рассказывает тестировщику, как работает функции. Ну что он там напридумывал в этой функциональности чуть больше технических деталей.

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

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

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

110: То есть, скажем так, ну, например, цель, да, протестировать 100% функционала, это, конечно, не очень хорошая цель, ну, потому что она потребует невероятного количества ресурсов, но, тем не менее, как пример.

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

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

113: И также определяем инструменты для тестирования. Ну тут, собственно, просто мы выбираем, скажем так.

114: Это будет, ну, не знаю, там какие-нибудь специальные тузы для тестирования. Апи, ещё что-нибудь. Ну, короче, просто это.

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

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

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

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

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

120: Для тестировщика это останется просто, ну, фича останется черным ящиком. И ещё 1 вопрос. Это кто согласовывает метрики и цели тестирования? Возможно, это сам менеджер, который ведёт фичу, возможно,

121: Это какой-нибудь, собственно, главный менеджер, да, там или менеджер продукта, который отвечает за продукт. Вот.

122: Да, ещё важный момент. Хотя ладно, потом скажу, давайте дальше.

123: Следующая стадия это разработка на этапе разработки тестировщики пишут тест кейсы и готовятся к приёмке.

124: В этом процессе участвуют в основном тестировщик и разработчик.

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

126: И верифицируем тестовый сценарий для юниттестов. Хорошо бы стараться строить процессы. Так, ну вот в командах, в которых вы дальше будете работать, чтобы тестирование принимало участие в валидации.

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

128: Это может сильно уменьшить затраты на тестирование.

129: Так, про слепые зоны.

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

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

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

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

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

135: Периодически отвечает, ну, периодически следит за тем, какие заводятся дефекты. Менеджер его пушит. И да, давайте про то, что делает тестирование тестировщики, определяя

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

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

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

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

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

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

142: То есть, ну, у вас есть таск на разработку фичи, в нём ничего, ни комментов от тестировщика. Че протестировано, чего сделано там, какие тесты написаны. И вот за этим тоже нужно следить про слепые зоны.

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

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

145: Или ваши тестировщики?

146: Следующий вопрос, как дефект попадает к разработчику, то есть, ну, понятно, что тестировщик заводит таск и дальше непонятно, типа, есть ли регламент, что разработчик должен от

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

148: Важный. Ещё 2 важных вопроса. Это кто определяет, едет ли фича и будет ли релиз вот про будет ли релиз? Скорее всего, в команде есть какой-то набор людей, который принимает такое решение, несмотря на наличие багов.

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

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

151: Тоже участвуют менеджеры, разработчики в лице админов. Я на самом деле админов тоже записал. Разработчики и тестировщики, которые проверяют то, что выкладка произошла успешно.

152: Что делают тестировщики, они проверяют на самом деле сам факт выкладки, то, что она случилась. То есть выложены артефакты, на самом деле, ну то есть вот собранные артефакты, да, на самом деле выложили и перепроверяют.

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

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

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

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

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

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

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

160: Анализ.

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

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

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

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

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

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

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

168: Ещё 1 вопрос, какие действия предпринимаются по результатам анализа? На самом деле можно провести очень поверхностный анализ и сказать, что, ну вот у нас не хватало тут 1 тест кейса и все, и на этом историю закончить и сказать, что все прекрасно.

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

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

171: Можем процесс, скажем так, анализа дефектов у нас есть, но он существует в том виде, что мы заводим просто тикеты на это, но не делаем их. Ну, потому что они в последнем приоритете, времени на них нет.

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

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

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

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

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

177: Review, это когда, собственно, ну, 1 разработчик пишет какую-то архитектуру, отдаёт какому-то очень, очень опытному разработчику, он после этого ревьюит её и подключает тестировщика, чтобы он со своей стороны посмотрел что-то сказа,

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

179: Вот у меня на самом деле последний слайд со статьями, которые я советовал бы прочитать, они вот первые 2, они не они про тестирование для людей, которые вне тестирования, чтобы вы понимали, что чуть

180: Лучше понимали, что делает тестирование. Они частично эти статьи пересекаются с докладом, ну, с лекцией, которую я сегодня рассказал. И есть ещё 1 ресурс про тестинг. Там можно более детально прочитать про тестирование, если вам будет очень

181: Интересно. Вот на этом у меня все. Спасибо за внимание.