[музыка] Всем привет Сегодня у нас новое собеседование на Junior qa с Павлом Так что не отвлекаемся и смотрим так Привет Представься пожалуйста расскажи как тебя зовут Какой у тебя опыт тестирования и что ты хочешь о себе узнать Привет меня [музыка] релевантного опыта у меня нет Я прошел курсы самостоятельно почти заканчиваю курсы которые приобрел недавно и хотел бы собеседоваться на инженеры посмотреть так скажем свой опыт Хорошо Ну тогда мы начнем с каких-то базовых вопросов и Расскажи пожалуйста что такое
00:00:01 - 00:01:52
тестирование по твоему тестирование Это проверка ожидаемого на основе хорошо а что такое качество Как ты думаешь качество это удовлетворение продукта пользователя либо заказчика в соответствии с его применением а где такие критерии качества могут содержаться критерии качества Ну допустим в требованиях они могут прописаны продукту спецификациях То есть как наш продукт должен работать эти все моменты древние спецификации в принципе письменная документация это одно и то же по сути может быть где-то еще мы можем брать
00:01:04 - 00:02:39
источники Как ты думаешь Ну вот такое бывает в реальной жизни что ты попал на проект и говоришь Дайте мне документацию есть норма Как мы можем узнать требования можно прописать для себя для проекта для создания документации мы можем посмотреть на продукты допустим со стороны конкурентов мы можем мозговым штурмом с командой обсудить какие у нас интересует вопрос по продукту То есть общение заказчика Ну если по прям вникать в теорию то есть там еще такой формат то есть фокус-групп то есть мы грубо говоря как в это тестирование
00:02:06 - 00:03:42
только на сбор требований то есть Так мы собираем с группы каким каким продуктом видит Какой продукт хотел бы получить это группа людей соответствие основываясь на их мнение в целом как бы что-то вроде маркетингового исследования так понимаю Да да прототип можем создать дизайн начальный принципе все верно Есть еще одно место где мы обычно можем брать Какие требования но также называется очень просто здравый смысл commance то есть мы действительно можем с кем-то обсуждать можем спрашивать у заказчика у
00:03:08 - 00:04:34
бизнес-аналитика и можем брать аналогию с других приложений похожих все правильно еще бывает здравый смысл то есть мы грубо говоря мы проверяем как приложение работает бах у нас оно вылетает вряд ли где-то в документации написано на каждой странице приложения что оно не должно вылетать тут да то есть ну мы понимаем что что-то происходит не то оно падает Хотя прямо не указан документации Что такое быть не должно и такого на самом деле очень много там где нету требований и с твоим с ростом твоего
00:03:51 - 00:04:53
опыта вот этот Common Sense он станет на самом деле настолько же важным как и документация если она существует Ты просто набьешь глаз руку и поймешь где нормальная хорошее качество где хромает хорошо какие ты можешь цель тестирования назвать Так ну первоначальная цель чтобы продукция ответила нашим требованиям спецификации продукту удовлетворял пользователя чтобы продукты удовлетворял заказчиков кто собственно и начал продукты Так ну в целом чтобы сохранить репутацию компании протестировав продукт тем самым ну качество
00:04:22 - 00:06:09
возможно причем каких-то заказчиков Ну вот прям очень глубоко заказчик Извне если у тебя какая-нибудь там соцсеть по хранению фоточек Ну какие заказчиков изменил репутацию ты правильно сказал репутационные риски мы можем поделить если прям углубиться Да у нас есть там денежные риски бывают Ну грубо говоря у нас банковское приложение в нем бак деньги считаются неправильно банк потерял деньги репутационные это сам факт наличия Бага может отвернуть пользователей от приложения например какой-то Время назад в Тинькофф банке
00:05:16 - 00:06:31
был бак с пересчетом между разными валютами и некоторые пользователи за эксплуатили эту ситуацию и просто намайнили себе денег какой-то промежуток времени Вот и банк понес репутационные риски потому что все поняли что банк дырявый на тот момент в том случае Окей хорошо Какие ты знаешь виды тестирования это ручная Автоматизированная она функционально это проверка основного функционала основной бизнес логики прописаны требования Ну возможно может быть еще функциональности если наш продукт заточена именно
00:05:56 - 00:07:36
представление функционально это тестирование тестирование инсталляции локализация интернационализация разобралась платформенная тестирование производительности тестирование отказа устойчивости Смотри чуть-чуть тормозим стрессовая нагрузочная это все в одном месте У нас есть тестирование производительности производительности да а в нем есть несколько видов и там есть проверка пиков хайпик тестинг есть нагрузочная когда мы то есть это все разные профили нагрузки поэтому тут аккуратно нагрузочное тестирование
00:06:57 - 00:08:26
лучше либо просто говорить про него что она есть либо прям вглубь Но если ты прям четко можешь рассказать все виды и так далее То что могут уточняющий вопрос спросить по поводу тестирования безопасности ты сказал что если наше приложение выполняет какие-то функции по безопасности Ну на самом деле тестирование безопасности это не только если наше приложение которое мы Тестируем что-то делает по безопасности это в принципе Любое приложение которое содержит себе какие-то платежные данные личные данные паспортные данные и так
00:07:54 - 00:08:58
далее То есть Это именно приложение в которых человек слишком много о себе сообщает информации и в такого рода приложениях желательно иметь возможность тестировать безопасность особенно если модули которые отвечают за безопасность это не модули которые мы берем так называемый сервис сторонние приложения сами с нуля пишут банки любят хорошо про тестирование локализации Расскажи что в рамках тестирования локализации мы проверяем в рамках тестирования локализации мы проверим допустим продукт который
00:08:26 - 00:09:43
создали на определенный локаль мы учитываем допустим юридический особенности этой локали то есть также мы смотрим перевод текста валюта то есть размер если это интернет магазин допустим одежды размерная сетка также там могут быть литры галлоны единицы измерения различные но в целом Я бы наверное тестировал основные вещи назвал я бы тестировал Наверное тогда ознакомился с определенным локалье и уже на основе их особенности уже выявил конкретные точки с которым я работал эти точки назвал Единственное что забыл на
00:09:08 - 00:10:41
самом деле очень важный самая вещь которая меняется еще формат да ты времени потому что Америка меняется местами день месяц и так далее поэтому тут Важно хорошо хорошо так инсталляция проверяется установка обновление удаление обновление через через версию откат на другую версию допустим А ну допустим удалил и заново установил то есть такие моменты все правильно отлично супер ты говоришь что есть ручной есть автоматизированное тестирование как ты понимаешь автоматизированное тестирование То есть
00:09:55 - 00:11:26
я думаю если нам нужно сократить время на какие-то рутинные задачи мы их можем за автоматизировать то есть чаще всего наверное это будет мог регрессия тестирование с разных модулей уже собралась и если нам обсудим про автоматизацию ты говоришь самые частые сценарий мы имеем в виду что Да вот и ты говоришь что лучше подходит смог и в регрессии хорошо спору нет Все отлично Все Каким образом создаются автотест Что делается чтобы они были то есть на основе тест-кейсов которые прописал допустим Ну допустим представим ситуацию что у нас
00:10:47 - 00:12:36
крупное дело у нас есть мануалы авто и вручную это стирающийся и передал эту документацию автоматизатору и автоматизатор каждый шаг уже начинает прописывать код соответственно Запускай его программа отрабатывает через браузер Либо это будет То есть это по сути говоря программа да то есть программа написана на каком-то языке программирования вот и она проверяет нашу исходную программу которую мы Тестируем есть у нас еще ящики разноцветные Да белый черный ящик белый ящик наверное разделяется по доступному коду
00:11:47 - 00:13:12
получается сами разработчики открывает свой код так это модуль на тестирование тестирование Black Box это тестирование статического характера То есть она включается тестирование документации тестирование также наверное макета прототипов каких-то [музыка] наверное покрывает больше основное требование тестирование наверное Ну как насколько я для себя вывел наверное 150 источников То есть это есть доступ допустим к базе данных Ты можешь проверить как база данных реагирует на наши действия хорошие Что такое
00:12:42 - 00:14:23
но я думаю что это методика тестирования когда допустим нет доступа у обычного пользователя но есть доступ у нас как у специалиста Ну не совсем ну хорошо Хорошо ты постарался рассказать смотри что надо выделить в ящиках в принципе да что между ними разница найти Первое это то что правильно Ты заметил что насколько мы имеем представление о системе внутри как она работает с технической точки зрения То есть если в Белом ящике мы знаем как работает код можем в нем разбираться мы с ним взаимодействуем мы
00:14:17 - 00:15:32
пишем Unit тесты черный ящик мы не знаем как работает код но мы знаем как работает бизнес логика Вот и второе помимо знания внутренняя часть системы Это что мы покрываем тестовым сценариями в первом случае в Белом ящике мы покрываем сам код то есть суть Юнит теста в том что они в отрыве от основной бизнес логике они просто проверяют функции кода маленькие кусочки А когда мы Тестируем черным ящиком Мы берем наши там юзер стори наше понимание того как должен пройти именно бизнес задачи должны пройти и покрываем тестами
00:14:55 - 00:16:14
уже бизнес требования они блоки кода вот два параметра основных ты еще сказал что черный ящик он больше подходит для статистического тестирования это не так черный ящик подходит для любого вида тестирования где мы покрываем бизнес логику статическое динамическая неважно и что касается серого ящика это действительно довольно мутная история в теории можно прочитать много историй много статей и какой-то из них ближе которая к душе легла принять почему часто пишут о том что это подходит для тестирования базы данных
00:15:33 - 00:16:45
тестирование API потому что вроде как это что-то посередине мы с одной стороны не знаем На самом деле как работает код backenda Ну не знаю То есть Да есть база данных Но вот как из нее что дергается мы сами не знаем но при этом Мы можем с ней как-то взаимодействовать например через графика User интерфейс для баз данных есть такие То есть Не обязательно писать запрос там Селект фромта то можем просто буквально как в Excel таблички поковыряться Но с другой стороны наша ковыряние в базе данных и проверка в то что мне что-то появилось
00:16:10 - 00:17:18
Оно идет несколько отдельно от бизнес логики потому что ну допустим изменения в базе данных могут касаться каких-то очень узких там моментов в системе и поэтому нельзя сказать что при тестировании баз данных мы проверяем именно бизнес-логику и так далее и мы как бы под капотом уже Мы ковыряем базу или Мы через постман отправляем запросы или там через другую систему на сервер и получаем ответ и так далее вот поэтому это можно отнести к серому ящику но на реальном собеседовании можно наткнуться на сложную философию А многие
00:16:44 - 00:17:57
собеседующие и не знают ничего про серый ящик и говорят только про белые чёрные и нормально всё проходит ящики обсудили хорошо есть у нас Цените смог и regression тестирование Вот и привлеклись даже начал что-то рассказывать да и просмотров немножко рассказал можешь рассказать про эти три вида Но это уровне тестирования на которых мы проверяем функциональность то есть наша система Письмо к тестирование это поверхностная проверка нашей основной бизнес логики то есть Цените тестирование это тестирование вглубь определенного
00:17:21 - 00:18:43
участка Ну или репрессия это тестирование добавление новые функциональности когда мы добавили новый функциональность проверка со старой проверяем те части приложения которые не изменились с нашим новым наблюдением но могли как-то на них нововведение в теории повлияет но не напрямую Вот ты в проекте работаешь и в программе которая тестируешь ввели новый функциональность кусочек добавили какой-то вид тестирования применишь в начале и какой применишь дальше Вот из этих трех В каком порядке Почему Ну сначала бы я проверил основной
00:18:07 - 00:19:36
основную работу функционала поверхностно как она работает потом бы я начал применять ценники то есть грубо говоря Копатель функциональность и применяя различные виды и затем я бы проверил старый функционал с добавлением этой новой фичи например ты не можешь сначала проверить регрессию на потом Цените Ну проверить что сначала старый функциональность а в конце проверишь но какая для тебя разница Нет новая функциональность она может повлечь на старый Вот и найдешь баги в Старой функциональности а потом в конце
00:19:05 - 00:20:33
возможно иного протестируешь Зачем нам Цените раньше регрессии проходить если мы как бы вроде и то это пройдем в итоге но так она как бы мне кажется отталкиваясь от теории то есть Так они называются уровни тестирования поэтому мы проходим все поэтапно А почему вот почему у нас такие вот Ну вот мы выделили вот эти Ну уровни тестирования там есть другие вещи которые так называются называем просто вот виды тестирования вот эти вот и вот у нас есть понятие задаст вопрос там своим коллегам на работе на новые они тебе могут сказать
00:19:49 - 00:21:02
что мы считаем что регрессию надо вначале делать есть такие вот и ты спросишь почему они говорят Да мы так читали вот кстати вот поэтому тут нужно понимать Да почему почему мы именно Вот так мы располагаем мы так располагаем обычно потому что шанс найти выше случае с Наука и цените при добавлении но функциональности а шанс найти бак в регрессии меньше потому что мы подразумеваем что в регрессе лежит те проверки которые непосредственно не затронуты новым функционалом а новый функционал он всегда несет в себя беду
00:20:29 - 00:21:53
Потому что его никто ни разу не проверял А в регрессии лежат тесты которые мы уже как правило хотя бы раз проверили они когда-то были тоже Цените тестами Ну в прошлом в прошлом цикле разработки и мы их уже там смотрели Ну или кто туда наш коллега и вот у нас новый функциональность и нам надо проверить именно ту сырую часть первую очередь и часто Если ты будешь работать например не в крупных продуктовых компаниях а допустим в аутсорс аутстафах которые на заказ разрабатывают на чей-то у тебя не будет
00:21:11 - 00:22:15
просто времени на регрессию просто не будет времени у вас будет очень быстро и спринты и твоя будет Главная задача Так свою работу организовать чтобы делать максимально много пользы с минимальным затратным времени и ты будешь просто даже на собеседовании ты можешь спрашивать такие компании там проекты снова с регрессией очень часто буду говорить У нас есть тесты которые регрессию мы уже целый год ни разу не проводили потому что у нас идет молд потом ценники потом конец принта потом новый спринт и так далее и от регрессии
00:21:43 - 00:22:45
мы можем отказаться Да может быть мы из-за этого пропустим какой-то баг но шанс что он там будет маленький А вот от смог отсадите нам желательно не отказываться потому что шанс там будет бак при добавлении новых функциональности больше вот причина Зачем нам вот это вот структуру нужно и не просто из теории Да это реальной работе поможет хорошо так слышал когда-нибудь про характеры там позитивные негативные характер тестов да то есть позитивной проверки у нас за точно на проверку должен работать наш продукт то есть
00:22:13 - 00:23:34
негативные проверки и система должна отработать верно ошибку предложить какой-то вариант отлично хорошо Окей и вот у нас есть то что часто называют уровнями тестирования иногда могут по-другому назвать кто нас есть несколько уровней по степени интегрированности элементов системы друг с другом по степени интеграции виды тестирование по степени интеграции или уровни тестирования называется вот ты уже один уровень называл в рамках белого ящика Да какой модульный модульный так дальше какие у нас идут
00:22:59 - 00:24:15
операционная системная приёмочная где-то есть теории где-то нет И давай повторим тогда модуль на это что модульная Это я не тесты покрывает разработчик сам свой код это отдельные участки интеграционные взаимодействие с этими модулями которые так системно это совокупность всех модулей в целом то есть как полностью работает наш проект наша программа Ну и приёмочная так если сформулировать свое мнение то есть системная но возможно с какими-то элементами добавления при сдаче продукты может быть элементом один это называется план
00:23:47 - 00:25:27
испытаний это по-русски если говорить А по-английски это ацетон с плен Вот то есть это просто ты с кейсы которые подписывают не только Ну там Ты для себя сделал для команды ну их заказчик показывают говорят вот план испытаний мы если проходим по нему вы принимаете нашу систему они говорят Да окей Правда в том что ты же сам подгоняешь план испытаний который ты же должен пройти Если пройдешь приложение с данного в редких случаях тебе сверху спускает этот план испытаний но чаще всего если заказчик не
00:24:44 - 00:25:41
технически то ты для него пишешь план потом говоришь Ну что как вот Согласно с этим они говорят да да не показываю нам это все мы верим все нормально Давай и по нему проходит сюда и система сдается частью или целиком хорошо знаешь ли ты что-то про техники то с дизайна как генерируется тестовые сценарии техники то здесь нам нужны для упрощения так скажем тестовых формирование тестовой документации минимизируя доске чек-листы но при этом не чтобы мы проверили то есть полностью основной продукт с минимальным набором
00:25:13 - 00:26:55
документации лучше так говорить что мы уменьшаем количество сценариев тестирования не снижая качество тестирования самое лучшее на самом деле разные техники для разного нужны Но вот допустим те техники про которых все спрашивают на собеседование Да это эквивалентное разбиение они вот тупо нужны для того чтобы ты поменьше тестов написал не причем не упустив какие-то моменты Вот соответственно техникой эквивалентом разбиение мы разбиваем на классы и значение в этом классе должны одинаково отработаны быть как в системе
00:26:08 - 00:27:36
какие-то классы могут быть в реальной жизни Ну класс допустим языка там кириллицы латиница класс спец символов класс цифр набор прекрасно хорошо техника анализа граничных значений Как работает в паре с эквивалентом избиением То есть это мы допустим на примере если у нас есть поле ввода и у нас определенная от нижней границы до Верхней границы допустим границу и выходы за границу плюс минус проверить середине Сколько получается у нас тестовых сценариев если мы допустим Тестируем интервал от 10 до 100
00:27:00 - 00:28:37
тоже так а Можем ли мы тестировать интервал допустим не числовой Да там а интервалы алфавитный вот нужно нам вывести допустим значение по алфавиту и проверить что значение одной там до другой буквы работают то же самое интервал Да только не между чисел а между буквами в алфавита такое может быть Ну да может быть то есть мы допустим проверим там первая буква алфавита и последнюю в целом мы сократим 33 проверки Ну да наверное можно так Ну принципе да все правильно потому что компьютерные системы они
00:28:01 - 00:29:23
знают порядок алфавитов используемых и работает с ним также как числовым рядом хорошо отлично давай поговорим про тестовую документацию мы создаем в процессе работы как правило Какие виды набор мы должны проверить продукт то есть состоит из наверное есть стандарт плана можно его написать то есть стандартом 829 какие части Он включает то есть ну что мы Тестируем как мы это будем тестировать то есть применение туров то есть сколько нам потребуется времени на это кто будет тестировать Ну и критерии выхода
00:28:48 - 00:30:37
и входа так Какие может назвать критерии допустим входа что требование мы проверили требование и они удовлетворяют согласна теме критериями это сложно Сложно мы проверили критерием обычно будет являться допустим наличие требований вот так вот что они в принципе есть мы можем начать тестирование Когда мы уже будем сами требования читать и проверять это уже будет просто статическое тестирование это то чем ты будешь заниматься каждый спринт приходит задача Ребята давайте вот такую-то перделку добавим Вот на нее
00:30:06 - 00:31:16
документация разработчики в бой тестировщики пока вам нечего тестировать потому что разработчики только начали читайте документацию это уже процесс тестирования пошел а вот критерием начала может быть и стильный как раз таки то что тебе дают документацию в принципе Какие еще могут Кроме того что документацию дали то что у нас подготовлен тестовая среда Возможно да там допустим у нас мобильное тестирование нам забыли дать телефоны допустим на эмуляторах нельзя окончания тестирования когда наш допустим тест кейсы чек-листы
00:30:51 - 00:32:14
покрыли основной функционал То есть три выхода то есть еще может быть то что [музыка] минимальное количество там багов в приложении не минимально какой-то определенный соотношение например набор например мы можем указать там или нам могут сверху выставить что допустим не должно быть критиков багов вообще не должно быть менеджер багов допустимая на баги могут быть или не должно быть багов абсолютно никаких вообще 0 и тогда мы можем такое зачем они нужны это набор проверка для нашего функционала чек-лист это
00:31:40 - 00:33:12
подробная проверка в систему от эскиз это уже подробное описание проверки состоящие из различных допустим ID номер требований Давай лучше начнем тест Вот таких полей без которых мы не можем мы можем как-то без зайти и без номера А вот что нам важно иметь результат название проверки ожидаем результаты название проверки в принципе сама основное Да может еще статус быть автор номера вот все правильно По поводу чек-листа Ну ты как не очень хороший пример привел проверки чековщик листе который стоит из чеков каждая
00:32:35 - 00:34:11
предложение это проверка это правильно и стык как правило человек вот из одной предложения но это не просто приложение проверить там все-таки мы стараемся в вот этом предложении как раз таки по возможности расписать суть проверки и место проверки просто это Все выглядит очень сжато например пользователь может зарегистрироваться свалидными значениями пользователь не может зарегистрироваться с не валидными значениями вот один чек второй чек но тем не менее это приложение оно как правило достаточно длинное чтобы если с
00:33:34 - 00:34:37
проверкой более-менее сложная Но кроме этого предложения действительно ничего нету Хорошо Как ты думаешь Зачем нам два вида документации для одного и того же для того чтобы загугментировать проверку то есть какой мы бы приняли в каком случае Ну да в принципе Зачем Мы не пользуемся только чек-листами или только тест кейсами допустим чек-листы актуальны для компании которые стартапы какие-то на несколько месяцев некоторые компании через три-четыре года называется стартапами стартап это такое размазанное слово есть
00:34:06 - 00:35:35
критерии Да по которым мы выберем чек-листы Или ты с кейса одно либо другое первое Как мы можем выделить это Ну ты наверное об этом начал Да это наверное предполагаемый срок разработки мы подразумеваем что это разработка на пару месяцев идти это там первая версия нам наверное нет смысла запариваться документацией потому что стартап не взлетит да если это компания которая там себе называет не называет стартапом неважно но мы знаем что у нее уже длинные цикл разработки срок разработки планируется
00:34:56 - 00:36:02
надолго там на год на там еще что-то то наверное есть больше смысла писать сразу ну или с этого момента тест кейсы потому что ну история будет длинная и нам желательно иметь подробную хорошую документацию Какие еще как ты думаешь критерии повлияет на выбор допустим если я один тестировщик то есть я могу писать для себя Понятно Если никого больше не будет команд тестирования я могу для себя писать А если у нас команда большая и проект у нас как ты говорил длинный мы и он перспективе будет развиваться мы будем
00:35:31 - 00:36:45
писать также мы будем писать когда у нас предполагается расширение команды чтобы вводить в курс дела новых пришедших специалистов Ну вот первый критерий срок Значит у нас проектов второй критерий это размер команды тестирования Да там или Будет ли кто-то в принципе читать наши тесты проверки и Можно с вами выделить третий критерий это время которое у нас есть на проекте проект может быть большой в нем может быть очень много людей но там все равно будет все висеть на чек-листах потому что структура разработки будет
00:36:12 - 00:37:25
такова что И что просто не будет времени писать длинные эскиз и получится что либо ты пишешь только То есть это не успеваешь тестировать либо ты быстро накидываешь себе эти чек-листы и тестируешь по ним соответственно выбираешь что лучше писать что-то чем ничего не протестировать потом Окей хорошо дальше у нас репорт что это такое задокументированная дефект приложении на котором можно их взять так потом ожидаемый фактически результаты на кого назначен бы ну и прикрепляем там фото видео блоги Отлично Отлично называют приложение
00:36:51 - 00:38:33
Хорошо хорошо супер есть у нас еще там бывает приоритет Да помимо все что указал вот если тебе не повезло там будет еще отдельно северите отдельно приварите вот это вот мозгодробительная часть но чаще всего в жире допустим будет только приоритет который себя будет подразумевать сразу все то есть и в принципе с этим не будет проблем никаких вот Как ты думаешь кто устанавливает вот приоритет Бога То есть как мы выбираем правильно приоритет допустим приоритет это вообще Насколько быстро нужно починить проблему
00:38:06 - 00:39:33
То есть как выставлять отталкиваясь серьезность если это будет невозможность оплаты то есть это будет приоритет а допустим если это какой-то тривиальный баг то есть ошибка в тексте это будет минимальным минимально Представь себе приходит заказчик Газпром там какой-нибудь вот разработчик что-то там пилил и он даже не знал как бы заказчик называться и там вместо название реально заказчика написал там какой-нибудь хрен банк вот это все впрок попала туда все И ты такой видишь И в шоке система сильно от этого страдать Нет
00:38:52 - 00:40:23
никто не страдает Ну там написано хрен банк вместо заказчика высокий приоритет будет или низкий высокий конечно высоким Ну а ты говоришь что типа серьезности значит на то насколько сильно опектит систему так слова одно слово другое слово насилием с тем-то не эффект система работает деньги проходят Вот только вот заголовок кривой Да тут лучшим ответом будет являться тот зависимость от того что ты тестируешь в зависимости от стадии на проекта мы определяем Какой должен быть приоритет например на ранних стадиях развития
00:39:45 - 00:40:57
проекта у нас как правило приоритет высокий только для технических всяких задач а допустим опечатки неправильный какой-то дизайн это низкий приоритет но по мере приближение к релизу часто приоритет Вот вы печатках и так далее увеличивается потому что увеличивается шанс что скоро это попадёт к реальным пользователям или хотя бы к заказчику но В некоторых случаях как вот я сейчас сказал иногда имиджевые баги лучше сразу поднимать высоким приоритет например неправильное название заказчик или ещё что-то что может обидеться и всё пойдёт
00:40:20 - 00:41:30
не так как хотелось бы вот поэтому при выборе приоритета тут надо оценивать ситуацию вокруг да какая у тебя и чтобы разрабатываете разрабатываете вы допустим чат Ну соответственно баги которые относятся к функциональности чат они важнее чем баги которые будут относиться к разделу настройки хорошо жизнь цикл баг-репорта Давай обсудим Вот ты завел багрин порт что с ним происходит назначен то есть на разработчика он получается фиксит его отправляет обратно То есть я проверяю если все окей его закрываю если нет
00:40:56 - 00:42:23
хорошо отлично это вот в идеальном случае так и происходит правильно если разработчик Вот ты отправил разработчик опять починил Куда дальше разработчик починил тебе попадает переоткрытый что ну посмотреть Да там этот сделал да то есть проверить что [музыка] проверяешь он опять воспроизводится что дальше так но я переоткрываю переоткрываю на разработчика опять с теми же условиями которые были прописаны Back Report и без комментарием Да может быть что-то добавишь допустим это что-то выяснить дополнительно такое бывает Ну вот смотри
00:41:52 - 00:43:14
вот у вас и цикл происходит он чинит ты проверяешь он чинит ты проверяешь в какой-то момент разработчику стою говорит у меня Бога нет я занят я не буду я проверю совместимость может быть окружение Может быть я какой-то у меня косяк был смотрю опять еще раз документацию так ли оно должно все быть в таком случае документация у нас значит прописано четко вы с разработчиком выяснили что вы правильно понимаете окружение вы ну по возможности сделали схожие что еще бывает не так Ну возможно Так может быть он не обновил
00:42:42 - 00:44:15
код ветки То есть я посмотрю последнюю может быть время изменения какое было все правильно то есть Может быть он вообще изменения забыл залить такой бывает он же все локально собирает приложение тогда ли он себя починил и довольные побежал баг репорт отдавать тебе а забыл кнопочку нажать чтобы залилось дальше а Бывает такое что он залил Но ваш контент integration система которая собирает это все вместе виде приложения с определенным номером версии с номером билда выдает Она еще не сработало сработает через час или завтра
00:43:31 - 00:44:36
утром Вот и просто вы тестируете опять же на разных версиях вот допустим и это вы проверили и все нормальные версия кода правильная Что дальше делать но исключив все возможные наверное моменты я обращусь к руководителю непосредственно к Лиду либо приоритет Но это серьезности как она влияет на систему и в целом поставлю может какой-то комментарий Правильно Да Все правильно потому что проблема многих начинающих тестировщиков это что они слишком сильно топят за свои баг-репорты просто до драки твоя задача
00:44:04 - 00:45:22
проинформировать всех кого можно кого надо ли Да если если Но самое главное Project менеджера потому что project-менеджер в итоге может пнуть разработчика и заставить его все-таки починить бак там если он тоже уверен что он воспроизводит или сказать тебе он скажет Ну сделаю что-нибудь с багом там убери его в быклок или Закрой это типа не так важно сейчас не отвлекаю нашего Васю Вася на нём держится вся мощь нашего проекта он короче занят действительно вот а мы предоставляем информацию говорим вот такая ситуация
00:44:56 - 00:45:55
Давай товарищи прожить менеджер разрулились за нас Я драться с разработчиком не буду за этот бак есть Вот соответственно так эти вопросы решаются хорошо что может если мы вернемся Да к жизненному циклуба-репорта что может ещё с багом происходить после того как ты его завел если разработчик сразу плачу что-то неладное и решил ничего не чинить со старта что он может [музыка] ссылку дубликат дубликат случае дубликата что происходит Так ну то есть получается я смотрю если в каком статусе предыдущий баг То есть
00:45:26 - 00:46:57
это дубликат если он открыт Я возможно там приложу свой второй бак что это проблема Актуально до сих пор но если он закрыт я переоткрываю свой и линкую ссылку старого проблем когда-то была она возникла снова хорошо Какие еще бывают случаи кроме дубликата когда разработчик сразу ничего не захотел что он не хочет я вот не буду потому что дубликат или Бэм что-то еще что-то еще бывает может быть это новый функциональность то есть добавлены в требование я но открыл бак там на старые требования правильно да то есть часто ноты бак
00:46:12 - 00:47:47
пишет ноты бак есть статус типа ты писал когда тесту документацию допустим по старым требованиям потом втихаря поменяли тебе этом не сказали или ты сам случайно упустил и функционально теперь по-новому работают и теперь-то она работает правильно просто документацию устарела Вот и надо бы тесту документацию исправить еще что может быть кроме ноты бак бывает еще статус не будут делать когда в обычно ставят его обычно ставят когда [музыка] разработчик согласен что там есть бак Что может быть Его надо было починить но
00:47:17 - 00:48:25
он например в курсе что либо эту часть приложения полностью выпилит всю либо полностью перепишут он скажет да я согласен Вот в настройках косяк но мы выпиливаем настройки в этом или в следующем спринте типа зачем его чинить раздел не будет лучше также обращается Иван Иванович точно да правда сказал или написал все выпиливается закрываем что типа бак есть оставляем до тех пор пока функциональность Не выпилиться ну у нас ситуация остается Вот а еще бывает статус к на три продюсер то есть эта ситуация мы с тобой
00:47:58 - 00:49:25
обсудили ситуацию Когда вы допустим бак завели пару раз друг другу кинули и потом разработчик сказал что у меня не воспроизводится а может быть такое что сразу и разврат сразу тебе говорит а мне не воспроизводится нормально и тут принципе меняется то о чем ты рассказывал проверяем что мы на эту версии что у нас значит понимание ситуации такое же и у нас схожее окружение максимальное не всегда идентичные компьютерные и если это все нет тогда ты тоже либо расишь к своему говоришь нет либо убеждаешься что ты действительно
00:48:42 - 00:49:55
перестарался это действительно бака такого нет этого Случайность была какая-то хорошо говорим про разные виды приложений какие-то в принципе знаешь три группы приложений на которые сейчас мы можем поделить то что создается [музыка] приложение в приложении работает по клиент сервере текстуре клиент отправляет запрос на сервер сервер обрабатывает запрос если нужно обращаться к базе данных что это вытащить значение Ну и отправляет обратно на клиент и соответственно клиент отрисовывает наш запрос А вот то что все назвал ездил запрос
00:49:18 - 00:51:04
ответ взаимодействие то чем все регулируется так скажем То есть это сертификат безопасности что он делает а ну шифрует данные трафик то есть в https формате можно перехватить трафик но нельзя прочитать о содержимое То есть можно удостовериться что-то куда-то летит но прочитать нельзя ваш степи можно и можно не только прочитать Но и вмешаться в него изменить и не знаю было время когда можно было в Макдональдсе сесть с ноутбуком ВКонтакте работал на http и ты мог подключиться в сессию другого человека который тоже сидит с
00:50:23 - 00:51:45
тобой в Макдональдсе в том же wi-fi от его имени там написать его друзьям какими гадости смешное время было до того как ввели сертификаты безопасности это перестало быть возможно хорошо запрос у нас обычно на сервере какими атрибут из чего он состоит если нужно тело запрос какие-то бывают еще метод или тип запроса get-пост под Delete Patch это основные такие про которым хорошо за достаточно ответ что все содержат обычно ответ содержит от тело запросы хайдера также Какие статус коды было 100 200
00:51:25 - 00:52:57
400 500 информационные 200 это успешные 300 перенаправление 400 ошибки на стороне клиента у нас какой-нибудь тело передается если мы ответ получаем 400 или 500 Нет не передается в теле ответы то есть там Джейсон текст формата адрес он либо xml какой архитектурный стиль этот самый HTML делами то есть нам передается веб-страница в виде кода а браузер нам ее читает и отрисовывает в котором мы видим вот хорошо Как ты думаешь Вот что нам важно тестировать если у нас веб-приложение то есть ты приходишь Да там на
00:52:34 - 00:54:27
собеседование тебе говорят у нас сайт как бы ты протестировал его вот может быть какие бы виды тестирования ты применил бы в первую очередь на что ты обратил внимание [музыка] а как разные платформы влияют на веб-приложения то есть допустим как у нас это приложение будет отрисовываться в телефоне то есть мы можем посмотреть браузера зависит как-нибудь отрисовывать нет а то есть да у нас же браузер один будет То есть можно за уши притащить кроссплатформы в том виде что на разных телефонов разный размер экрана Но вот
00:53:50 - 00:55:12
это только и вот максимум То есть это верстка проверяется но как бы более правильно ответ что от платформы в это не зависит он зависит от реализации браузера от типа браузера Вот от этого в этом-то его и суть сильного отличает вот еще нам важно на отказ восстановления Как реагирует в том плане как она реагирует на отлом интернета либо много можно трафик можно полностью отключить потому что на самом деле вот в реальной жизни ты увидишь Если тебе придется тестировать приложение что разработчики очень часто забывают как-то
00:54:57 - 00:56:09
обрабатывать правильно отлом интернета и на это следует обращать большое внимание хорошо поговорим про нативные приложения нативные о чем нативная так но это мобильное приложение допустим она Ну практически не требует интернета может работать без интернета Может подгружать просто какие-то обновленные данные очень очень опасно опасная формулировки Смотри ты говоришь может работать может не работать нет технически Она работает без подключения к интернету интернет нужен для того чтобы подгружать какую-то информацию не
00:55:36 - 00:57:01
логику приложения а допустим какой-то контент с которыми он работает важный момент Если отключить интернет нативного приложения оно будет жить но допустим если это приложение суть его заключается в том чтобы там фоточки подгружать да и фоточки подгружаться не будут свежих фоточек в нем не будет теряется бизнес смысл приложения но оно работает а веб-приложение если мы включим интернет он не работает в принципе это вот это важно а есть нативное приложение которое в принципе не нужен интернет чистый язык даже бизнес смысл например
00:56:19 - 00:57:28
фонарик вот у тебя на мобильном устройстве приложу фонарик или калькулятор калькулятор фонарик ничего сервера не подгружают Вот это самый настоящий нативные приложения и еще ты сказал опасную вещь Ты сказала что это относится к мобилкам доступные приложения тоже называют нативными то есть приложение которое устанавливается на твой компьютер они тоже они просто раньше когда было больше компьютеров меньше смартфонов это называлось достал приложение сейчас это называют нативными Но это типа одно и то же просто
00:56:54 - 00:57:54
платформа чуть разные это это грань она постоянно размывается то есть iPhone становится все больше компьютер становится все меньше и все в принципе приходит к одному как бы знаменателю и принципе у них одинаковые как относится к интернету обсудили в чем еще особенность Тестируем также реконнектом установку обновление удаления тестирование подходит так так но опять же троттлин трафика прерывание Ну трафик может только что обсудили он особо нам не важен потому что само приложение работает без контента вот мы можем проверить но это
00:57:24 - 00:58:44
не Ключевое А вот кросс Какое платформенное рост платформенная Правильно Потому что зависит от мощности железа который установлена так возможно еще на портретную альбомную ориентацию если поддерживается я типа секрету скажу сейчас большинство вендоров просто отключает это возможность и поэтому не так уж много современных приложений поворачивается именно чтобы не фиксить вот эти баги раньше было модно чтобы в двух измерениях было сейчас просто отключает эту функцию Ты хоть как Поверни она все равно будет в своем
00:58:11 - 00:59:24
прежнем этом это нормально два раза меньше работы делают Хорошо Окей так и гибридные тогда расскажи в чем там суть это совокупность найти приложение то есть она также включать установку удаления обновления то есть инсталляцию то есть также мы можем применить кроссплатформенное тестирование так В целом все виды которым там применим из Веба установка требуется правильно подключение к интернету требуется что еще также производительность посмотрим локализация логика приложение где находится на севере или на клиенте
00:58:48 - 01:00:31
Нужно ли нам разрешение пользователя для обновления тонкий момент по моему не нужно разрешение пользователя обновление так Ну да нужно потому что она же может быть без интернета работать Да все правильно все правильно то есть в нативных нам нужно спрашивать пользователя о гибридных Мы же сами только что сказали что основная логика находится на сервере Поэтому в большинстве случаев мы можем на сервере как в приложениях поменять что хотим точка входа останется той же это так называемый тонкий клиент понятия потому
01:00:04 - 01:01:11
что на самом деле в гибридном приложении в том виде в котором мы сейчас его обсуждаем нативная часть она маленькая То есть это не 50 на 50 А может быть даже 10 процентов на 90 и вот это нативной части это так называемый тонкий клиент точка входа ярлычок в приложении какие-то базовые вещи основная вся логика все происходит на сервере мы можем там менять легко и так далее хорошо Да еще что главное про гибридные помнить что на самом деле с гибридными есть проблема в том как мы понимаем Как выглядит гибридное приложение Дело в том
01:00:49 - 01:02:04
что на самом деле у слова гибрид есть несколько разных технических реализаций и вот помимо того что мы только что назвали Да вида приложения выбью applications так называемый то что мы сейчас тонкий клиент часть бывает например еще гибридный фреймворк например гибридный фреймворк Самарин где приложение пишется на сей шарпе а на выходе получается вроде как iOS Android приложение одновременно магия бывает еще всякий подходы но имеет Самое широкое распространение подавляющее поэтому на реальном собеседовании Лучше там говорить что
01:01:36 - 01:02:59
есть Разный подход к понятию гибридных приложений я расскажу про самые как я понимаю часто используем Потому что есть шанс что допустим человек который слушает гибридный расскажешь он может быть даже не знает про них и удивиться и такой рассказываешь не то поэтому тут нужно в аккураточку хорошо и поговорим про методологии немножко да то есть какие-то знаешь методологии разработки как они устроены есть гибкая есть гибкая методология это аджайл это у нас включается тебя скрам Канбан Что такое Но это некий набор правил по которым
01:02:17 - 01:03:58
должен разобраться продукт хорошо также есть водопады хорошо вот у нас набор правил в него входит методологии [музыка] Что такое в чем его суть отличительные разработка по спринта то есть разрабатываем по определенному времени какой-то функционал также включает в себя а если поэтапно То есть это планирование ежедневные митинги в конце хорошо так но сам непосредственно сама разработка со Sprint в процессе ежедневной митинги в конце перспективы то есть мы обсуждаем то мы скинем проблем что мы могли улучшить в следующем
01:03:17 - 01:05:25
и собственно релиз хорошо она планирование что мы делаем то есть мы Возможно мы обсуждаем то за сколько мы сделаем наш продукт возможно времени мы распределяем по участникам команды время За сколько мы сделаем У нас одно всегда для нас принта там две недели три недели месяц но конкретно мы что делаем первое мы выбираем задачи которые будем делать У нас есть Вот и мы из баклага проектов всего Да все задачи которые мы предполагаем в проекте берем задачи в backlock спринта то есть конкретно вот в эти вот этот
01:04:42 - 01:06:09
отрезок и это как раз таки происходит на планирование И помимо того что мы выбираем сами задачи мы что делаем оцениваем оцениваем каждую задачу и Стараемся сделать так чтобы мы были равномерно загружены говорят менеджеры чтобы у нас хватило задач чтобы не дай бог не простаивали не Пошли пить чай но и в то же время чтобы мы успели сделать все что мы взяли вот соответственно мы как тестировщики мы иногда участвуем в этом проекте иногда нет бывает всякое Вот Но тем не менее хорошо хорошо вот есть у нас там какой-нибудь водопад
01:05:34 - 01:06:53
до waterful вот в нем в чем суть Чем отличается отжала получается модель разработки которая такая так скажем более строгая у ней происходит разработка требований устоялась мы делаем разработку самого проекта потом тестировано все делается поэтапно без изменений предыдущего этапа так скажем лучше по-другому говорить лучше говорить Так что в водопаде отсутствуют или затруднена обратная связь между этапами разработками на обратная связь то есть у нас есть те же по сути этапы как мы будем делать потом у нас
01:06:24 - 01:07:53
имплементация идет документации потом программисты работы потом тестировщики Но в отличие от того допустим скрам скрам процесс когда мы находимся в середине пути нет такого что допустим вот сейчас Значит мы одновременно и документацию Тестируем разработчики что-то уже пишут А мы там статическое тестирование проводим Нет там пока к тебе задача не спустилась сидишь потом тебе задачу спустилась ты работаешь потом ты протестировал Пошло все дальше и из-за этого определенная особенности есть вот этих ватерфолл проектов
01:07:16 - 01:08:38
особенности Какие этапы изолированы и поток только сверху вниз идет это не можешь там влезть посередине и что-то сделать Как изменить процесс они применяется для таких серьезных так скажем проектов как Почему медицинская оборудование Почему Потому что цена ошибки с краями не может быть не будет такой высокой допустим как в построении аппараты МРТ значит что значит у нас чаще будут баги в храме возможно Почему потому что у нас [музыка] крайне могут быть чаще такой модный процесс модно молодежно все
01:07:58 - 01:09:39
там придумали что все Шустро делалось а у нас больше багов как же так но так скажем применяем к проектам не такого серьезного масштаба как почему Почему мы ракеты по скрам не делаем потому что именно вот эта Суть аджайла в том что все гибко и то что может в любой момент что-то изменяться она вносит определенную сумятицу неразбериху в проект То есть когда вы сидите у вас среди нас принта подлетает менеджер говорит так я только что пил вино с клиентом он говорит ему вообще не нравится что мы делаем Короче у нас есть
01:09:01 - 01:10:29
пол спринта чтобы все исправить бросаем что мы делаем сейчас это в быклок это избы клоу так все шуры-муры Давайте до конца недели осталось вперед разработчики сделают Ты может быть даже успеешь протестировать если повезет и может быть даже заказчик будет доволен Вот потому что для него это важно но итоговая реализация вот будет намного более Забавно чем если вас никто не трогал Ну и перемешается все да да Вот то есть ты шел по плану там у тебя было в голове там вот сейчас мы документацию потом это
01:09:50 - 01:10:56
бомбах все это так переворачивается вы с этим справитесь но на выходе шанс что будет бак потом и пропущен и вправду пойдет намного выше А ватерфоле из-за того что медленно все размеренно постепенно по этапам Никто никого не трогает никто никого там за голову не трясет за плечи когда человек сидит работает все более размеренно там получается так что сам процесс разработки дольше и на выходе Может в рынок хуже вписываться Но при этом будет намного стабильнее качественнее более консервативный такой
01:10:24 - 01:11:30
подход так скажем и поэтому если разрабатывается что-то Что требует больших финансовых вложений там создание этой ракеты или робота там никто не торопится потому что там рынок не такой конкурент а когда хотят создать быстрый интернет-магазин который продает какой-нибудь новую хрень новомодную там фиджет спиннеры какие-нибудь или там у госапоги там каким-то или еще что-нибудь модной там футболки с каким с принтом принтом Им не нужно год этим заниматься у них есть месяц Чтобы успеть ворваться в тренд а рынок да да успеть за рынком
01:10:57 - 01:12:06
Чтобы успеть за рынком надо делать быстро и пусть даже с багами Ну потому что если в интернет-магазин глюка Нет никто не умрёт А с ракета упадёт то может умереть Вот почему мы говорим Да что где-то там канает работает Хотя постепенно некоторые даже крупные компании переходят более мелким вот этим инкрементом например вот Windows раньше менялся раз несколько лет большим обновлением Теперь ты хочешь выключить Нет братан Мы сначала обновимся потому что сегодня залили в меня какого-то потом ты выключишься это может
01:11:32 - 01:12:36
происходить раз в неделю раз три а раньше это происходило огромными сервисами раз в несколько лет То есть даже вот разработка таких сложных вещей она больше идет со временем сужаются темпы разработки и маленькими кусочками она пропихивается вместо одних больших кусков хорошо супер принципе мне понравилось как Мы пообщались там можно какие-то еще Вопросы задать Ну я думаю и так хорошо значит смотри что тебе нужно подтянуть нужно будет по поводу ящиков Повторите белые свежие черный ящик да чем не отличается почётче
01:12:08 - 01:13:36
Что значит это для того Это для того Это для того значит мы Тестируем бизнес требования тут мы значит Тестируем код так в уровнях там про этот самый про приёмочная что у нас есть ацетон техники дизайна в принципе хорошо про эти вспомнить про жизнь цикл баг-репорта Что происходит если разработчик сразу отказывается дубликат ноты бак родился Ну и про принцип работы приложения видов тестирования тоже советую почитать не просто это также это не так же вот прям четко я тебе рекомендую Как смотреть критерии выписать типа
01:12:52 - 01:14:14
подключение интернета необходимость да нет да потом Нужно ли разрешение на обновление это же каждому виду Опа И вот такую себе табличку нарисовать и четко по этой табличке про каждый вид будет тебе проще запоминать или там даже как шпаргалку все положить там на всякий случай и уже от этой табличке можно будет и во-первых рассказать как они работают а во-вторых по ней сориентироваться Какие виды тестирования можно применить Ну и в принципе все на реальном собесе тебя еще могут спросить про Континенте
01:13:57 - 01:15:03
integration может посчитаешь что это такое Но обычно глубоко не копают Вот и в принципе все ну если занудный попадется собеседующий он начнет докапываться запросах ответа глубже мы прошли а он может спросить допустим о чем разница между пост и геям разница между этими вот такие вещи я думаю не нужно вот не спросить но такое бывает вот в принципе мои замечания Так я считаю что хорошо подготовленный вполне можно реально собеседование даже с этими знаниями Да в целом Нет все слабые стороны я для себя подчеркну будем работать дальше
01:14:32 - 01:16:07
супер Хорошо тогда если что пиши в личку с вопросом можешь на бусте подписаться хочешь не там это не отписывайся тогда Ну всё удачи на собесах Давай Спасибо большое Пока Ну как вам собеседование хочу отметить что ближе к концу когда собеседование перевалило за час Павел немножко поплыл и ему стало отвечать на вопросы несколько сложнее это очередной аргумент пользу того чтобы собеседование не затягивать и в принципе любой интервью Верт должен стараться ложиться в час потому что после этого времени
01:15:28 - 01:16:58
продуктивность общения несколько упадет подписывайтесь на канал переходите По ссылкам и записывайтесь на подобное интервью Если хотите со мной пообщаться пока
[музыка] Всем привет Сегодня у нас новое собеседование на Junior qa с Павлом Так что не отвлекаемся и смотрим так Привет Представься пожалуйста расскажи как тебя зовут Какой у тебя опыт тестирования и что ты хочешь о себе узнать Привет меня [музыка] релевантного опыта у меня нет Я прошел курсы самостоятельно почти заканчиваю курсы которые приобрел недавно и хотел бы собеседоваться на инженеры посмотреть так скажем свой опыт Хорошо Ну тогда мы начнем с каких-то базовых вопросов и Расскажи пожалуйста что такое
00:00:01 - 00:01:52
тестирование по твоему тестирование Это проверка ожидаемого на основе хорошо а что такое качество Как ты думаешь качество это удовлетворение продукта пользователя либо заказчика в соответствии с его применением а где такие критерии качества могут содержаться критерии качества Ну допустим в требованиях они могут прописаны продукту спецификациях То есть как наш продукт должен работать эти все моменты древние спецификации в принципе письменная документация это одно и то же по сути может быть где-то еще мы можем брать
00:01:04 - 00:02:39
источники Как ты думаешь Ну вот такое бывает в реальной жизни что ты попал на проект и говоришь Дайте мне документацию есть норма Как мы можем узнать требования можно прописать для себя для проекта для создания документации мы можем посмотреть на продукты допустим со стороны конкурентов мы можем мозговым штурмом с командой обсудить какие у нас интересует вопрос по продукту То есть общение заказчика Ну если по прям вникать в теорию то есть там еще такой формат то есть фокус-групп то есть мы грубо говоря как в это тестирование
00:02:06 - 00:03:42
только на сбор требований то есть Так мы собираем с группы каким каким продуктом видит Какой продукт хотел бы получить это группа людей соответствие основываясь на их мнение в целом как бы что-то вроде маркетингового исследования так понимаю Да да прототип можем создать дизайн начальный принципе все верно Есть еще одно место где мы обычно можем брать Какие требования но также называется очень просто здравый смысл commance то есть мы действительно можем с кем-то обсуждать можем спрашивать у заказчика у
00:03:08 - 00:04:34
бизнес-аналитика и можем брать аналогию с других приложений похожих все правильно еще бывает здравый смысл то есть мы грубо говоря мы проверяем как приложение работает бах у нас оно вылетает вряд ли где-то в документации написано на каждой странице приложения что оно не должно вылетать тут да то есть ну мы понимаем что что-то происходит не то оно падает Хотя прямо не указан документации Что такое быть не должно и такого на самом деле очень много там где нету требований и с твоим с ростом твоего
00:03:51 - 00:04:53
опыта вот этот Common Sense он станет на самом деле настолько же важным как и документация если она существует Ты просто набьешь глаз руку и поймешь где нормальная хорошее качество где хромает хорошо какие ты можешь цель тестирования назвать Так ну первоначальная цель чтобы продукция ответила нашим требованиям спецификации продукту удовлетворял пользователя чтобы продукты удовлетворял заказчиков кто собственно и начал продукты Так ну в целом чтобы сохранить репутацию компании протестировав продукт тем самым ну качество
00:04:22 - 00:06:09
возможно причем каких-то заказчиков Ну вот прям очень глубоко заказчик Извне если у тебя какая-нибудь там соцсеть по хранению фоточек Ну какие заказчиков изменил репутацию ты правильно сказал репутационные риски мы можем поделить если прям углубиться Да у нас есть там денежные риски бывают Ну грубо говоря у нас банковское приложение в нем бак деньги считаются неправильно банк потерял деньги репутационные это сам факт наличия Бага может отвернуть пользователей от приложения например какой-то Время назад в Тинькофф банке
00:05:16 - 00:06:31
был бак с пересчетом между разными валютами и некоторые пользователи за эксплуатили эту ситуацию и просто намайнили себе денег какой-то промежуток времени Вот и банк понес репутационные риски потому что все поняли что банк дырявый на тот момент в том случае Окей хорошо Какие ты знаешь виды тестирования это ручная Автоматизированная она функционально это проверка основного функционала основной бизнес логики прописаны требования Ну возможно может быть еще функциональности если наш продукт заточена именно
00:05:56 - 00:07:36
представление функционально это тестирование тестирование инсталляции локализация интернационализация разобралась платформенная тестирование производительности тестирование отказа устойчивости Смотри чуть-чуть тормозим стрессовая нагрузочная это все в одном месте У нас есть тестирование производительности производительности да а в нем есть несколько видов и там есть проверка пиков хайпик тестинг есть нагрузочная когда мы то есть это все разные профили нагрузки поэтому тут аккуратно нагрузочное тестирование
00:06:57 - 00:08:26
лучше либо просто говорить про него что она есть либо прям вглубь Но если ты прям четко можешь рассказать все виды и так далее То что могут уточняющий вопрос спросить по поводу тестирования безопасности ты сказал что если наше приложение выполняет какие-то функции по безопасности Ну на самом деле тестирование безопасности это не только если наше приложение которое мы Тестируем что-то делает по безопасности это в принципе Любое приложение которое содержит себе какие-то платежные данные личные данные паспортные данные и так
00:07:54 - 00:08:58
далее То есть Это именно приложение в которых человек слишком много о себе сообщает информации и в такого рода приложениях желательно иметь возможность тестировать безопасность особенно если модули которые отвечают за безопасность это не модули которые мы берем так называемый сервис сторонние приложения сами с нуля пишут банки любят хорошо про тестирование локализации Расскажи что в рамках тестирования локализации мы проверяем в рамках тестирования локализации мы проверим допустим продукт который
00:08:26 - 00:09:43
создали на определенный локаль мы учитываем допустим юридический особенности этой локали то есть также мы смотрим перевод текста валюта то есть размер если это интернет магазин допустим одежды размерная сетка также там могут быть литры галлоны единицы измерения различные но в целом Я бы наверное тестировал основные вещи назвал я бы тестировал Наверное тогда ознакомился с определенным локалье и уже на основе их особенности уже выявил конкретные точки с которым я работал эти точки назвал Единственное что забыл на
00:09:08 - 00:10:41
самом деле очень важный самая вещь которая меняется еще формат да ты времени потому что Америка меняется местами день месяц и так далее поэтому тут Важно хорошо хорошо так инсталляция проверяется установка обновление удаление обновление через через версию откат на другую версию допустим А ну допустим удалил и заново установил то есть такие моменты все правильно отлично супер ты говоришь что есть ручной есть автоматизированное тестирование как ты понимаешь автоматизированное тестирование То есть
00:09:55 - 00:11:26
я думаю если нам нужно сократить время на какие-то рутинные задачи мы их можем за автоматизировать то есть чаще всего наверное это будет мог регрессия тестирование с разных модулей уже собралась и если нам обсудим про автоматизацию ты говоришь самые частые сценарий мы имеем в виду что Да вот и ты говоришь что лучше подходит смог и в регрессии хорошо спору нет Все отлично Все Каким образом создаются автотест Что делается чтобы они были то есть на основе тест-кейсов которые прописал допустим Ну допустим представим ситуацию что у нас
00:10:47 - 00:12:36
крупное дело у нас есть мануалы авто и вручную это стирающийся и передал эту документацию автоматизатору и автоматизатор каждый шаг уже начинает прописывать код соответственно Запускай его программа отрабатывает через браузер Либо это будет То есть это по сути говоря программа да то есть программа написана на каком-то языке программирования вот и она проверяет нашу исходную программу которую мы Тестируем есть у нас еще ящики разноцветные Да белый черный ящик белый ящик наверное разделяется по доступному коду
00:11:47 - 00:13:12
получается сами разработчики открывает свой код так это модуль на тестирование тестирование Black Box это тестирование статического характера То есть она включается тестирование документации тестирование также наверное макета прототипов каких-то [музыка] наверное покрывает больше основное требование тестирование наверное Ну как насколько я для себя вывел наверное 150 источников То есть это есть доступ допустим к базе данных Ты можешь проверить как база данных реагирует на наши действия хорошие Что такое
00:12:42 - 00:14:23
но я думаю что это методика тестирования когда допустим нет доступа у обычного пользователя но есть доступ у нас как у специалиста Ну не совсем ну хорошо Хорошо ты постарался рассказать смотри что надо выделить в ящиках в принципе да что между ними разница найти Первое это то что правильно Ты заметил что насколько мы имеем представление о системе внутри как она работает с технической точки зрения То есть если в Белом ящике мы знаем как работает код можем в нем разбираться мы с ним взаимодействуем мы
00:14:17 - 00:15:32
пишем Unit тесты черный ящик мы не знаем как работает код но мы знаем как работает бизнес логика Вот и второе помимо знания внутренняя часть системы Это что мы покрываем тестовым сценариями в первом случае в Белом ящике мы покрываем сам код то есть суть Юнит теста в том что они в отрыве от основной бизнес логике они просто проверяют функции кода маленькие кусочки А когда мы Тестируем черным ящиком Мы берем наши там юзер стори наше понимание того как должен пройти именно бизнес задачи должны пройти и покрываем тестами
00:14:55 - 00:16:14
уже бизнес требования они блоки кода вот два параметра основных ты еще сказал что черный ящик он больше подходит для статистического тестирования это не так черный ящик подходит для любого вида тестирования где мы покрываем бизнес логику статическое динамическая неважно и что касается серого ящика это действительно довольно мутная история в теории можно прочитать много историй много статей и какой-то из них ближе которая к душе легла принять почему часто пишут о том что это подходит для тестирования базы данных
00:15:33 - 00:16:45
тестирование API потому что вроде как это что-то посередине мы с одной стороны не знаем На самом деле как работает код backenda Ну не знаю То есть Да есть база данных Но вот как из нее что дергается мы сами не знаем но при этом Мы можем с ней как-то взаимодействовать например через графика User интерфейс для баз данных есть такие То есть Не обязательно писать запрос там Селект фромта то можем просто буквально как в Excel таблички поковыряться Но с другой стороны наша ковыряние в базе данных и проверка в то что мне что-то появилось
00:16:10 - 00:17:18
Оно идет несколько отдельно от бизнес логики потому что ну допустим изменения в базе данных могут касаться каких-то очень узких там моментов в системе и поэтому нельзя сказать что при тестировании баз данных мы проверяем именно бизнес-логику и так далее и мы как бы под капотом уже Мы ковыряем базу или Мы через постман отправляем запросы или там через другую систему на сервер и получаем ответ и так далее вот поэтому это можно отнести к серому ящику но на реальном собеседовании можно наткнуться на сложную философию А многие
00:16:44 - 00:17:57
собеседующие и не знают ничего про серый ящик и говорят только про белые чёрные и нормально всё проходит ящики обсудили хорошо есть у нас Цените смог и regression тестирование Вот и привлеклись даже начал что-то рассказывать да и просмотров немножко рассказал можешь рассказать про эти три вида Но это уровне тестирования на которых мы проверяем функциональность то есть наша система Письмо к тестирование это поверхностная проверка нашей основной бизнес логики то есть Цените тестирование это тестирование вглубь определенного
00:17:21 - 00:18:43
участка Ну или репрессия это тестирование добавление новые функциональности когда мы добавили новый функциональность проверка со старой проверяем те части приложения которые не изменились с нашим новым наблюдением но могли как-то на них нововведение в теории повлияет но не напрямую Вот ты в проекте работаешь и в программе которая тестируешь ввели новый функциональность кусочек добавили какой-то вид тестирования применишь в начале и какой применишь дальше Вот из этих трех В каком порядке Почему Ну сначала бы я проверил основной
00:18:07 - 00:19:36
основную работу функционала поверхностно как она работает потом бы я начал применять ценники то есть грубо говоря Копатель функциональность и применяя различные виды и затем я бы проверил старый функционал с добавлением этой новой фичи например ты не можешь сначала проверить регрессию на потом Цените Ну проверить что сначала старый функциональность а в конце проверишь но какая для тебя разница Нет новая функциональность она может повлечь на старый Вот и найдешь баги в Старой функциональности а потом в конце
00:19:05 - 00:20:33
возможно иного протестируешь Зачем нам Цените раньше регрессии проходить если мы как бы вроде и то это пройдем в итоге но так она как бы мне кажется отталкиваясь от теории то есть Так они называются уровни тестирования поэтому мы проходим все поэтапно А почему вот почему у нас такие вот Ну вот мы выделили вот эти Ну уровни тестирования там есть другие вещи которые так называются называем просто вот виды тестирования вот эти вот и вот у нас есть понятие задаст вопрос там своим коллегам на работе на новые они тебе могут сказать
00:19:49 - 00:21:02
что мы считаем что регрессию надо вначале делать есть такие вот и ты спросишь почему они говорят Да мы так читали вот кстати вот поэтому тут нужно понимать Да почему почему мы именно Вот так мы располагаем мы так располагаем обычно потому что шанс найти выше случае с Наука и цените при добавлении но функциональности а шанс найти бак в регрессии меньше потому что мы подразумеваем что в регрессе лежит те проверки которые непосредственно не затронуты новым функционалом а новый функционал он всегда несет в себя беду
00:20:29 - 00:21:53
Потому что его никто ни разу не проверял А в регрессии лежат тесты которые мы уже как правило хотя бы раз проверили они когда-то были тоже Цените тестами Ну в прошлом в прошлом цикле разработки и мы их уже там смотрели Ну или кто туда наш коллега и вот у нас новый функциональность и нам надо проверить именно ту сырую часть первую очередь и часто Если ты будешь работать например не в крупных продуктовых компаниях а допустим в аутсорс аутстафах которые на заказ разрабатывают на чей-то у тебя не будет
00:21:11 - 00:22:15
просто времени на регрессию просто не будет времени у вас будет очень быстро и спринты и твоя будет Главная задача Так свою работу организовать чтобы делать максимально много пользы с минимальным затратным времени и ты будешь просто даже на собеседовании ты можешь спрашивать такие компании там проекты снова с регрессией очень часто буду говорить У нас есть тесты которые регрессию мы уже целый год ни разу не проводили потому что у нас идет молд потом ценники потом конец принта потом новый спринт и так далее и от регрессии
00:21:43 - 00:22:45
мы можем отказаться Да может быть мы из-за этого пропустим какой-то баг но шанс что он там будет маленький А вот от смог отсадите нам желательно не отказываться потому что шанс там будет бак при добавлении новых функциональности больше вот причина Зачем нам вот это вот структуру нужно и не просто из теории Да это реальной работе поможет хорошо так слышал когда-нибудь про характеры там позитивные негативные характер тестов да то есть позитивной проверки у нас за точно на проверку должен работать наш продукт то есть
00:22:13 - 00:23:34
негативные проверки и система должна отработать верно ошибку предложить какой-то вариант отлично хорошо Окей и вот у нас есть то что часто называют уровнями тестирования иногда могут по-другому назвать кто нас есть несколько уровней по степени интегрированности элементов системы друг с другом по степени интеграции виды тестирование по степени интеграции или уровни тестирования называется вот ты уже один уровень называл в рамках белого ящика Да какой модульный модульный так дальше какие у нас идут
00:22:59 - 00:24:15
операционная системная приёмочная где-то есть теории где-то нет И давай повторим тогда модуль на это что модульная Это я не тесты покрывает разработчик сам свой код это отдельные участки интеграционные взаимодействие с этими модулями которые так системно это совокупность всех модулей в целом то есть как полностью работает наш проект наша программа Ну и приёмочная так если сформулировать свое мнение то есть системная но возможно с какими-то элементами добавления при сдаче продукты может быть элементом один это называется план
00:23:47 - 00:25:27
испытаний это по-русски если говорить А по-английски это ацетон с плен Вот то есть это просто ты с кейсы которые подписывают не только Ну там Ты для себя сделал для команды ну их заказчик показывают говорят вот план испытаний мы если проходим по нему вы принимаете нашу систему они говорят Да окей Правда в том что ты же сам подгоняешь план испытаний который ты же должен пройти Если пройдешь приложение с данного в редких случаях тебе сверху спускает этот план испытаний но чаще всего если заказчик не
00:24:44 - 00:25:41
технически то ты для него пишешь план потом говоришь Ну что как вот Согласно с этим они говорят да да не показываю нам это все мы верим все нормально Давай и по нему проходит сюда и система сдается частью или целиком хорошо знаешь ли ты что-то про техники то с дизайна как генерируется тестовые сценарии техники то здесь нам нужны для упрощения так скажем тестовых формирование тестовой документации минимизируя доске чек-листы но при этом не чтобы мы проверили то есть полностью основной продукт с минимальным набором
00:25:13 - 00:26:55
документации лучше так говорить что мы уменьшаем количество сценариев тестирования не снижая качество тестирования самое лучшее на самом деле разные техники для разного нужны Но вот допустим те техники про которых все спрашивают на собеседование Да это эквивалентное разбиение они вот тупо нужны для того чтобы ты поменьше тестов написал не причем не упустив какие-то моменты Вот соответственно техникой эквивалентом разбиение мы разбиваем на классы и значение в этом классе должны одинаково отработаны быть как в системе
00:26:08 - 00:27:36
какие-то классы могут быть в реальной жизни Ну класс допустим языка там кириллицы латиница класс спец символов класс цифр набор прекрасно хорошо техника анализа граничных значений Как работает в паре с эквивалентом избиением То есть это мы допустим на примере если у нас есть поле ввода и у нас определенная от нижней границы до Верхней границы допустим границу и выходы за границу плюс минус проверить середине Сколько получается у нас тестовых сценариев если мы допустим Тестируем интервал от 10 до 100
00:27:00 - 00:28:37
тоже так а Можем ли мы тестировать интервал допустим не числовой Да там а интервалы алфавитный вот нужно нам вывести допустим значение по алфавиту и проверить что значение одной там до другой буквы работают то же самое интервал Да только не между чисел а между буквами в алфавита такое может быть Ну да может быть то есть мы допустим проверим там первая буква алфавита и последнюю в целом мы сократим 33 проверки Ну да наверное можно так Ну принципе да все правильно потому что компьютерные системы они
00:28:01 - 00:29:23
знают порядок алфавитов используемых и работает с ним также как числовым рядом хорошо отлично давай поговорим про тестовую документацию мы создаем в процессе работы как правило Какие виды набор мы должны проверить продукт то есть состоит из наверное есть стандарт плана можно его написать то есть стандартом 829 какие части Он включает то есть ну что мы Тестируем как мы это будем тестировать то есть применение туров то есть сколько нам потребуется времени на это кто будет тестировать Ну и критерии выхода
00:28:48 - 00:30:37
и входа так Какие может назвать критерии допустим входа что требование мы проверили требование и они удовлетворяют согласна теме критериями это сложно Сложно мы проверили критерием обычно будет являться допустим наличие требований вот так вот что они в принципе есть мы можем начать тестирование Когда мы уже будем сами требования читать и проверять это уже будет просто статическое тестирование это то чем ты будешь заниматься каждый спринт приходит задача Ребята давайте вот такую-то перделку добавим Вот на нее
00:30:06 - 00:31:16
документация разработчики в бой тестировщики пока вам нечего тестировать потому что разработчики только начали читайте документацию это уже процесс тестирования пошел а вот критерием начала может быть и стильный как раз таки то что тебе дают документацию в принципе Какие еще могут Кроме того что документацию дали то что у нас подготовлен тестовая среда Возможно да там допустим у нас мобильное тестирование нам забыли дать телефоны допустим на эмуляторах нельзя окончания тестирования когда наш допустим тест кейсы чек-листы
00:30:51 - 00:32:14
покрыли основной функционал То есть три выхода то есть еще может быть то что [музыка] минимальное количество там багов в приложении не минимально какой-то определенный соотношение например набор например мы можем указать там или нам могут сверху выставить что допустим не должно быть критиков багов вообще не должно быть менеджер багов допустимая на баги могут быть или не должно быть багов абсолютно никаких вообще 0 и тогда мы можем такое зачем они нужны это набор проверка для нашего функционала чек-лист это
00:31:40 - 00:33:12
подробная проверка в систему от эскиз это уже подробное описание проверки состоящие из различных допустим ID номер требований Давай лучше начнем тест Вот таких полей без которых мы не можем мы можем как-то без зайти и без номера А вот что нам важно иметь результат название проверки ожидаем результаты название проверки в принципе сама основное Да может еще статус быть автор номера вот все правильно По поводу чек-листа Ну ты как не очень хороший пример привел проверки чековщик листе который стоит из чеков каждая
00:32:35 - 00:34:11
предложение это проверка это правильно и стык как правило человек вот из одной предложения но это не просто приложение проверить там все-таки мы стараемся в вот этом предложении как раз таки по возможности расписать суть проверки и место проверки просто это Все выглядит очень сжато например пользователь может зарегистрироваться свалидными значениями пользователь не может зарегистрироваться с не валидными значениями вот один чек второй чек но тем не менее это приложение оно как правило достаточно длинное чтобы если с
00:33:34 - 00:34:37
проверкой более-менее сложная Но кроме этого предложения действительно ничего нету Хорошо Как ты думаешь Зачем нам два вида документации для одного и того же для того чтобы загугментировать проверку то есть какой мы бы приняли в каком случае Ну да в принципе Зачем Мы не пользуемся только чек-листами или только тест кейсами допустим чек-листы актуальны для компании которые стартапы какие-то на несколько месяцев некоторые компании через три-четыре года называется стартапами стартап это такое размазанное слово есть
00:34:06 - 00:35:35
критерии Да по которым мы выберем чек-листы Или ты с кейса одно либо другое первое Как мы можем выделить это Ну ты наверное об этом начал Да это наверное предполагаемый срок разработки мы подразумеваем что это разработка на пару месяцев идти это там первая версия нам наверное нет смысла запариваться документацией потому что стартап не взлетит да если это компания которая там себе называет не называет стартапом неважно но мы знаем что у нее уже длинные цикл разработки срок разработки планируется
00:34:56 - 00:36:02
надолго там на год на там еще что-то то наверное есть больше смысла писать сразу ну или с этого момента тест кейсы потому что ну история будет длинная и нам желательно иметь подробную хорошую документацию Какие еще как ты думаешь критерии повлияет на выбор допустим если я один тестировщик то есть я могу писать для себя Понятно Если никого больше не будет команд тестирования я могу для себя писать А если у нас команда большая и проект у нас как ты говорил длинный мы и он перспективе будет развиваться мы будем
00:35:31 - 00:36:45
писать также мы будем писать когда у нас предполагается расширение команды чтобы вводить в курс дела новых пришедших специалистов Ну вот первый критерий срок Значит у нас проектов второй критерий это размер команды тестирования Да там или Будет ли кто-то в принципе читать наши тесты проверки и Можно с вами выделить третий критерий это время которое у нас есть на проекте проект может быть большой в нем может быть очень много людей но там все равно будет все висеть на чек-листах потому что структура разработки будет
00:36:12 - 00:37:25
такова что И что просто не будет времени писать длинные эскиз и получится что либо ты пишешь только То есть это не успеваешь тестировать либо ты быстро накидываешь себе эти чек-листы и тестируешь по ним соответственно выбираешь что лучше писать что-то чем ничего не протестировать потом Окей хорошо дальше у нас репорт что это такое задокументированная дефект приложении на котором можно их взять так потом ожидаемый фактически результаты на кого назначен бы ну и прикрепляем там фото видео блоги Отлично Отлично называют приложение
00:36:51 - 00:38:33
Хорошо хорошо супер есть у нас еще там бывает приоритет Да помимо все что указал вот если тебе не повезло там будет еще отдельно северите отдельно приварите вот это вот мозгодробительная часть но чаще всего в жире допустим будет только приоритет который себя будет подразумевать сразу все то есть и в принципе с этим не будет проблем никаких вот Как ты думаешь кто устанавливает вот приоритет Бога То есть как мы выбираем правильно приоритет допустим приоритет это вообще Насколько быстро нужно починить проблему
00:38:06 - 00:39:33
То есть как выставлять отталкиваясь серьезность если это будет невозможность оплаты то есть это будет приоритет а допустим если это какой-то тривиальный баг то есть ошибка в тексте это будет минимальным минимально Представь себе приходит заказчик Газпром там какой-нибудь вот разработчик что-то там пилил и он даже не знал как бы заказчик называться и там вместо название реально заказчика написал там какой-нибудь хрен банк вот это все впрок попала туда все И ты такой видишь И в шоке система сильно от этого страдать Нет
00:38:52 - 00:40:23
никто не страдает Ну там написано хрен банк вместо заказчика высокий приоритет будет или низкий высокий конечно высоким Ну а ты говоришь что типа серьезности значит на то насколько сильно опектит систему так слова одно слово другое слово насилием с тем-то не эффект система работает деньги проходят Вот только вот заголовок кривой Да тут лучшим ответом будет являться тот зависимость от того что ты тестируешь в зависимости от стадии на проекта мы определяем Какой должен быть приоритет например на ранних стадиях развития
00:39:45 - 00:40:57
проекта у нас как правило приоритет высокий только для технических всяких задач а допустим опечатки неправильный какой-то дизайн это низкий приоритет но по мере приближение к релизу часто приоритет Вот вы печатках и так далее увеличивается потому что увеличивается шанс что скоро это попадёт к реальным пользователям или хотя бы к заказчику но В некоторых случаях как вот я сейчас сказал иногда имиджевые баги лучше сразу поднимать высоким приоритет например неправильное название заказчик или ещё что-то что может обидеться и всё пойдёт
00:40:20 - 00:41:30
не так как хотелось бы вот поэтому при выборе приоритета тут надо оценивать ситуацию вокруг да какая у тебя и чтобы разрабатываете разрабатываете вы допустим чат Ну соответственно баги которые относятся к функциональности чат они важнее чем баги которые будут относиться к разделу настройки хорошо жизнь цикл баг-репорта Давай обсудим Вот ты завел багрин порт что с ним происходит назначен то есть на разработчика он получается фиксит его отправляет обратно То есть я проверяю если все окей его закрываю если нет
00:40:56 - 00:42:23
хорошо отлично это вот в идеальном случае так и происходит правильно если разработчик Вот ты отправил разработчик опять починил Куда дальше разработчик починил тебе попадает переоткрытый что ну посмотреть Да там этот сделал да то есть проверить что [музыка] проверяешь он опять воспроизводится что дальше так но я переоткрываю переоткрываю на разработчика опять с теми же условиями которые были прописаны Back Report и без комментарием Да может быть что-то добавишь допустим это что-то выяснить дополнительно такое бывает Ну вот смотри
00:41:52 - 00:43:14
вот у вас и цикл происходит он чинит ты проверяешь он чинит ты проверяешь в какой-то момент разработчику стою говорит у меня Бога нет я занят я не буду я проверю совместимость может быть окружение Может быть я какой-то у меня косяк был смотрю опять еще раз документацию так ли оно должно все быть в таком случае документация у нас значит прописано четко вы с разработчиком выяснили что вы правильно понимаете окружение вы ну по возможности сделали схожие что еще бывает не так Ну возможно Так может быть он не обновил
00:42:42 - 00:44:15
код ветки То есть я посмотрю последнюю может быть время изменения какое было все правильно то есть Может быть он вообще изменения забыл залить такой бывает он же все локально собирает приложение тогда ли он себя починил и довольные побежал баг репорт отдавать тебе а забыл кнопочку нажать чтобы залилось дальше а Бывает такое что он залил Но ваш контент integration система которая собирает это все вместе виде приложения с определенным номером версии с номером билда выдает Она еще не сработало сработает через час или завтра
00:43:31 - 00:44:36
утром Вот и просто вы тестируете опять же на разных версиях вот допустим и это вы проверили и все нормальные версия кода правильная Что дальше делать но исключив все возможные наверное моменты я обращусь к руководителю непосредственно к Лиду либо приоритет Но это серьезности как она влияет на систему и в целом поставлю может какой-то комментарий Правильно Да Все правильно потому что проблема многих начинающих тестировщиков это что они слишком сильно топят за свои баг-репорты просто до драки твоя задача
00:44:04 - 00:45:22
проинформировать всех кого можно кого надо ли Да если если Но самое главное Project менеджера потому что project-менеджер в итоге может пнуть разработчика и заставить его все-таки починить бак там если он тоже уверен что он воспроизводит или сказать тебе он скажет Ну сделаю что-нибудь с багом там убери его в быклок или Закрой это типа не так важно сейчас не отвлекаю нашего Васю Вася на нём держится вся мощь нашего проекта он короче занят действительно вот а мы предоставляем информацию говорим вот такая ситуация
00:44:56 - 00:45:55
Давай товарищи прожить менеджер разрулились за нас Я драться с разработчиком не буду за этот бак есть Вот соответственно так эти вопросы решаются хорошо что может если мы вернемся Да к жизненному циклуба-репорта что может ещё с багом происходить после того как ты его завел если разработчик сразу плачу что-то неладное и решил ничего не чинить со старта что он может [музыка] ссылку дубликат дубликат случае дубликата что происходит Так ну то есть получается я смотрю если в каком статусе предыдущий баг То есть
00:45:26 - 00:46:57
это дубликат если он открыт Я возможно там приложу свой второй бак что это проблема Актуально до сих пор но если он закрыт я переоткрываю свой и линкую ссылку старого проблем когда-то была она возникла снова хорошо Какие еще бывают случаи кроме дубликата когда разработчик сразу ничего не захотел что он не хочет я вот не буду потому что дубликат или Бэм что-то еще что-то еще бывает может быть это новый функциональность то есть добавлены в требование я но открыл бак там на старые требования правильно да то есть часто ноты бак
00:46:12 - 00:47:47
пишет ноты бак есть статус типа ты писал когда тесту документацию допустим по старым требованиям потом втихаря поменяли тебе этом не сказали или ты сам случайно упустил и функционально теперь по-новому работают и теперь-то она работает правильно просто документацию устарела Вот и надо бы тесту документацию исправить еще что может быть кроме ноты бак бывает еще статус не будут делать когда в обычно ставят его обычно ставят когда [музыка] разработчик согласен что там есть бак Что может быть Его надо было починить но
00:47:17 - 00:48:25
он например в курсе что либо эту часть приложения полностью выпилит всю либо полностью перепишут он скажет да я согласен Вот в настройках косяк но мы выпиливаем настройки в этом или в следующем спринте типа зачем его чинить раздел не будет лучше также обращается Иван Иванович точно да правда сказал или написал все выпиливается закрываем что типа бак есть оставляем до тех пор пока функциональность Не выпилиться ну у нас ситуация остается Вот а еще бывает статус к на три продюсер то есть эта ситуация мы с тобой
00:47:58 - 00:49:25
обсудили ситуацию Когда вы допустим бак завели пару раз друг другу кинули и потом разработчик сказал что у меня не воспроизводится а может быть такое что сразу и разврат сразу тебе говорит а мне не воспроизводится нормально и тут принципе меняется то о чем ты рассказывал проверяем что мы на эту версии что у нас значит понимание ситуации такое же и у нас схожее окружение максимальное не всегда идентичные компьютерные и если это все нет тогда ты тоже либо расишь к своему говоришь нет либо убеждаешься что ты действительно
00:48:42 - 00:49:55
перестарался это действительно бака такого нет этого Случайность была какая-то хорошо говорим про разные виды приложений какие-то в принципе знаешь три группы приложений на которые сейчас мы можем поделить то что создается [музыка] приложение в приложении работает по клиент сервере текстуре клиент отправляет запрос на сервер сервер обрабатывает запрос если нужно обращаться к базе данных что это вытащить значение Ну и отправляет обратно на клиент и соответственно клиент отрисовывает наш запрос А вот то что все назвал ездил запрос
00:49:18 - 00:51:04
ответ взаимодействие то чем все регулируется так скажем То есть это сертификат безопасности что он делает а ну шифрует данные трафик то есть в https формате можно перехватить трафик но нельзя прочитать о содержимое То есть можно удостовериться что-то куда-то летит но прочитать нельзя ваш степи можно и можно не только прочитать Но и вмешаться в него изменить и не знаю было время когда можно было в Макдональдсе сесть с ноутбуком ВКонтакте работал на http и ты мог подключиться в сессию другого человека который тоже сидит с
00:50:23 - 00:51:45
тобой в Макдональдсе в том же wi-fi от его имени там написать его друзьям какими гадости смешное время было до того как ввели сертификаты безопасности это перестало быть возможно хорошо запрос у нас обычно на сервере какими атрибут из чего он состоит если нужно тело запрос какие-то бывают еще метод или тип запроса get-пост под Delete Patch это основные такие про которым хорошо за достаточно ответ что все содержат обычно ответ содержит от тело запросы хайдера также Какие статус коды было 100 200
00:51:25 - 00:52:57
400 500 информационные 200 это успешные 300 перенаправление 400 ошибки на стороне клиента у нас какой-нибудь тело передается если мы ответ получаем 400 или 500 Нет не передается в теле ответы то есть там Джейсон текст формата адрес он либо xml какой архитектурный стиль этот самый HTML делами то есть нам передается веб-страница в виде кода а браузер нам ее читает и отрисовывает в котором мы видим вот хорошо Как ты думаешь Вот что нам важно тестировать если у нас веб-приложение то есть ты приходишь Да там на
00:52:34 - 00:54:27
собеседование тебе говорят у нас сайт как бы ты протестировал его вот может быть какие бы виды тестирования ты применил бы в первую очередь на что ты обратил внимание [музыка] а как разные платформы влияют на веб-приложения то есть допустим как у нас это приложение будет отрисовываться в телефоне то есть мы можем посмотреть браузера зависит как-нибудь отрисовывать нет а то есть да у нас же браузер один будет То есть можно за уши притащить кроссплатформы в том виде что на разных телефонов разный размер экрана Но вот
00:53:50 - 00:55:12
это только и вот максимум То есть это верстка проверяется но как бы более правильно ответ что от платформы в это не зависит он зависит от реализации браузера от типа браузера Вот от этого в этом-то его и суть сильного отличает вот еще нам важно на отказ восстановления Как реагирует в том плане как она реагирует на отлом интернета либо много можно трафик можно полностью отключить потому что на самом деле вот в реальной жизни ты увидишь Если тебе придется тестировать приложение что разработчики очень часто забывают как-то
00:54:57 - 00:56:09
обрабатывать правильно отлом интернета и на это следует обращать большое внимание хорошо поговорим про нативные приложения нативные о чем нативная так но это мобильное приложение допустим она Ну практически не требует интернета может работать без интернета Может подгружать просто какие-то обновленные данные очень очень опасно опасная формулировки Смотри ты говоришь может работать может не работать нет технически Она работает без подключения к интернету интернет нужен для того чтобы подгружать какую-то информацию не
00:55:36 - 00:57:01
логику приложения а допустим какой-то контент с которыми он работает важный момент Если отключить интернет нативного приложения оно будет жить но допустим если это приложение суть его заключается в том чтобы там фоточки подгружать да и фоточки подгружаться не будут свежих фоточек в нем не будет теряется бизнес смысл приложения но оно работает а веб-приложение если мы включим интернет он не работает в принципе это вот это важно а есть нативное приложение которое в принципе не нужен интернет чистый язык даже бизнес смысл например
00:56:19 - 00:57:28
фонарик вот у тебя на мобильном устройстве приложу фонарик или калькулятор калькулятор фонарик ничего сервера не подгружают Вот это самый настоящий нативные приложения и еще ты сказал опасную вещь Ты сказала что это относится к мобилкам доступные приложения тоже называют нативными то есть приложение которое устанавливается на твой компьютер они тоже они просто раньше когда было больше компьютеров меньше смартфонов это называлось достал приложение сейчас это называют нативными Но это типа одно и то же просто
00:56:54 - 00:57:54
платформа чуть разные это это грань она постоянно размывается то есть iPhone становится все больше компьютер становится все меньше и все в принципе приходит к одному как бы знаменателю и принципе у них одинаковые как относится к интернету обсудили в чем еще особенность Тестируем также реконнектом установку обновление удаления тестирование подходит так так но опять же троттлин трафика прерывание Ну трафик может только что обсудили он особо нам не важен потому что само приложение работает без контента вот мы можем проверить но это
00:57:24 - 00:58:44
не Ключевое А вот кросс Какое платформенное рост платформенная Правильно Потому что зависит от мощности железа который установлена так возможно еще на портретную альбомную ориентацию если поддерживается я типа секрету скажу сейчас большинство вендоров просто отключает это возможность и поэтому не так уж много современных приложений поворачивается именно чтобы не фиксить вот эти баги раньше было модно чтобы в двух измерениях было сейчас просто отключает эту функцию Ты хоть как Поверни она все равно будет в своем
00:58:11 - 00:59:24
прежнем этом это нормально два раза меньше работы делают Хорошо Окей так и гибридные тогда расскажи в чем там суть это совокупность найти приложение то есть она также включать установку удаления обновления то есть инсталляцию то есть также мы можем применить кроссплатформенное тестирование так В целом все виды которым там применим из Веба установка требуется правильно подключение к интернету требуется что еще также производительность посмотрим локализация логика приложение где находится на севере или на клиенте
00:58:48 - 01:00:31
Нужно ли нам разрешение пользователя для обновления тонкий момент по моему не нужно разрешение пользователя обновление так Ну да нужно потому что она же может быть без интернета работать Да все правильно все правильно то есть в нативных нам нужно спрашивать пользователя о гибридных Мы же сами только что сказали что основная логика находится на сервере Поэтому в большинстве случаев мы можем на сервере как в приложениях поменять что хотим точка входа останется той же это так называемый тонкий клиент понятия потому
01:00:04 - 01:01:11
что на самом деле в гибридном приложении в том виде в котором мы сейчас его обсуждаем нативная часть она маленькая То есть это не 50 на 50 А может быть даже 10 процентов на 90 и вот это нативной части это так называемый тонкий клиент точка входа ярлычок в приложении какие-то базовые вещи основная вся логика все происходит на сервере мы можем там менять легко и так далее хорошо Да еще что главное про гибридные помнить что на самом деле с гибридными есть проблема в том как мы понимаем Как выглядит гибридное приложение Дело в том
01:00:49 - 01:02:04
что на самом деле у слова гибрид есть несколько разных технических реализаций и вот помимо того что мы только что назвали Да вида приложения выбью applications так называемый то что мы сейчас тонкий клиент часть бывает например еще гибридный фреймворк например гибридный фреймворк Самарин где приложение пишется на сей шарпе а на выходе получается вроде как iOS Android приложение одновременно магия бывает еще всякий подходы но имеет Самое широкое распространение подавляющее поэтому на реальном собеседовании Лучше там говорить что
01:01:36 - 01:02:59
есть Разный подход к понятию гибридных приложений я расскажу про самые как я понимаю часто используем Потому что есть шанс что допустим человек который слушает гибридный расскажешь он может быть даже не знает про них и удивиться и такой рассказываешь не то поэтому тут нужно в аккураточку хорошо и поговорим про методологии немножко да то есть какие-то знаешь методологии разработки как они устроены есть гибкая есть гибкая методология это аджайл это у нас включается тебя скрам Канбан Что такое Но это некий набор правил по которым
01:02:17 - 01:03:58
должен разобраться продукт хорошо также есть водопады хорошо вот у нас набор правил в него входит методологии [музыка] Что такое в чем его суть отличительные разработка по спринта то есть разрабатываем по определенному времени какой-то функционал также включает в себя а если поэтапно То есть это планирование ежедневные митинги в конце хорошо так но сам непосредственно сама разработка со Sprint в процессе ежедневной митинги в конце перспективы то есть мы обсуждаем то мы скинем проблем что мы могли улучшить в следующем
01:03:17 - 01:05:25
и собственно релиз хорошо она планирование что мы делаем то есть мы Возможно мы обсуждаем то за сколько мы сделаем наш продукт возможно времени мы распределяем по участникам команды время За сколько мы сделаем У нас одно всегда для нас принта там две недели три недели месяц но конкретно мы что делаем первое мы выбираем задачи которые будем делать У нас есть Вот и мы из баклага проектов всего Да все задачи которые мы предполагаем в проекте берем задачи в backlock спринта то есть конкретно вот в эти вот этот
01:04:42 - 01:06:09
отрезок и это как раз таки происходит на планирование И помимо того что мы выбираем сами задачи мы что делаем оцениваем оцениваем каждую задачу и Стараемся сделать так чтобы мы были равномерно загружены говорят менеджеры чтобы у нас хватило задач чтобы не дай бог не простаивали не Пошли пить чай но и в то же время чтобы мы успели сделать все что мы взяли вот соответственно мы как тестировщики мы иногда участвуем в этом проекте иногда нет бывает всякое Вот Но тем не менее хорошо хорошо вот есть у нас там какой-нибудь водопад
01:05:34 - 01:06:53
до waterful вот в нем в чем суть Чем отличается отжала получается модель разработки которая такая так скажем более строгая у ней происходит разработка требований устоялась мы делаем разработку самого проекта потом тестировано все делается поэтапно без изменений предыдущего этапа так скажем лучше по-другому говорить лучше говорить Так что в водопаде отсутствуют или затруднена обратная связь между этапами разработками на обратная связь то есть у нас есть те же по сути этапы как мы будем делать потом у нас
01:06:24 - 01:07:53
имплементация идет документации потом программисты работы потом тестировщики Но в отличие от того допустим скрам скрам процесс когда мы находимся в середине пути нет такого что допустим вот сейчас Значит мы одновременно и документацию Тестируем разработчики что-то уже пишут А мы там статическое тестирование проводим Нет там пока к тебе задача не спустилась сидишь потом тебе задачу спустилась ты работаешь потом ты протестировал Пошло все дальше и из-за этого определенная особенности есть вот этих ватерфолл проектов
01:07:16 - 01:08:38
особенности Какие этапы изолированы и поток только сверху вниз идет это не можешь там влезть посередине и что-то сделать Как изменить процесс они применяется для таких серьезных так скажем проектов как Почему медицинская оборудование Почему Потому что цена ошибки с краями не может быть не будет такой высокой допустим как в построении аппараты МРТ значит что значит у нас чаще будут баги в храме возможно Почему потому что у нас [музыка] крайне могут быть чаще такой модный процесс модно молодежно все
01:07:58 - 01:09:39
там придумали что все Шустро делалось а у нас больше багов как же так но так скажем применяем к проектам не такого серьезного масштаба как почему Почему мы ракеты по скрам не делаем потому что именно вот эта Суть аджайла в том что все гибко и то что может в любой момент что-то изменяться она вносит определенную сумятицу неразбериху в проект То есть когда вы сидите у вас среди нас принта подлетает менеджер говорит так я только что пил вино с клиентом он говорит ему вообще не нравится что мы делаем Короче у нас есть
01:09:01 - 01:10:29
пол спринта чтобы все исправить бросаем что мы делаем сейчас это в быклок это избы клоу так все шуры-муры Давайте до конца недели осталось вперед разработчики сделают Ты может быть даже успеешь протестировать если повезет и может быть даже заказчик будет доволен Вот потому что для него это важно но итоговая реализация вот будет намного более Забавно чем если вас никто не трогал Ну и перемешается все да да Вот то есть ты шел по плану там у тебя было в голове там вот сейчас мы документацию потом это
01:09:50 - 01:10:56
бомбах все это так переворачивается вы с этим справитесь но на выходе шанс что будет бак потом и пропущен и вправду пойдет намного выше А ватерфоле из-за того что медленно все размеренно постепенно по этапам Никто никого не трогает никто никого там за голову не трясет за плечи когда человек сидит работает все более размеренно там получается так что сам процесс разработки дольше и на выходе Может в рынок хуже вписываться Но при этом будет намного стабильнее качественнее более консервативный такой
01:10:24 - 01:11:30
подход так скажем и поэтому если разрабатывается что-то Что требует больших финансовых вложений там создание этой ракеты или робота там никто не торопится потому что там рынок не такой конкурент а когда хотят создать быстрый интернет-магазин который продает какой-нибудь новую хрень новомодную там фиджет спиннеры какие-нибудь или там у госапоги там каким-то или еще что-нибудь модной там футболки с каким с принтом принтом Им не нужно год этим заниматься у них есть месяц Чтобы успеть ворваться в тренд а рынок да да успеть за рынком
01:10:57 - 01:12:06
Чтобы успеть за рынком надо делать быстро и пусть даже с багами Ну потому что если в интернет-магазин глюка Нет никто не умрёт А с ракета упадёт то может умереть Вот почему мы говорим Да что где-то там канает работает Хотя постепенно некоторые даже крупные компании переходят более мелким вот этим инкрементом например вот Windows раньше менялся раз несколько лет большим обновлением Теперь ты хочешь выключить Нет братан Мы сначала обновимся потому что сегодня залили в меня какого-то потом ты выключишься это может
01:11:32 - 01:12:36
происходить раз в неделю раз три а раньше это происходило огромными сервисами раз в несколько лет То есть даже вот разработка таких сложных вещей она больше идет со временем сужаются темпы разработки и маленькими кусочками она пропихивается вместо одних больших кусков хорошо супер принципе мне понравилось как Мы пообщались там можно какие-то еще Вопросы задать Ну я думаю и так хорошо значит смотри что тебе нужно подтянуть нужно будет по поводу ящиков Повторите белые свежие черный ящик да чем не отличается почётче
01:12:08 - 01:13:36
Что значит это для того Это для того Это для того значит мы Тестируем бизнес требования тут мы значит Тестируем код так в уровнях там про этот самый про приёмочная что у нас есть ацетон техники дизайна в принципе хорошо про эти вспомнить про жизнь цикл баг-репорта Что происходит если разработчик сразу отказывается дубликат ноты бак родился Ну и про принцип работы приложения видов тестирования тоже советую почитать не просто это также это не так же вот прям четко я тебе рекомендую Как смотреть критерии выписать типа
01:12:52 - 01:14:14
подключение интернета необходимость да нет да потом Нужно ли разрешение на обновление это же каждому виду Опа И вот такую себе табличку нарисовать и четко по этой табличке про каждый вид будет тебе проще запоминать или там даже как шпаргалку все положить там на всякий случай и уже от этой табличке можно будет и во-первых рассказать как они работают а во-вторых по ней сориентироваться Какие виды тестирования можно применить Ну и в принципе все на реальном собесе тебя еще могут спросить про Континенте
01:13:57 - 01:15:03
integration может посчитаешь что это такое Но обычно глубоко не копают Вот и в принципе все ну если занудный попадется собеседующий он начнет докапываться запросах ответа глубже мы прошли а он может спросить допустим о чем разница между пост и геям разница между этими вот такие вещи я думаю не нужно вот не спросить но такое бывает вот в принципе мои замечания Так я считаю что хорошо подготовленный вполне можно реально собеседование даже с этими знаниями Да в целом Нет все слабые стороны я для себя подчеркну будем работать дальше
01:14:32 - 01:16:07
супер Хорошо тогда если что пиши в личку с вопросом можешь на бусте подписаться хочешь не там это не отписывайся тогда Ну всё удачи на собесах Давай Спасибо большое Пока Ну как вам собеседование хочу отметить что ближе к концу когда собеседование перевалило за час Павел немножко поплыл и ему стало отвечать на вопросы несколько сложнее это очередной аргумент пользу того чтобы собеседование не затягивать и в принципе любой интервью Верт должен стараться ложиться в час потому что после этого времени
01:15:28 - 01:16:58
продуктивность общения несколько упадет подписывайтесь на канал переходите По ссылкам и записывайтесь на подобное интервью Если хотите со мной пообщаться пока
01:16:14 - 01:16:41