0: Всем привет, меня зовут Оля, я руководитель тестирования яндекс про. И сегодня я расскажу о тестировании

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

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

3: Отнесём в конец, то есть вы их пишите, и в конце я на них отвечу.

4: Итак, 1, с чего мы сегодня начнём, собственно, вообще с тестирования, с его определения, с того, чем тестирование занимается и зачем оно нужно.

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

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

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

8: Конечный пользователь не просто сделан так, как он задумывался, но он ещё и удобный.

9: По сути, основная вообще цель и задача тестирования. Если брать, так прям глобально это обеспечение качества. Что это означает? Это означает, что тестирование такая прослойка.

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

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

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

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

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

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

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

17: Исправить, чтобы продукт был лучше.

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

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

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

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

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

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

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

25: Пойдём дальше.

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

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

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

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

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

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

32: Можно сломать извне, то есть никак к данным пользователя я не подлезу.

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

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

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

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

37: Выполняет основные свои функции, но и он действительно удобный. Ну то есть для меня, как пример, у нас в команде есть так называемое тестирование в Полях. То есть мы сами выходим, как

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

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

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

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

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

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

44: Естественно, нельзя забывать о том, что существует такое такая вещь, как тестирование локализации, то есть проверяется не просто перевод, а проверяется ещё как меня.

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

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

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

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

49: Это на самом деле 1 из самых действенных методов, который использует вообще команда.

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

51: Вообще, такие виды, как мануальное и автоматизированное тестирование, виды тестирования, которые связаны с изменениями. Почему вообще их боятся? Потому что это самые, самые долгие виды тестирования в основном.

52: Используется вот 3 вида. Это так называемое смоук тестирование, это регрессы и повторное тестирование, чем они отличаются. Смоук тестирование это проверка, ну, так скажем, кор функционала, то есть того функционала.

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

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

55: Я не знаю, там, если у вас приложение, например, в котором, там, не знаю, 50 экранов, и там 100 500 разных возможностей между ними переходить, можете себе представить, сколько часов может занять полная прове.

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

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

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

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

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

61: И давайте посмотрим на такие 2 достаточно важных вида тестирования, которые применяются чаще всего. И вообще существуют. Это ручное и автоматизированное тестирование. Что же это такое?

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

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

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

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

66: Он начинает смотреть, и он вам может по ходу дела сразу же давать какую-то обратную связь, что, мол, здесь, там не работает, а вот здесь работает, там это плохо, это хорошо.

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

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

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

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

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

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

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

74: Опять же, тот минус, который исходил у нас из предыдущего слайда, это как раз вот эти вот все повторные тестирования, регрессы, смоуки, все, что занимает очень много времени у человека, это правда занимает

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

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

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

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

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

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

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

82: Распараллелить их на там нескольких устройствах и прогнать их там, не знаю, за 30 минут.

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

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

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

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

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

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

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

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

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

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

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

94: Выгодно как пример можно посмотреть на мой слайд. У меня здесь приведён такой маленький график. На самом деле этот график взят с работы моей команды когда-то давно. Я пришла в компанию. Очень давно тогда

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

96: Циклах. У нас там 3, 4 дня занимает вот этот вот регресс, а выпустить продукт без него нельзя, потому что ты не будешь уверен в том, что он выпущен качественно и что все хорошо, естественно, начинает

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

98: Product все, что там происходит.

99: Пришли к выводу, что как раз-таки пора внедрять автоматизацию, а что делать и можем посмотреть насколько star график падать. То есть в итоге мы дошли просто до того, что у нас 1 человек за буквально 4 часа руками проверяет какие-то основные

100: Сценарий, а все остальное делается с помощью автоматизации.

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

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

103: А что, на что точнее нужно обратить внимание, когда вы создаёте тот или иной продукт? Потому что если какие-то вещи забывать, естественно,

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

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

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

107: Пакеты заранее и то там в какой момент мы разрешаем повороты, в какой момент мы запрещаем повороты, как мы хотим, чтобы это работало

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

126: Тор или google play в самой выкладке нет ничего страшного, но.

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

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

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

130: Уходит вот на сторону этих сервисов.

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

132: Есть браузеры в телефонах + 100.

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

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

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

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

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

138: Локализацию, что все классно у вас там все работает в браузере. Можно просто там нажать и сказать, хочу перевести эту страничку. То есть здесь может как бы заранее об этом стоит думать. А не поедет ли у вас вся вёрстка? Не, ну

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

140: Именно менеджера.

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

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

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

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

145: Ошибки, но it мир принято называть это багами. Что же вообще это такое по сути своей баг это просто несоответствие программы. То есть там вы задумывали 1, а работает оно иначе или

146: Не знаю, там ошибка, там какой-то там знак препинания Пропущен, это тоже баг.

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

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

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

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

151: Компаниях редко когда применяют 2 этих определения, обычно все называют общим словом приоритет.

152: Что же это вообще такое? Приоритетность бага по сути, это то в какую очередь нужно забрать в работу там ту или иную вот эту вот ошибку, серьёзность же это уже какая-то конкретная атрибут.

153: То есть там специфичное название этого бага.

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

155: Что же такое вообще вот эта вот приоритетность, серьёзность багов, какие есть виды? Самый страшный вид, который вам может встретиться, это так называемая блокирующая ошибка, она представляет

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

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

158: Господи, какой-то экран авторизации. Я ввожу номер телефона, нажимаю далее и ничего не происходит. Ошибка, ошибка. Но если я, например, сверну приложение, разверну ещё раз,

159: Ввожу номер телефона, нажимаю вход, все работает.

160: Как бы ошибка действительно достаточно проблемная, но очень простой способ её обойти.

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

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

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

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

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

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

167: Страшно может быть. То есть все зависит от вашего продукта. А если это просто там что-то маленькое, пропущенное, где-то, что-то случилось такое вот совсем мелкое, незначительное, да, это ошибка, но её можно поправить как бы чуть позже.

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

169: Очень, очень долгое время мы к нему пришли и поняли, что это, по сути, оптимальное время для того, чтобы среагировать на какую-то ошибку и её решить, естественно, как бы

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

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

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

173: Вам нужно там, не знаю, попрыгать на 1 ноге, покрутиться вокруг оси, 50 раз перевернуть, там, не знаю, планшет и оп, она случилась, блокируют, да, реально ли это для воспроизведения там, у пользователей?

174: Ну, типа там 1% из 1000000. То есть здесь опять же нужно смотреть по метрикам, вылезает ли это. Нужно всегда оценивать то где это происходит. То есть, если это

175: Ошибка происходит только, например, на 1 каком-то устройстве или на 1 браузере. А критично ли это? То есть какой функционал это задевает, как оно воспроизводится? Насколько вообще это проблемно, если абсолютно везде, ну, скорее,

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

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

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

179: Когда вы раскатываете что-то важное, что вот впервые в жизни увидит свет, и вы понимаете, что у вас вдруг там что-то ломается, причём ломается достаточно критично возмо.

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

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

182: Починить спокойно и ещё раз попробовать его отдать.

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

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

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

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

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

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

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

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

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

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

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

194: Либо это будет очень быстро все зависеть будет только от вас.

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

196: У вас на продукте вообще нет багов. Звучит здорово. Прийти к этому, правда, очень тяжело. Особенно когда у вас продукт постоянно там прям меняется, меняется, меняется много нового функционала.

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

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

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

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

201: Потому что чем больше у вас будет ошибок в продукте, тем, естественно, он будет хуже. Есть золотое правило, что никакая новая фича не нужна, если продукт уже не работает, то есть его никак не

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

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

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

205: Продуктовые релизы и вся команда разработки и тестирования садится вот на фиксы вот этих вот багов. Классно. Они там за раз починили, не знаю, там 50, 100 ошибок их выпустили. Что происходит дальше у вас? Она там, не знаю.

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

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

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

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

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

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

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

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

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

215: В целом документация от менеджера это достаточно прям такое что-то объёмное, потому что по хорошему нужно в себе иметь все это и

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

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

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

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

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

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

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

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

224: У меня в команде есть такое негласное правило, что у нас не закрывается ни 1 фича. Пока тестировщик не написал свою документацию, она на самом деле достаточно маленькая. Это совсем краткое изло.

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

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

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

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

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

230: За 3, 5 минут понять, а что, собственно, здесь происходит? То есть пройдя вот по такой вот маленькой документации, можно сформировать там впечатление того, что вообще происходит в целом, объединять такую

231: Документацию, конечно же, можно все-таки самая идеальная документация это документация, которая написана руками менеджера, потому что только он понимает всю суть создания продукта, то есть

232: Все, что пишем мы для себя, это что-то такое там коротко, абстрактно, просто для того, чтобы нам быстро вспомнить, а что ж там было?

233: Но именно продуктовая документация донесёт до любого человека. Вот в подробностях, что происходит.

234: Из документации есть ещё 1 вид, который применяет тестирование. Оно называется тест кейс, тест кейс. Это такое как бы описание по шагам действий.

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

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

237: Запустить приложение действие, там приложение запустилось, показался такой-то экран, там следующее действие, не знаю, там нажать на кнопку вход, там результат, не знаю, там поднялась клавиатура.

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

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

240: Понял. Нужно самому попробовать что-то сделать, то вот легко по шагам проходится и все хорошо.

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

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

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

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

245: Собственно, происходит, когда вы выполняете там тот или иной сценарий.

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

247: Что тестирование это очень трудоёмкий процесс, и если правильно его не запланировать и не оценить ещё на этапе создания продукта, у вас может все

248: Съехать, когда тестировщик приходит на планирование. Основная его в этот вот прям момент функция. Это, во первых, определить, зачем нужен продукт, то есть послушать менеджера.

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

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

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

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

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

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

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

256: Обычно есть несколько вариантов оценок. Есть так называемые там первоначальные, есть основные. Необязательно, что они будут, может быть 1 какая-то общая. Главное понимать, что вообще туда входит тестиро.

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

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

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

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

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

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

263: Основную 1 проверку, то есть вот это проход по основному 1 функционалу. Поиск ошибок, заведение баг репортов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

287: Backend там, грубо говоря, разработчик мог понять 1, разработчик, который делал там, не знаю, мобилки или фронт другое. Они там по раздельности сделали, там, не знаю, web часть отдали, её проверили.

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

289: Продукт со всем, что есть.

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

291: Перечисляла. То есть к ним могут в любой момент прийти и попросить слушай, а помоги мне там воспроизвести что-то, а помоги мне там настроить а что у нас сегодня там по, там, не знаю, процентной раскатке, что с продуктом и cello?

292: Человек отвлекается на это, это его обязанность. И, естественно, у него какие-то там вещи смещаются. То есть к этому нужно, ну, относиться спокойно.

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

294: Знает, если вы это не добавили тоже в документацию, если это где-то публично не написано, никогда не докажете, что это было так. Об этом нужно помнить и не забывать.

295: К теме, там вот регрессов, сборок и всего остального, как только

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

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

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

299: В общую какую-то ветку ничего не сломалось.

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

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

302: Вот этой вот критичности, серьёзности этих ошибок, потому что вы будете смотреть на продукт там с точки зрения, например, бизнеса, но тестировщик всегда смотрит на продукт вообще именно с точки зрения

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

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

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

306: Очень советую подумать о, когда вы создаёте какой-то продукт, о том, сколько у вас будет людей в команде.

307: Тестирование может стать так называемым узким горлышком в продукте.

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

309: Приходится 2 разработчика. В целом можно жить, когда, например, 3 к 1 ещё тоже идёт, это уже чуть становится больше нагрузки, но нормально выживают, когда начинается больше. То есть, например, там 5 к 1, 6 к 1.

310: И выше все нагрузка. В этом смысле она просто циклится. Команда начинает тестирование моментально выгорать. Там ребята работают уже там, не знаю, не по 9 часов, а там по 14. И, собственно,

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

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

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

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

315: Была права аналитика, что это нужно там, хорошо ли вы это продумали, правильно ли это сделано и уже потом, как бы вот это все оценив, вы отдаёте это дальше в продакшн.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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