Comprehensive QA testing course from basics to job readiness, focusing on practical skills, market relevance, and mentoring support.
Key Takeaways
- Effective QA training requires practical, market-relevant knowledge and ongoing mentor support.
- Testing is a critical part of quality control but distinct from broader quality assurance processes.
- Mentors add value by providing personalized guidance and ensuring candidates are job-ready, beyond just teaching basics.
- QA roles are evolving, requiring programming skills and experience to meet current market demands.
- Both testers and developers share the ultimate goal of delivering a reliable, high-quality product.
What the video covers
- The course is designed by IT mentors who earn by successfully placing candidates in jobs and supporting them through probation.
- It balances practical knowledge with essential theory to prepare beginners for interviews and real work scenarios.
- QA demand is growing, with current expectations including basic Python programming and at least one year of experience.
- The course structure includes extensive chapters with time codes, practical assignments, and detailed homework analysis available to community members.
- Multiple speakers contribute to the course, each with their own style and contact info for personal communication.
- Mentors provide value beyond information, including diagnostics, psychological support, and market-relevant guidance.
- Testing is explained as a technical check to find defects, ensure quality, and reduce costs by early error detection.
- The course clarifies differences between testing, quality control, and quality assurance, emphasizing their roles in product quality.
- It compares the roles of testers and developers, highlighting their shared goal of delivering a quality product despite different focuses.
- Practical advice is given on handling real-world testing challenges, such as balancing urgent releases with quality assurance.
Full Transcript — Download SRT & Markdown
Speaker A
Hello and welcome to one of the courses on conscious mercantilism and IT mentors. First of all, we need to understand why this course is worth watching until the end and paying full attention to, and how it differs from any other public courses. To do this, we need to understand who IT mentors are. They are a group of people who earn most of their profit from placing candidates in jobs and completing their probation period. That is, they don’t just throw some materials and say, "Come on, bro, study." They guide candidates through employment and then support them during the first days of work. This means that in this course, we tried to cover the most important topics for employment. We constantly remove unnecessary content from our materials, add relevant market questions, and try to keep the course on the edge where we don’t overload beginners with too much theory but provide practically applicable knowledge. This knowledge will be enough to pass interviews with all those tricky questions and successfully complete the probation period. Because, I remind you, if a candidate feels bad at work, they won’t get paid, will be fired, and then the mentor won’t get paid either. One of the most common requests to IT mentors is to get into IT through QA or testing. The demand for QA is indeed growing, but so are the requirements. In 2020, it was enough to know what a bug is, but now beginners are expected to know the basics of programming in Python and have at least a year of experience. Where to get this year of experience can be seen via the corresponding link. We have a separate guide. Well, this course is designed to help with the basics of testing and programming. It is also important for you to understand how this course is structured. It has several extensive chapters, each consisting of several parts. All of this is laid out in time codes for your convenience. We specifically decided not to split the course into many different videos so that at any moment you can return to an important chapter or re-listen to information you didn’t fully grasp. We will start completely from scratch for beginners and finish with testing practice. So, if you have already watched something, feel free to open the time codes and go to the sections that really interest you. After difficult theoretical parts, we immediately offer practical assignments to consolidate the theoretical material and apply it in practice. A detailed analysis of each homework assignment and an explanation of the correct answer are provided in a separate section available to members of the conscious mercantilism community. First, so that you don’t immediately know the correct answer and can think a little. And second, because there is really a lot of information that needs separate discussion, and the course would become too bulky otherwise. Within the course, you will meet several speakers. Well, because watching only my face for six hours straight would tire everyone. Each of them prepared their own chapter and material. So, if you like someone’s presentation style and want to communicate personally, read what is written under their videos. That is their Telegram nickname. You can contact them personally there. If you want to watch everything at once and not think about which parts you missed, go to Boosty. There you will find a ready text transcription of this entire guide. If you perceive text and pictures better than voice, that’s an option. I also want to explain why this course is publicly available if we supposedly have mentors who charge for training. The thing is, the main value of a mentor is not in the information. All the information is already available on the internet, in ChatGPT or other neural networks. You can get it there. The value of a mentor lies in diagnostics, in checking that you are truly ready to go to an interview, show a decent result, and then do your job. The value of a mentor is in psychological and moral support. The value of a mentor is that you can ask them any questions, unlike ChatGPT. But unlike ChatGPT, a mentor does not hallucinate or give you general answers. They always know what is currently relevant in the market and what is, in general, probably not worth learning. Mentors are not interested in teaching you the basics. You should go to a mentor when you have already passed the basics and don’t understand what to do next. It’s not obvious to you how to jump from "I know a lot" to "I work for money." So, it’s all logical. If you are not interested in mentoring, watch the course and get a job. We will only be glad. Testing is a technical check of the actual behavior of a program against the expected behavior. Its goal is to identify errors, ensure quality, and convey information to stakeholders. Why is testing needed before release? It helps save money. An error found at early stages costs much less. It allows checking compliance with requirements, gives a user’s perspective on the product, and helps find unplanned usage scenarios. Principles of testing: testing demonstrates the presence of defects but does not guarantee their absence. Exhaustive testing is impossible except in trivial cases. Early testing helps find defects as early as possible. Defect clustering: most errors are found in a limited number of modules. The pesticide paradox: repeating the same tests stops revealing new defects. Testing depends on the project context. For example, a banking service or a news portal. You will test differently. The misconception of no errors: the absence of found errors does not mean the product is ready. A QA specialist is paid not only for found bugs and defects but also for improving quality processes and minimizing reputational losses. But this is when one delivery app leaks all addresses into a public field, and now everyone knows what junk you order at 3:00 a.m. Also, for ensuring product stability and reliability. From the above, you might have noticed that there is bug hunting and product quality assurance. These are different tasks. The narrowest part of a tester’s job is testing, the process of finding errors. Quality control includes testing and also controlling the correction of found errors, that is, controlling the result. It focuses on the finished product. Quality assurance includes everything I mentioned but also involves organizing processes so that errors occur as rarely as possible and focuses on processes. Thus, testing is part of quality control, and quality control is part of the broader QA system. If it is still difficult to understand, just screenshot this table, hang it somewhere, keep it, and with practice, you will understand the differences. Now that we have delved a bit into the testing process, you can guess what role a tester plays in a development team. If it is still difficult to understand how QA differs from a developer, let’s again look at the goals, focus, and results of their work. But this time, compare an average developer and an average tester. We have prepared a table again, which you can return to and quickly refresh your memory when preparing for interviews. If you read carefully, it becomes clear that although the differences in focus, tools, and mindset are significant, the overall goal of both the developer and the tester is the same: to make a quality working product. Simply put, although the developer must primarily implement all customer requirements in the product, they cannot ignore possible risks. Likewise, the tester must identify any risks in advance but remember that the output should be a product needed by the customer. A practical situation: if your release is burning and some super important feature that everyone has long awaited is about to be released, you should not block...
Speaker A
такие IT-менторы. Это коллектив людей, которые получают большинство своей прибыли за трудоустройство и окончание испытательного срока кандидатам. То есть не просто кидает какие-то материалы и говорит: "Давай, братан, учись". А доводит до трудоустройства и потом сопровождает в первые дни работы. Это
Speaker A
означает, что в этом курсе мы попытались осветить самые важные для трудоустройства темы. Мы постоянно убираем из своих материалов что-то ненужное, добавляем актуальные вопросы с рынка и стараемся держать курс на той самой грани, где мы впихиваем в голову новичка не слишком много теории, но при
Speaker A
этом даём ему практически применимые знания, которых будет достаточно для того, чтобы пройти собеседование со всеми там мудрёнными каверзными вопросами и при этом успешно завершить испытательный срок. Потому что, напоминаю, если вдруг кандидат будет плохо себя чувствовать на работе, ему не
Speaker A
заплатят зарплату, уволят, и тогда ментор не получит денег. Один из самых частых запросов к IT-менторам - это вкат в IT через QA или через тестирование. Спрос на QA действительно растёт, но при этом растут и требования. В 2020 было достаточно
Speaker A
просто знать, что такое этот ваш баг, а сейчас от новичка ожидают основ программирования на Python и хотя бы года опыта. Откуда взять этот год опыта, можно посмотреть по соответствующей ссылке. У нас есть отдельный гайд. Ну а этот курс призван помочь с основами
Speaker A
тестирования и программирования. Тебе также важно понять, как устроен этот курс. В нём есть несколько обширных глав, каждый из которых состоит из нескольких частей. Всё это вынесены в тайм-коды для твоего удобства. Мы специально решили не разбивать курс на много разных видео, чтобы в любой момент
Speaker A
ты мог вернуться к важной главе или переслушать информацию, которую плохо усвоил. Мы начнём совсем со снов для новичков, а закончим уже практикой тестирования. Поэтому, если вдруг ты что-то уже посмотрел, смело открывай тайм-коды и переходи к тем разделам, которые тебя действительно интересуют.
Speaker A
После сложных теоретических частей мы сразу же предлагаем практическое задание для того, чтобы закрепить теоретический материал и применить его на практике.
Speaker A
Подробный разбор каждого домашнего задания и объяснение правильного ответа мы вынесли в отдельную часть, которая доступна участникам сообщества осознанной меркантильности. Во-первых, для того, чтобы ты сразу не знал правильный ответ и мог немножечко подумать. А, во-вторых, потому что там действительно много инфы, которую нужно
Speaker A
отдельно разбирать, и курс и без того раздуется. В рамках курса вы познакомитесь с несколькими спикерами.
Speaker A
Ну, потому что смотреть только на моё лицо 6 часов к ряду все бы устали.
Speaker A
Каждый из них сам готовил свою главу и материал. Поэтому, если вдруг чья-то подача тебе сымпонирует и с кем-то захочется пообщаться лично, читай, что написано под ними. Это их никнейм в Телеграме. Там с ними можно лично связаться. Если ты хочешь сразу смотреть
Speaker A
всё и не думать, какие там части пропущены, переходи на Бусте. Там уже готова текстовая расшифровка всего этого гайда. Если вдруг текст и картинки ты воспринимаешь лучше, чем голос. Также я хочу объяснить, почему этот курс лежит публично, если вроде бы у нас есть
Speaker A
какие-то менторы, которые берут деньги за обучение. Всё дело в том, что основная ценность ментора вовсе не в информации. Вся информация у нас и так уже лежит в интернете, в chatчат GPT или других любых нейронках. Можно получить её там. Ценность ментора как бы в
Speaker A
диагностике, в проверке того, что ты действительно готов пойти на собеседование, показать там достойный результат и после этого выполнять свою работу. Ценность ментора в психологической и моральной поддержке.
Speaker A
Ценность ментора в том, что в него, как в chatчат GPT, можно задавать любые вопросы. Только в отличие от чат GPT, ментор не галлюционирует и не выдаёт тебе общие ответы. Он всегда знает, что сейчас актуально на рынке, а чего учить,
Speaker A
в общем, наверное, и не стоит. Менторам не интересно преподавать тебе основы. К ментору пора идти тогда, когда эта основа пройдена и ты не понимаешь, [музыка] что нужно делать дальше. Тебе не очевидно, как прыгнуть от я "Я знаю много" к "Я работаю за деньги". Так что
Speaker A
всё логично. Если тебе менторство не интересно, смотри курс, устраивайся на работу. Мы будем только рады.
Speaker A
Тестирование - это техническая проверка соответствия фактического поведения программы ожидаемому. Его цель - выявить ошибки, убедиться в качестве и передать информацию стейкхолдерам. Зачем нужно тестирование до релиза? Помогает сэкономить деньги. Ошибка, найденная на ранних этапах, стоит гораздо дешевле.
Speaker A
Позволяет проверить соответствие требованиям, даёт взгляд на продукт со стороны пользователя, помогает найти незапланированные сценарии использования. Принципы тестирования: тестирование демонстрирует наличие дефектов, но не гарантирует их отсутствия. Исчерпывающее тестирование невозможно, за исключением тривиальных случаев. Раннее тестирование помогает найти дефекты как можно раньше.
Speaker A
Скопление дефектов. Большая часть ошибок находится в ограниченном количестве модулей. Парадокс пестицида: повторение одних и тех же тестов перестаёт выявлять новые дефекты. Тестирование зависит от контекста проекта. К примеру, банковский сервис или новостной портал. Вы будете тестировать по-разному. Заблуждение об
Speaker A
отсутствии ошибок. Отсутствие найденных ошибок не означает готовность продукта. Платят Qспециалисту не только за найденные баги и дефекты, но и за улучшение процессов качества, минимизацию репутационных потерь. Но это когда у одного приложения доставки все адреса сливаются в публичное поле, и
Speaker A
теперь все знают, какое хрючевого ты в 3:00 ночи заказываешь. И за обеспечение стабильности и надёжности продукта. Из сказанного выше ты мог заметить, что есть поиск багов, а есть обеспечение качества продукта. И это разные задачи.
Speaker A
Самая узкая часть работы тестировщика - это тестинг, тестирование непосредственно процесс поиска ошибок. Quality control включает в себя тестинг, а также контроль исправления найденных ошибок, то есть контроль результата.
Speaker A
Предполагает фокус на готовом продукте. Quality Assurance включает в себя всё, что я перечислил, но также подразумевает организацию процессов таким образом, чтобы ошибки возникали как можно реже и предполагает фокус на процессах. Таким образом, тестирование - это часть Quality Control, а Quality Control - это
Speaker A
часть более широкой системы QA. Если разобраться по-прежнему сложно, просто заскринь эту табличку, куда-нибудь её повесь, положи, с практикой придёт понимание различий.
Speaker A
Сейчас, когда мы уже немного погрузились в процесс тестирования, вы и сами можете догадаться, какую роль тестировщик занимает в команде разработки. Если разобраться в том, чем QA отличается от разработчика по-прежнему сложно, давайте снова посмотрим на цели, фокус и результаты работы. Но в этот раз сравним
Speaker A
среднестатистического разработчика и среднестатистического тестировщика. Мы снова подготовили табличку, к которой ты сможешь вернуться и быстро освежить всё в памяти, когда будешь готовиться к собеседованиям. Если вчитаться, становится понятно, что хотя различия между фокусом, инструментами и мышлением большие, глобально цель и разработчика,
Speaker A
и тестировщика одна: сделать качественный работающий продукт. Проще говоря, хотя разработчик и должен в первую очередь реализовать все требования заказчика в продукт, он не может закрывать глаза на возможные риски. Так и тестировщик, любые риски необходимо обозначать заранее, но при
Speaker A
этом помнить, что на выходе должен получиться продукт, необходимый заказчику. Ситуация из практики. Если вдруг у вас горит релиз и вот-вот должна выйти какая-то суперважная фича, которую все давным-давно ждут и вот-вот она уже на подходе, тебе не стоит блокировать
Speaker A
этот релиз из-за какого-то супер маленького бага, вроде чуть-чуть поехавшей вёрстки в каком-то дальнем-дальнем уголке продукта. Вы в первую очередь команда. Вы работаете над общим результатом. И этот маленький неважный баг можно обозначить, но не стоит настаивать на его исправлении
Speaker A
прямо сейчас. Лучше просто перенести его в следующий спринт и починить уже потом после вашего релиза. У разработчика и тестировщика разные инструменты, с которыми они работают на ежедневной основе. Но сейчас тестировщик вполне может заниматься вайб-кодингом, а разработчик не должен отдавать в релиз
Speaker A
продукт с очевидными багами. Грубо говоря, компетенции немножечко перемешиваются и перетекают из одной роли в другую. На просторах интернета тебе уже могло попасться видео QA не нужны. Это правда лишь отчасти. Экономия на тестировании редко приводит к действительно положительным результатам.
Speaker A
Тут можно вспомнить, что в 2024 году Google так спешили представить свою нейросеть Джемини, что подверглись серьёзному риску отмены из-за того, что их нейросеть генерировала изображения, не соответствующие культурным или историческим фактам. К примеру, портрет папы Римского женщины. В конечном итоге
Speaker A
Google пришлось временно ограничить доступ к функционалу генерации изображения, а также занять почётное место в рейтинге технологических провалов по версии Meet Technology Review. Теперь о роли тестировщика на каждом этапе разработки. Важно понимать, идеальная картина тестирования подразумевает участие тестировщика во
Speaker A
всех стадиях разработки продукта: от сбора требований до релиза и поддержки. Но это в идеальном мире. В реальности же всё может быть по-другому. Стадии могут отсутствовать, задачи размыты, а роли пересекаться. Поэтому эта схема скорее ориентир, а не строгий регламент. Кодекс
Speaker A
- это просто свод указаний, а не жёстких законов. >> В общем, не стоит чехвостить свою команду за то, что она всё ещё не идеальна. Для обучения мы представим идеальный вакуумный продукт, где всё идёт по плану. В жизни же вы будете
Speaker A
выстраивать эти процессы постепенно, отталкиваясь от вашей команды и уже сложившихся в ней процессов. Стадия требований, стадия разработки, стадия тестирования и интеграции, стадия релиза, пострелизная стадия. Иногда какой-то из блоков может полностью отсутствовать. Например, в проекте отсутствует стадия сбора требований или
Speaker A
не используется стандартная архитектура. Это нормально. В таких случаях тестировщик адаптирует подход, задаёт больше уточняющих вопросов, сам строит гипотезы, опирается на пользовательский сценарий. Суть в том, чтобы не ждать идеальных условий, не воротить нос, мол, эх, у нас как-то всё не идеально, а
Speaker A
уметь действовать в существующих реалиях. В теории всё выглядит красиво, но в реальной жизни не все этапы бывают формализованы. Иногда вам придётся действовать на ощупь, самим разбираться в логике работы системы, вытаскивать требования из диалогов и переписок или просто отталкиваться от здравого смысла.
Speaker A
И последнее о рутине QA. Чем придётся заниматься в течение рабочего дня. Типичные задачи тестировщика на день выглядят примерно так: отжумание, прескачать так, стоп. Планирование тестов, анализ новых задач и написание тест-кейсов к ним. Проведение ручного и автоматизированного тестирования. Анализ
Speaker A
результатов тестирования и фиксирование багов. Обсуждение ошибок с командой. разработка, продакты или внутренние заказчики, обновление документации и предложение улучшений. Ошибочно будет мечтать об идеальной работе тестировщика, где у тебя слева ожидаемый результат в табличке, справа реальный результат, помечаешь зелёненьким или
Speaker A
красненьким, если не совпадает, и уходишь домой. На самом деле, зачастую всего этого как бы нет. Тебе придётся собирать эти требования, понимать, это точно ожидаемое поведение или вот в таком вот кейсе мы ожидаем что-то другое. А какое поведение мы вообще
Speaker A
получили? А такое ли оно будет на других устройствах и в других обстоятельствах? Так, подождите. Мне сказали, что эта задача вообще должна выглядеть не так. А этот экран точно должен быть здесь. А как на этом экране оказаться? А почему
Speaker A
наша програм? Короче говоря, это коммуникация, системное мышление, понимание своего продукта и умение им пользоваться и ещё раз коммуникация, общение со всеми участниками команды, что, в общем, в конечном итоге и позволяет построить качественный продукт.
Speaker A
И последняя часть в этой главе - это методологии разработки. Обычно в больших и дорогих курсах по QA им уделяется совсем немного времени, но для успешного прохождения собеседований на текущем рынки и гладкой интеграции в команды вам необходимо разбираться в основных
Speaker A
методологиях разработки. Методология разработки - это подход к созданию продукта, которая определяет порядок выполнения задач, методы реализации, контроль, стоимость, сроки. Сильно упрощая методологию разработки - это карта маршрута команды от идеи до релиза продукта. От того, какая эта карта, зависит и роль тестировщика. Где-то он
Speaker A
подключается только на финальных этапах, а где-то проходит с командой через все стадии разработки продукта. Мы разберём две основных модели: Agile и Waterfall.
Speaker A
Agile - это гибкий подход, где работа делится на короткие циклы и легко адаптируется к изменениям. Многие компании используют Agile элементы в своей работе, например, Google, Dell Сбер. Основой Agile являются четыре ценности, заложенных в Agile манифесте.
Speaker A
Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласование условий контракта.
Speaker A
Готовность к изменениям важнее следование первоначальному плану. Можно представить, что команда идёт не по шоссе, а по тропинкам и на каждой развилке может менять направление, чтобы выбрать более удобный маршрут. Первый популярный подход внутри Agile - это Скрам. Он задаёт такие правила работы.
Speaker A
Работа делится на короткие спринты от одной до 4 недель. Проводятся регулярные встречи. Это планирование, ежедневный стендап или планёрка на 15 минут и ретро. Обсуждение итогов. Внутри Скрам есть определённые роли. Это владелец продукта, скраммастер и команда разработки. В конце каждого спринта
Speaker A
команда показывает результат, работающий кусочек продукта. Отходя от непривычных тебе терминов, можно представить это так. Команда садится вместе, решает, что сделает за следующие 2 недели. каждый день синхронизируется по вопросам и проблемам и в конце показывает результат и обсуждает, что можно улучшить в
Speaker A
следующем спринте. Другой подход - это к анбан. Его основная суть в визуализации процесса и в ограничении количества задач в работе. Вот главное, что нужно знать о канбан. Вместо спринтов непрерывный поток задач. У каждой задачи есть свой статус. Всё это отражено на
Speaker A
канбандоске, где задачи плавно переходят из одного статуса в другой. Например, надо сделать, в работе готово. Это похоже на список дел на холодильнике.
Speaker A
Написал купить молоко. Пока не сделал, не берёшься за следующую задачу, например, сходить в спортзал. Кабан доска в Джира выглядит, например, вот так. Обрати внимание, что добавилась ещё одна колонка на проверки. В целом количество статусов в этой доске не
Speaker A
ограничены, и у каждой команды они могут быть свои. Задачи здесь разделены по статусам. Их можно двигать из одной колонки в другую. Всё гибко и прозрачно.
Speaker A
Каждый участник команды в любой момент знает, в каком статусе другая задача. Главное отличие Jile от Waterfall, про который позже для QA инженера, тестирование - это не этап, а непрерывный процесс. Тестировщик подключается ещё на этапе сбора требований. На этом этапе никакого
Speaker A
продукта может ещё даже не существовать. Тестировщик пишет тесты и автотесты параллельно с процессом разработки.
Speaker A
Работает в связке с программистами и активно участвует в скрам-мероприятиях или обсуждениях с канбанкомандой. Например, уже через несколько дней после начала работы над задачей тестировщик может проверить результат, оперативно дать команде обратную связь и помочь исправить ошибки. К преимуществам отйлмы
Speaker A
можем отнести быструю реакцию на изменение системы, регулярные поставки работающего ПО, тесное сотрудничество с заказчиком, высокую мотивацию команды и раннее обнаружение проблем. К ограничениям можем отнести трудности с масштабированием в крупных организациях, высокие требования к вовлечённости всех участников, меньшее внимание
Speaker A
документации и сложность планирования долгосрочных проектов. Если - это маршрут с возможностью свернуть и поменять направление на более выгодное, тоfall - это движение строго по шоссе без поворотов. Каждый этап идёт строго за предыдущим. Сначала анализ, проектирование разработка тестирование, внедрение. Название
Speaker A
водопад отражает эту логику. Вода как бы стекает с этапа на этап и движется строго вниз к завершению продукта. Тефол особенно удобен там, где всё должно быть заранее известно, утверждено, спланировано и поставлена печать, например, в медицине, в госучреждениях, в оборонной промышленности и в
Speaker A
машиностроении. Исторически его использовали IBM и NASA для работы над крупными инженерными системами, но и сейчас он попрежнему актуален в строго регламентированных сферах. Для тестировщика в Waterfall важно понимать, что тестирование - это отдельный этап.
Speaker A
Пока разработка продукта не завершена, тестировать нечего. Преимущество здесь в чёткой последовательности работы и в контроле с исчерпывающей документацией.
Speaker A
Waterfall подходит там, где все требования к продукту заранее известны. Поэтому к ограничениям здесь относится то, что трудно что-то менять на поздних этапах. Пользователь видит результат разработки только в самом конце. И существует большой риск, что продукт к моменту его запуска устареет. Подведём
Speaker A
итог. Agile - это гибкость итерации, ранняя обратная связь. Waterfall - это предсказуемость контроль последовательность, но низкая гибкость.
Speaker A
Роль тестировщика зависит от выбранной модели работы. В Agile тестировщик подключается сразу и проделывает весь путь вместе с командой. Waterfall он подключается позже, потому что тестирование - это отдельный этап. И напоследок предлагаю тебе топ вопросов собеседований по основам тестирования и
Speaker A
методологии разработки, которые ты встретишь на 90% сабесов. Расскажите, что такое тестирование и какая у него цель? Подскажи, в чём разница между Quality Assurance, Quality Control и тестировщиком? Какие гибкие методологии бывают и в чём разница между ними? Какие особенности работы тестировщика в Скрам
Speaker A
и канбан? Кстати, в третьем вопросе тебя может ожидать подвох, потому что помимо уже известных основных методологий, от тебя могут ожидать знания по лин методологии, но про неё я расскажу уже отдельно в специальной приватной части на бусте, где мы подробно разберём эти
Speaker A
вопросы и добавим немножко полезной информации, которая поможет успешно пройти собеседование. Если тебе что-то осталось непонятным, напиши свой вопрос в комментариях, и мы откорректируем курс. Ну а если тебе было интересно и полезно поставь пожалуйста лайк напиши комментарий в поддержку и
Speaker A
подпишись на канал. У нас впереди ещё много образовательного контента, который ты не захочешь пропустить.
Speaker A
>> Как вы представляете себе айтишника? Когда человек со стороны представляет себе айтишника, [музыка] часто возникает образ человека в капюшоне, который одиноко сидит в тёмной комнате и что-то делает за компьютером. Иногда даже те, кто приходит на обучение, [музыка] имеют
Speaker A
такое же представление о тестировщиках, но реальность кардинально отличается. Современная работа в IT - это, прежде всего командная работа. Тестировщик - неотъемлемая часть этой [музыка] команды. И от того, как он взаимодействует с другими ролями, напрямую зависит качество конечного продукта, скорость разработки и общая
Speaker A
атмосфера в проекте. Сегодня мы максимально подробно разберём, кто есть кто в команде, как проходят все ключевые процессы с точки зрения QA, как правильно выстраивать личное общение и как превратиться из простого исполнителя в специалиста, который реально влияет на продукт. Это не просто теория, это
Speaker A
основа, без которой невозможно эффективно работать в любой IT-компании. Я Михаил Чумаков, известный так же как Cella, ментор в сфере тестирования и автотестирования. За 2 года я лично помог более 70 людям войти в IT-сферу или кратно вырасти в доходах. В текущее
Speaker A
время я работаю в одном из крупнейших банков и занимаю позицию тестировщика уровня Синьор с зарплатой, превышающей 400.000 руб. в месяц. Я прекрасно понимаю ваше состояние новичка, потому что сам когда-то стоял на этом перекрёстке, не знал, куда идти и с чего
Speaker A
начать. Сейчас я помогаю многим войти в профессию и буквально за руку веду к успеху.
Speaker A
Кто есть кто в команде? В любой продуктовой команде набор алей примерно одинаковый, хотя возможны вариации в зависимости от конкретного проекта и компании. Давайте последовательно разберём каждую роль и то, как тестировщик должен с ними взаимодействовать. Разработчики - это наши главные партнёры в работе. У нас
Speaker A
есть фронт-энд разработчики, отвечающие за то, что видят и с чем взаимодействует пользователь, то есть интерфейс, кнопки, формы. Есть эээнд разработчики, реализующие бизнес-логику, работу с базами данных и API. Существует стереотип, что тестировщики и разработчики постоянно конфликтуют, но на самом деле это наши самые главные
Speaker A
союзники. [музыка] Конкретные точки взаимодействия с разработчиками включают уточнение деталей по задаче, то есть как реализована та или иная [музыка] функция, понимание архитектурных решений, как устроен обмен данными между системами, а также знание технических ограничений, какие лимиты заложены в систему. Правильное взаимодействие с
Speaker A
разработчиками экономит время обеим сторонам и значительно повышает качество продукта. Следующие в цепочке - это аналитики. Это те, кто формирует требования к продукту. Мы не будем углубляться в различия между бизнес-аналитиками системными аналитиками и продуктовыми аналитиками.
Speaker A
Давайте возьмём базовое понимание. Главное понимать, что аналитик - это человек, который знает, что должна делать система с точки зрения бизнеса и пользователя. Итак, аналитик, с чем мы к нему приходим? Что он знает такого, без чего мы не обойдёмся? Мы приходим к
Speaker A
нему, если непонятно, как система должна реагировать на какой-то определённый сценарий, если не ясно, что именно должно показываться в случае ошибки, если есть сомнения в логике работы того или иного функционала, аналитик отвечает за качественно составленные требования, а они, в свою очередь, основа
Speaker A
качественного тестирования. И с ним тестировщик как уточняет требования к уже разрабатываемому функционалу, так и прорабатывает требования к той фиче, которая только находится на этапе составления требований, находит в них слабые места и способствует огромной экономии денег бизнесу на том, что в
Speaker A
будущем будет в разы меньше дефектов, которые стоили бы колоссальных средств из-за переделок на поздних стадиях разработки. Теперь поговорим о дизайнере. Дизайнер отвечает за то, как будет выглядеть и ощущаться наш продукт.
Speaker A
Представьте ситуацию. Мы тестируем форму для регистрации, но не до конца понимаем, что должно происходить при наведении курсора на кнопку, какой порядок шагов заложен в процессе заполнения, появятся ли подсказки при вводе данных или, например, должен ли выскакивать Popup с предупреждением,
Speaker A
если пользователь ввёл данные неверно. Все эти моменты мы уточняем у дизайнера с точки зрения визуализации и пользовательского опыта. И хотя на первый взгляд эти детали могут показаться мелкими, именно они [музыка] в совокупности формируют то впечатление, которое пользователь получает от
Speaker A
продукта. Тестировщик в этом взаимодействии [музыка] должен быть голосом пользователя внутри команды и обращать внимание на такие нюансы. Продукт-менеджер и проject-менеджер - это два разных человека. Прокт отвечает за продукт целиком, за цели, стратегию, метрики и приоритеты. Project-менеджер фокусируется на процессе, чтобы задачи
Speaker A
[музыка] двигались, сроки соблюдались и встречи проходили. Но часто в небольших командах эти роли совмещает один человек, и с ним тестировщик уже чаще всего обсуждает влияние багов на бизнес.
Speaker A
Например, если выпустим с этой ошибкой, пользователи не смогут оплатить и конверсия упадёт. А также приоритеты исправления. Например, этот баг критичный, его нужно чинить в первую очередь, а вот этот можно ставить в бэклогинг. Хотя первична критичность и приоритет в любом случае определяем мы
Speaker A
как технические специалисты, но финальное решение по срокам и рискам принимается совместно с менеджером. DevOps или системные инженеры - это специалисты, которые помогают с окружением. Тестовые сервера, CCD процессы, логи, конфигурации. Без них тестировщик быстро застрянет на [музыка] проблемах. Вроде сборка не
Speaker A
разворачивается или тестовый стенд не отвечает. Чтобы было понятно, сборка - это новая версия приложения, которую разработчики собрали и выложили на тестовый сервер. А стенд - это сам тестовый сервер, отдельная среда, [музыка] где мы проверяем продукт перед тем, как он попадёт к пользователям.
Speaker A
Если сборка не разворачивается, значит, приложение не удалось установить на стенд. А если стенд [музыка] не отвечает, это как если бы сайт вообще не открывался. Тестировать просто нечего.
Speaker A
Понимание этих базовых понятий и налаженное взаимодействие с Devops инженерами критически важны для эффективной работы тестировщика. Другие тестировщики, если их несколько в команде, важно правильно выстроить взаимодействие между тестировщиками.
Speaker A
Нужно разделять зоны ответственности, [музыка] чтобы не дублировать проверки и не спорить о документации. Наоборот, нужно уметь заменять друг друга в случае болезней или отпусков, делиться находками и методиками тестирования. В идеале тестировщики в команде должны быть не конкурентами, а партнёрами,
Speaker A
которые помогают друг другу, работают на общий результат. Тестировщик как режиссёр в театре, он не просто сверяет ожидаемый и фактический результат, а является одним из ключевых персон, знающих о каждой секунде постановки и вносящий в свой вклад в каждую [музыка]
Speaker A
сцену. Он взаимодействует с каждым и отвечает за конкретный результат в виде финального продукта. Для него главная цель не просто выпустить нечто работающее, чтобы это понравилось конечному потребителю, но как же организовывается вся работа в команде с таким количеством человек? В предыдущей
Speaker A
главе Антон уже вкратце рассказал о методологиях работы в IT. Сейчас возьмём одну из них за основу для детального разбора. Самая популярная на сегодняшний день методология - это скрам. Хотя принципы, которые мы разберём, применимы и к другим гибким методологиям
Speaker A
разработки. Скрам работа делится на короткие итерации, спринты. Обычно это период от 2 до 4 недель. Каждая итерация имеет чёткую цель, определённый набор задач и обязательный цикл встреч, планирование, ежедневные стендапы, груминг, ретроспективы и демонстрация результатов. Именно потому, что продуктовые команды чаще всего работают
Speaker A
по этой методологии, мы будем разбирать её как основной пример взаимодействия команды с акцентом на роль тестировщика в каждом процессе. Командные встречи начинаются с ежедневных, да или митингов. Это короткие пятнадцатиминутные [музыка] встречи, которые проходят каждое утро в одно и то
Speaker A
же время. Каждый участник команды, разработчик аналитик тестировщик рассказывает о трёх ключевых вещах. Что было сделано вчера, что планируется сделать сегодня и с какими проблемами или блокирующими факторами он столкнулся. [музыка] И в чём роль конкретно тестировщика в этом процессе.
Speaker A
Я не просто говорю, что тестирую фичу. Я задаю [музыка] себе три вопроса: что проверил вчера, что беру в работу сегодня? Что мне мешает для проведения тестирования? И отвечаю на них.
Speaker A
Например, вчера протестировал корзину, нашёл два бага, сегодня проверю оплату. Мешает то, что нет тестовых карт. Так команда сразу видит риски. Для тестировщика это возможность регулярно обозначать риски и держать команду в курсе процесса тестирования. Например, если фича ещё находится в разработке, но
Speaker A
вы уже понимаете, что [музыка] её тестирование займёт аж два полные дня. Об этом нужно сказать нали. Напоминаю, что тестирование Фичи X займёт 2 дня.
Speaker A
Если мы хотим успеть в срок, нужно, чтобы код был залит на тестовый стенд не позже среды. Таким образом, команда заранее понимает временные затраты и может соответствующим образом скорректировать планы, либо заложить это время и релизиться в конце спринта, либо
Speaker A
вообще не брать эту фичу в текущий спринт, понимая, что не успеют. Далее идут груминги. Встреча по уточнению и подготовке задач. Груминг в обычной жизни - это уход за внешним видом домашнего животного. И тут аналогично.
Speaker A
Мы наши задачи причёсываем, обсуждаем, определяем сложность и требуемые ресурсы на задачи. На этих встречах мы детально обсуждаем будущие [музыка] задачи и то, как мы будем их выполнять. Это та самая встреча, где тестировщик может и должен предлагать или спрашивать о сценариях,
Speaker A
которые изначально не учитывались в требованиях. Например, как повлияет это обновление на пользователей со старой версией EOS? Что будет, если пользователь введёт некорректные данные в это поле? Увидит ли пользователь подсказку при возникновении ошибки?
Speaker A
Будет ли предупреждающий Poup при попытке выйти без сохранения данных? Такие уточнения помогают команде заранее предусмотреть edge cases, так называемые кривые случаи и boundary values, так называемые граничные значения, которые часто пропускаются на этапе проектирования. Важно понимать, что подобные вопросы могут и должны задавать
Speaker A
все роли команды разработки, но тестировщик, как специалист по качеству, несёт особую ответственность за полноту этого анализа. Следующая ключевая встреча - планирование спринта. У нас есть ограниченное время, обычно 2-4 недели, и команде нужно определить, какие задачи попадут в работу в
Speaker A
следующей итерации. Мы оцениваем задачи по нескольким параметрам: бизнес-приоритетам загрузки разработчиков и, [музыка] что критически важно, по времени на тестирование.
Speaker A
Казалось бы, а тестировщик тут зачем? Ведь что там руководители решат, то и будем делать. Но нет, здесь присутствие тестировщика обязательно. Его главная задача - реалистично оценивать и обозначать [музыка] сроки проверки. Например, на задачу может уйти не один день, а 2-три из-за
Speaker A
сложности или необходимости проверки на разных платформах. Об этом нужно сказать сразу. В моей практике были ситуации, когда команда брала слишком много задач в спринт и не успевала с тестированием или бизнес добавлял новые задачи прямо посреди спринта. Если тестировщик молчит
Speaker A
о своих временных затратах, это почти гарантированно приводит к срыву сроков, выгоранию и ухудшению атмосферы в команде. Ретроспектива - это встреча обратной связи внутри команды, направленная исключительно на улучшение рабочих процессов [музыка] и взаимодействия. На ретро мы обсуждаем, что в прошедшем спринте получилось
Speaker A
хорошо, что можно улучшить, что совсем не сработало и какие конкретные шаги мы можем предпринять для улучшения в следующем спринте. Эта встреча не о продукте и не о пользователях, она о внутренних процессах команды. Её можно сравнить с групповым сеансом
Speaker A
психотерапии, где все обсуждают свои боли и желания. Для тестировщика это возможность поднять вопросы, связанные с качеством процессов. [музыка] Например, нам не хватает тестовых данных для полноценной проверки или бэкрепорты часто возвращаются из-за недостаточной информации, или мы начинаем тестирование слишком поздно. Конструктивная обратная
Speaker A
связь на ретроспективе - это мощный инструмент для постепенного, но постоянного улучшения качество работы всей команды. И, [музыка] наконец, демонстрация. Финальное мероприятие спринта, где команда показывает стейкхолдерам, то есть заинтересованным сторонам со стороны [музыка] бизнеса, результат работ. Обычно демо проводит
Speaker A
продукт owner или один из разработчиков, но я настоятельно рекомендую тестировщикам периодически брать на себя эту [музыка] функцию. Демо - это презентация блюда гостям. Почему тестировщику вообще полезно проводить демо? Потому что мы знаем все ингредиенты, каждый баг, каждую особенность. Мы можем показать не только
Speaker A
что сделали, но и как это работает, на что обратить внимание. Проведение демонстрации - это отличный опыт, который позволяет тестировщику показать свою экспертизу, [музыка] продемонстрировать понимание продукта в целом и той ценности, который получили пользователи. Именно на демо наглядно видим, совпадает ли то, что мы
Speaker A
планировали сделать в начале спринта с тем, что получилось в итоге. Для тестировщика, который проводит [музыка] демо, это также возможность мягко обозначить известные ограничения или особенности реализации, [музыка] которые стоит учитывать. Помимо запланированных встреч, у нас всегда есть индивидуальная коммуникация с членами команды. Это
Speaker A
может быть общение с разработчиком по поводу технических деталей реализации, уточнения бизнес-требований у аналитика или [музыка] обсуждения с дизайнером какого-то конкретного состояния интерфейса. Индивидуальное взаимодействие часто оказывается гораздо эффективнее формальных процессов. Это можно сравнить со строительством дома.
Speaker A
Что эффективнее? обсуждать конкретный вопрос личность с тем, чьей зоной ответственности является вопрос или обсуждать детали установки ванной на общей встрече, где и мастера по натяжным потолкам, и установщики [музыка] окон, и сборщики кухни. Также не стоит забывать, что гораздо быстрее созвониться на 5
Speaker A
минут и обсудить вопрос голосом, чем тратить полчаса на переписку в чате. Или когда нужно показать разработчику странное поведение системы, проще показать экран и сразу продемонстрировать проблему, чем пытаться описать её словами. Все мы понимаем текущие общественные тренды на минимальное количество голосовой
Speaker A
коммуникации. Однако иногда всё же созвонится это лучший способ быстро и качественно решить проблему. В моей практике был показательный случай.
Speaker A
Тестировщик потратил почти 3 часа на составление детального бакрепорта шагами воспроизведения и скриншотами, [музыка] в то время как пятиминутный звонок с демонстрацией экрана позволил бы разработчику сразу понять суть проблемы и начать её исправлять. Поэтому индивидуальное взаимодействие [музыка] - это не просто дополнение к основным
Speaker A
процессам, а нормальная и важная часть работы современного тестировщика. Главное здесь не стесняться, писать другим членам команды и задавать вопросы. Лучше задать глупый вопрос сейчас, чем потом разбираться с последствиями недопонимания. Это экономит время всей команды, помогает [музыка] быстрее двигаться к
Speaker A
качественному результату. Частые вопросы и ситуации на собеседовании. Давайте подробно разберём частые [музыка] вопросы, которые действительно задают на собеседованиях на позиции QA инженеров. Эти вопросы направлены не только на проверку технических знаний, но и на понимание вашего подхода к работе, умения работать
Speaker A
в команде и способности действовать в сложных рабочих ситуациях. Первый классический вопрос: что вы будете делать, если задача пришла на тестирование в пятницу вечером, а релиз запланирован на утро понедельник? Этот вопрос проверяет ваше умение расставлять приоритеты, [музыка] оценивать риски.
Speaker A
Что самое важное - грамотно коммуницировать в стрессовой ситуации. Неправильный ответ - начать паниковать, пытаться ускориться, сделать всё быстро в ущерб качеств, либо [музыка] согласиться работать все выходные без возражений. Правильная стратегия выглядит так. Сначала вы спокойно оцениваете объём работы и её сложность.
Speaker A
Затем вы идёте к менеджеру или тимледу и чётко озвучиваете ситуацию. Я получил задачу на тестирование. Основные сценарии я могу проверить сегодня, но полноценное тестирование с проверкой всех кейсов, включая краевые случаи, а также регресс, занимает x часов или дней. Я могу сделать базовую проверку
Speaker A
сегодня, но полное тестирование будет возможно только в понедельник. Далее вы вместе анализируете риски. Если мы выпустим релиз без полного тестирования, возможны следующие проблемы А, B и C. Я рекомендую перенести релиз или выпускать с пониманием этих рисков. Также необходимо перечислить вариант решения
Speaker A
проблемы путём ускорения тестирования. такие как привлечь к задаче тестировщиков из своей команды, привлечь тестировщиков из соседних команд, сократить количество проверок, убрав низкоприоритетные и негативные сценарии.
Speaker A
Такой подход показывает вас как профессионала, который умеет управлять ожиданиями и не боится говорить о проблемах открыто. Второй частый вопрос: что делать, если требований к задаче почти нет? Или они очень расплывчатые?
Speaker A
Этот вопрос проверяет вашу проактивность и умение работать в условиях неопределённости. Худший ответ, который можно дать - это сказать, что вы будете ждать, пока требования появятся, или начнёте тестировать, что попало.
Speaker A
Правильный ответ строится по следующему алгоритму. Сначала вы фиксируете факт отсутствия требований в комментариях к задачам. Затем вы начинаете активно собирать информацию. Общайтесь с аналитиком, уточняйте бизнесу-логику, обращайтесь к разработчикам за пониманием технической реализации, дизайнеру за деталями интерфейса.
Speaker A
Параллельно вы начинаете делать исследовательское тестирование и сами формулировать предположения о том, как система должна работать, и выносите их на обсуждение команды. Например, поскольку требований нет, я предполагаю, что система должна работать следующим образом А, B и C. Подтвердите, пожалуйста, или поправьте мои
Speaker A
предположения. Часто такой подход помогает команде быстрее сформулировать требования. В своей практике я сталкивался с ситуацией, когда тестировщик 2 недели дал чётких требований, хотя мог за пару дней прояснить ключевые моменты и начать работу. Помните, лучше быть надоедливым тестировщиком, который задаёт [музыка]
Speaker A
много вопросов, чем потом разбираться с последствиями выпуска сурового функционала. Третий важный вопрос: как вы будете действовать, если разработчик настаивает, что найденный вами баг - это не баг, а фичар это проверка ваших коммуникативных навыков и умение разрешать конфликтные ситуации. Первое
Speaker A
правило - сохранять спокойствие и профессиональный подход. Не нужно спорить или доказывать свою правоту агрессивно. Вместо этого используйте технику трёх столпов. [музыка] Во-первых, обращайтесь к требованиям.
Speaker A
Если есть документация, покажите, где поведение системы отличается от описанного. Во-вторых, апеллируйте к пользовательскому опыту. Объясните, почему текущее поведение может запутать или разочаровать пользователя.
Speaker A
В-третьих, привлекайте третью [музыка] сторону. Аналитика как лицо, описавшее требования и понимающего, как это должно работать. Не стоит забывать, что разработчик - это ваш коллега, поэтому ваша задача - не победить в споре, а обеспечить наилучшее качество продукта и сохранение хороших взаимоотношений с
Speaker A
коллегами. Четвёртый распространённый вопрос. Опишите, как будете действовать, если обнаружили критический баг прямо перед релизом? Это ситуация, которая действительно часто происходит в реальной работе. Ваши действия должны быть чёткими и последовательными.
Speaker A
Во-первых, немедленно уведомить команду, написать в общий чат, подойти к менеджеру, далее оценить критичность и влияние бага. Что именно сломано? Для какого процента пользователей в конце предложить варианты решения проблемы?
Speaker A
Можно ли быстро исправить? Есть ли обходной путь? Нужно ли откладывать релиз? Самое главное - не скрывать проблему и не пытаться её решить в одиночку. Релиз с критическим багом - это ответственность всей команды, а не только тестировщика. Пятый вопрос,
Speaker A
который проверяет ваше понимание процессов. Как вы определяете, что тестирование завершено? и продукт можно выпускать. Этот вопрос выявляет ваш системный подход к работе. Хороший ответ включает несколько критериев. Все запланированные тесткейсы выполнены. Все найденные критичные и блокирующие баги исправлены и перепроверены. Выполнен
Speaker A
регресс и приёмочное тестирование, а также команда привела оценку рисков и приняла осознанное решение о выпуске.
Speaker A
Важно подчеркнуть, что решение о релизе принимается совместно всей командой, а не только тестировщиком. Вы предоставляете информацию о качестве, но окончательное решение - это зона ответственности продукт-менеджера с учётом бизнес-контекста. Подводя итоги всему сказанному, хочется подчеркнуть: взаимодействие с командой - это не
Speaker A
дополнительная нагрузка для тестировщика, а фундаментальная часть работы. Именно через грамотную коммуникацию формируются те процессы, от которых зависит скорость движения задач, количество багов, уходящих в продакшн, и в конечном счёте то, каким продукт увидят пользователя. Запомните три ключевых принципа успешного тестировщика
Speaker A
в команде. Первое - это проактивность. Не ждите проблем, предвосхищайте их. Второе - это прозрачность. Всегда держите команду в курсе статуса тестирования и возникающих рисков. И последнее - это партнёрство. Вы не полицейские качества, а полноценный партнёр разработчиков, аналитиков и
Speaker A
менеджеров создания лучшего продукта. Чем раньше вы поймёте эти принципы и начнёте применять их на практике, тем быстрее вы вырастете из начинающего тестировщика в ценного специалиста, без которого команда не представляет своей работы.
Speaker A
Давайте теперь подробно разберём жизненный цикл программного обеспечения. Это фундаментальное понятие, которое должен понимать каждый тестировщик.
Speaker A
Представьте, что мы строим дом. Сначала появляется идея, затем проект, потом строительство, сдача в эксплуатацию и дальнейшее обслуживание. Примерно так же работает и жизненный цикл программного обеспечения. Чтобы было понятнее, представьте, что мы создаём мобильное приложение для доставки Едре. назовём
Speaker A
его Cellлодоставка. На этом примере я покажу, какую роль играет тестировщик на каждом этапе разработки. Первый этап - анализ требований и планирования. На этом этапе бизнес-аналитики и продукт-менеджеры, а также заинтересованные стороны определяют, что именно должно делать программное обеспечение. Например, показывать
Speaker A
рестораны, добавлять блюда в корзину, принимать оплату и отслеживать доставку. Наша задача, как тестировщиков на этом этапе, задавать неудобные вопросы. А что, если ресторан внезапно закроется? А если оплата пройдёт, но заказ не создастся и так далее. Эти вопросы позволяют выявить потенциальные риски и
Speaker A
предотвратить их на стадии проектирования. Здесь формируется бизнес и технические требования, а также определяются сроки и бюджет. Важно отметить, что участие тестировщика на этом этапе критически важно. Как инженер по обеспечению качества, мы смотрим на требования глазами пользователя ищем слабые места. Лучше найти противоречия в
Speaker A
требованиях сейчас, чем переделывать функциональность потом. Следующий этап - проектирования архитектуры. Разработчики и архитекторы решают, как будет устроена система, какие будут модули, как они будут взаимодействовать, какие технологии использовать. Создаётся техническое задание, проектируются базы данных интерфейсы программирования приложений, а также пользовательские
Speaker A
интерфейсы. Разработчики решают, как будет устроена система, какие сервисы будут отвечать за заказы, какие заплатежи, как они будут общаться между собой. Здесь мы уже думаем о том, как будем тестировать взаимодействие этих сервисов, где могут возникнуть проблемы, как система поведёт себя при сбоях. Как
Speaker A
думаете, это тот самый момент, когда тестировщик спокойно похлёбывает своей смузи, потому что ему здесь нечего делать и вправду. Что же делать инженеру по обеспечению качества на этом этапе?
Speaker A
На самом деле для тестировщика это время начать готовить тестовую документацию, а именно стратегию тестирования и тест-план. Мы думаем о том, как будем проверять систему, какие сыряды тестирования нам понадобятся, какие инструменты мы будем использовать.
Speaker A
Во-первых, мы задаём вопросы о надёжности системы. Например, что произойдёт, если сервис ресторанов вдруг станет [музыка] недоступен? Как поведёт себя приложение, если платёжный шлюз будет отвечать с задержкой? Мы смотрим на систему не тогда, когда она работает идеально, а тогда, когда что-то
Speaker A
ломается. Во-вторых, мы анализируем точки взаимодействия между компонентами. В нашем приложении Cellella доставка есть сервис заказов. сервис ресторанов, платёжный сервис и сервис доставки. Мы спрашиваем: "А как они общаются? Что будет, если сообщение между сервисами потеряется? Как обеспечивается согласованность данных?" В-третьих, мы
Speaker A
думаем о [музыка] тестируемости архитектуры. Например, можно ли легко имитировать различные состояния системы? Можно ли изолированно тестировать отдельные компоненты? Есть ли возможность подменять реальные сервисы на тестовые заглушки? Третий этап - разработка. Программисты пишут код, создают функциональность согласно требованиям. На этом этапе тестировщики
Speaker A
уже активно работают, создают тестовые сценарии, готовят тестовые данные, начинают проводить первые проверки. Первое, что мы делаем - это пишем тесты параллельно с разработкой. Пока программисты создают функциональность для корзины товаров, мы уже пишем тесты для API этого модуля. Мы не ждём,
Speaker A
[музыка] пока всё будет готово. Мы работаем вместе с разработчиками. Например, разработчик создаёт метод добавления товара в корзину. Мы сразу же пишем тесты, которые проверяют эту функциональность. то есть добавление одного или нескольких товаров в корзину, добавление закончившегося на складе
Speaker A
товара в корзину и так далее. Также разрабатываем наши тестовые данные, настраиваем наше тестовое окружение, продумываем все тестовые сценарии, потому что требования нам уже известны, и на следующий этап нам надо оставить только выполнение самого тестирования.
Speaker A
Четвёртый этап - тестирование - это наша основная фаза. Но важно понимать, что тестирование происходит не только на этом этапе. Мы проверяем постоянно и требования, и дизайн, и код. На этом этапе мы проводим комплексную проверку: функциональное тестирование, интеграционное нагрузочное
Speaker A
тестирование безопасности и так далее. Я проверяю не только выполняет ли система свои основные функции, но и исключает ли она негативные сценарии. Например, попробую заказать доставку на несуществующий адрес, оплачу несуществующие карты заказ, закажу роллы, убрав из них все ингредиенты.
Speaker A
Пятое - это внедрение и развёртывание. Когда продукт прошёл все проверки, его выпускают для пользователей. Это может быть постепенное внедрение, пробные релизы или полномасштабный запуск. Мы не просто наблюдаем, мы активно мониторим десятки тысяч показателей. Вот практический пример для cстелодоставка.
Speaker A
После выпуска новой версии мы отслеживаем количество успешных заказов в час, процент отказов платёжной системы, время отклика серверов, количество ошибок в логах, а также отзывы в App Store и Google Play. Мы настроили систему алёртов, которая мгновенно сообщает нам, если какие-то
Speaker A
метрики выходят за допустимые пределы, например, если процент неуспешных платежей превышает 3%, мы получаем уведомления и сразу начинаем разбираться. Особое внимание мы уделяем мониторингу бизнес-показателей.
Speaker A
Технические метрики могут [музыка] быть в норме, если конверсия заказов упала - это серьёзный сигнал. Возможно, мы случайно усложнили процесс оформления заказа или новая функция работает не так, как ожидали пользователи. Давайте рассмотрим примерный сценарий. Мы выпустили наше приложение Castellлодоставка. Технически всё
Speaker A
работает, как должно, но заметили, что количество оплат через СБП значительно ниже, [музыка] чем через карту. Хотя СБП - один из самых популярных методов на рынке. Это вызывает у нас вопросы, и мы начинаем анализировать поведение пользователя. В процессе анализа данных
Speaker A
мы понимаем, что, возможно, пользователи сталкиваются с дополнительными шагами при оплате через СБП. Мы обнаруживаем, что виной всему кнопка "Оплатить ПСБП", которая вынесена отдельно в корзину, а не предложена как один из вариантов на этапе оформление заказа, где ожидается удобный выбор способа оплаты. Это
Speaker A
разделение не было очевидным на этапе тестирования, поскольку в наших тестах мы не смогли учесть поведение пользователей в реальных условиях.
Speaker A
Например, как они воспринимают расположение кнопки и процесс выбора способа оплаты в реальных сценариях. [музыка] И, наконец, шестой этап.
Speaker A
Сопровождение и поддержка. Продукт живёт, его используют, находят новые ошибки, появляются новые требования. Команда выпускает обновление, исправляет недочёты, добавляет новый функционал.
Speaker A
Первое и самое важное, мы постоянно следим за тем, как ведёт себя приложение в реальных условиях. Мы отслеживаем ключевые показатели. Сколько заказов проходит успешно, нет ли проблем с оплатой, как быстро работает приложение.
Speaker A
Если какие-то показатели начинают ухудшаться, мы сразу это замечаем и начинаем разбираться. [музыка] Например, после обновления приложения мы заметили, что в Санкт-Петербурге резко вырос процент отменённых заказов. Мы начали расследование и обнаружили, что проблема в работе геолокации. Приложение неправильно определяло зону доставки для
Speaker A
некоторых [музыка] населённых пунктов. Мы быстро связались с разработчиками и уже через несколько часов выпустили экстренный фикс. Когда пользователи сообщают о проблемах, мы также начинаем расследование. Например, если [музыка] несколько пользователей жалуются, что не могут оплатить заказ, мы проверяем логи,
Speaker A
анализируем, нет ли проблем с конкретным банком или регионом, ищем закономерности. Как пример работы с обратной связью несколько пользователей написали, что им неудобно каждый раз вводить адрес доставки. Мы проанализировали статистику и увидели, что 90% пользователей заказывают с одних и тех же двух-трёх адресов. Мы
Speaker A
предложили добавить [музыка] функцию избранные адреса, и после её внедрения количество успешных заказов выросло на 15%. Важно понимать, что современные подходы к разработке сделали этот процесс более итеративным и непрерывным.
Speaker A
Мы не проходим эти этапы один раз линейно. Мы постоянно перемещаемся между ними, выпуская всё новые и новые версии продукта. Смузи Rраф намидальном придётся пить во время работы, а не вместо. На каждом этапе жизненного цикла разработки нам есть чем заняться и над
Speaker A
чем работать. Теперь давайте поговорим о жизненном цикле тестирования. [музыка] Это систематический процесс, который гарантирует, что тестирование проводится тщательно и последовательно. Давайте разберём его по этапам, основываясь на идеальном процессе тестирования. Первый этап - анализ требований. Мы глубоко погружаемся в документацию, чтобы понять
Speaker A
ожидаемое поведение системы. Мы изучаем технические [музыка] задания, пользовательские истории, рассматриваем макеты и буквально выпытываем у аналитиков все детали. Наша главная задача - найти противоречие неясности и проблемы в требованиях. Если у нас есть общая постановка задачи, мы вытаскиваем конкретные требования. Если есть
Speaker A
конкретные требования, анализируем их с разных сторон. Второй этап- планирование тестирования. Мы создаём план тестирования, который описывает объём, подход, ресурсы, график, критерии начала и окончания тестирования. Мы берём всё, что узнали, и отвечаем на вопросы: что мы будем тестировать, а что нет. Сколько
Speaker A
у нас времени? Кто будет тестировать? Какие браузеры и устройства нам нужны? Что мы будем считать успехом? Всё это мы собираем в наш план тестирования, по которому будем двигаться. Например, при планировании тестирования мы столкнулись с нехваткой времени. Релиз был через 3
Speaker A
недели, а протестировать нужно было огромное количество новых функций. Как стоит распланировать тестирование [музыка] в таком случае? Мы приняли решение 70% времени посвятить критическому функционалу, заказу, оплате [музыка] и доставке, 20% второстепенно функциям вроде фильтров в каталоге и 10%, [музыка] если останется время,
Speaker A
наименее критичной ленте новостей. Третий этап - проектирование тестов. Мы создаём тестовые случаи и тестовые сценарии на основе проанализированных требований. Когда план готов, мы начинаем придумывать конкретные проверки. Какие именно артефакты мы создаём, зависят от проекта и принятого на нём стиле ведения тестовой
Speaker A
документации. Для технически сложного проекта рекомендуется начать с диаграммы состояний и переходов, перейти к общему контрольному списку всех типовых проверок, а затем описывать тестовые случаи. В случае нашего приложения мы сначала спроектируем максимально подробную диаграмму состояний и переходов. Визуально упростив нашу
Speaker A
будущую работу и понимание самой системы, пропишем в ней все возможные этапы пользовательских сценариев. Что происходит на этапе авторизации, из какого окна в какое пользователю необходимо перейти для оформления заказа и как система реагирует на различные негативные кейсы. Когда есть прописанная
Speaker A
диаграмма, мы прописываем наши будущие тесты, уточняем требования. Если, например, заметили, что в требованиях не описана реакция системы на ввод несуществующего адреса. Четвёртый этап - подготовка тестового окружения. Мы настраиваем стенды, устанавливаем необходимое программное обеспечение, развёртываем тестовую версию приложения, разворачиваем последнюю версию
Speaker A
приложения, подготавливаем тестовые базы данных с нужными нам данными. Пятый этап- выполнение тестирования. Мы запускаем тестовые случаи, регистрируем результаты, выявляем и документируем дефекты. Мы берём наши контрольные списки и тестовые случаи и начинаем прогонять их на подготовленном окружении. Когда мы находим расхождение
Speaker A
с ожидаемым результатом, мы оформляем отчёт об ошибке. Мы не просто пишем: "Что-то сломалось", а локализуем проблему максимальным образом, вплоть до конкретных строк в локах. Хороший тестировщик в казах коллег - это тот, кто в своих отчётах об ошибках даёт
Speaker A
максимум информации и разработчику остаётся только исправить проблему. Шестой этап. Анализ результатов и отчётность. Мы подводим итоги и формируем отчёт о тестировании. Мы собираем всю статистику, сколько тестов прошло, сколько упало, сколько ошибок нашли, сколько из них уже исправили. В
Speaker A
отчёте используем принятые на проекте метрики. На реальном проекте это будет выглядеть так. На этапе анализа результатов мы увидели, что 80% багов связано с интеграцией между сервисами.
Speaker A
Мы предложили команде увеличить время на интеграционное тестирование и внедрить автотесты для API. В итоге это количество подобных ошибок сократилось на 60%. Важно понимать, что в современных гибких методологиях эти этапы не являются строго последовательными. В спринте мы можем параллельно работать над несколькими
Speaker A
этапами для разных задач. Например, для одной задачи можем анализировать требования, для другой уже выполнять тесты. Также хочу подчеркнуть, что тестирование - это не только поиск ошибок. Это комплексная деятельность [музыка] по обеспечению качества, которое включает в себя профилактику дефектов
Speaker A
через раннее вовлечение в процесс, улучшение процессов разработки через обратную связь, помощь команде в понимании требований и обеспечения уверенности в качестве продукта перед выпуском. Каждый этап жизненного цикла тестирования важен и вносит свой вклад в конечное качество продукта. Пропуск или
Speaker A
некачественное выполнение любого из этапов может привести к тому, что в продукте останутся серьёзные дефекты.
Speaker A
Помните, хорошее тестирование - это не когда мы находим много ошибок, а когда мы помогаем команде создать продукт, в котором ошибок изначально мало. И жизненный цикл тестирования - это тот каркас, который помогает нам достигать этой цели системно и последовательно. И
Speaker A
напоследок, вот вам домашнее задание для лучшего усвоения темы. Давайте в качестве эксперимента представим ситуацию. Гигант найма nн, в котором ты являешься ведущим инженером, решил создать свой маркетплейс по продаже резюме и собственных чёрных списков для рекрутёров. Одни компании предлагают
Speaker A
свои рекрутерские базы и чёрные списки, вторые их покупают. Твоей задачей сейчас будет спланировать общий объём работ твоего QA отдела и дать вышестоящему руководству отчёт о предстоящей работе по каждому этапу жизненного цикла ПО.
Speaker A
Чем будет заниматься твой отдел? На каждый этап выдели один аспект, который требует особого внимания в связи со спецификой продукта. Например, для этапа сбора и анализа требований следует уделить внимание системе отзывов, потому что это площадка с разными продавцами.
Speaker A
Ну привет, неогранённые алмазы. Меня зовут Паша, и я уже почти семь добрых лет являюсь QA инженером. Поработал я и в маленьких стартапах, и в бигтехах, а последние года являюсь руководителем команд тестирования. Сегодня мы поговорим с вами на довольно обширную и
Speaker A
важную тему, иначе зачем про неё спрашивают на каждом собеседовании, а именно виды тестирования. Я почти уверен, что многие из вас уже заходили что-то почитать про виды тестирования и пугались этой огромной схемой с десятками видов. Если не пугались, то
Speaker A
заходите на первую же статью в поисковой выдаче и испугайтесь. Спешу вас успокоить. Не нужно на первых порах знать всё от а да я. К тому же тестирование - это область, которая зависит от контекста, и разные виды тестирования применяются в разных
Speaker A
командах. Да и тем более мы живём в динамичном мире IT, где всё часто меняется. Новые виды тестирования приходят, какие-то остаются с закрытой дверью.
Speaker A
Сейчас мы с вами разберём основные виды тестирования, которые чаще всего применяются в работе QA инженера. И начать, думаю, стоит с их иерархии.
Speaker A
Сначала всегда нужно выбрать, а как вообще вы будете тестировать функционал руками или с помощью автоматизации.
Speaker A
Поэтому первыми в иерархии идут ручное и автоматизированное тестирование. Ручное тестирование - это когда QA инженер выполняет работу вручную с использованием разного стороннего по, например, DEF Tools или Postm.
Speaker A
Автоматизированное же - это когда QA инженер обладает знанием какого-либо языка программирования, например, питоном или Java, и, конечно же, знанием фреймворков для тестирования, пишет код для проверки того или иного функционала.
Speaker A
Далее идут виды тестирования, которые проверяют то, как работает ваша программа. Это функциональное и нефункциональное тестирование.
Speaker A
Функциональная - это когда мы проверяем, что программа делает именно то, что от неё требуется. Например, приложение калькулятора должно выдавать правильный результат вычисления тех чисел, которые вы туда ввели. Нефункциональное же - это когда мы проверяем не сами функции, а
Speaker A
другие свойства программы. Например, может ли программа выдержать определённую нагрузку, удобно ли ей пользоваться, ну и безопасна ли она.
Speaker A
Например, существует задача сделать кружку, чтобы из неё можно было пить. Вроде бы задача выполнена с точки зрения функционального тестирования. Из кружки и правда можно пить, но с точки зрения удобства пользования это довольно-таки проблематично. Далее же идут виды тестирования, которые относятся к тем, о
Speaker A
которых мы поговорили ранее. У них тоже есть разные группировки. Сейчас мы поговорим отдельно про каждый. Начнём с видов тестирования, которые связаны с обновлением кода. Что же это такое?
Speaker A
Перед тем, как тестировщик начинает что-либо тестировать, разработчик пишет код и предоставляет его нам для проверки. Чтобы правильно подойти к этому процессу, существует дымовое, санитарное и регрессионное тестирование.
Speaker A
Первым делом всегда проводится санити тестирование. Это такой вид тестирования, который проводится обособленно для какой-либо доработки текущих функций программы, ну или исправления ошибки. Далее проводится домовое тестирование. Обычно оно проводится до регрессионного тестирования и после того, как доработки функций попадут на основную рабочую
Speaker A
среду, а именно место, где работают реальные пользователи. смог тестирование это базовая проверка критических модулей бизнеса е что-то критичное когда выкати фотки на где работаютровщики то смысла тратить время коей команды на регрессионное тестирование в целом нет к таким модулям могут относиться
Speaker A
регистрация авторизация или например загрузка данных на страницу или же наоборот на тестовой среде всё работало хорошо когда доработки попали на реальных пользователей вдруг появилась очень серьёзная ошибка тогда вы как QA должны сообщить об этом команде убрать эти функции использовательской среды и
Speaker A
разбираться с командой, в чём же дело. Регрессионное тестирование, наверное, самое объёмное из всех перечисленных видов. Регрессионное тестирование проводится, когда новые функции попали на среду для тестирования, то есть ту, где ещё нет реальных пользователей. И нам нужно проверить, что ключевые
Speaker A
бизнес-процессы не задеты и новый функционал работает так, как он задумывался. Обычно объём его меняется.
Speaker A
Это называется динамический регресс. Иными словами, чтобы составить список тест-кейсов для регресса, используются знания вами системы, выделяются модули, которые доработки могли задеть, и добавляются в прогон. Например, если произошла доработка в модуле доставки, то нужно проверить добавление товара в корзину и отображение данных в профиле
Speaker A
пользователя. Далее хотелось бы поговорить о видах тестирования, которые отличаются по уровню доступа к системе, а именно тестирование методом белого, серого и чёрного ящиков. Метод чёрного ящика - это тестирование без какого-либо знания системы. Иными словами, как будто работаете со стороны пользователя. Метод
Speaker A
серого - это когда тестирование выполняется с полным доступом к системе. Под системой я имею в виду и людей, и API, и базы данных, и код. Метод белого ящика в целом похож на метод серого.
Speaker A
Только разница в том, что при методе белого ящика вы умеете читать код и можете найти в нём проблему. Давайте разберёмся на примере. Есть у нас некоторая форма регистрации в беговое сообщество. Если проводить тестирование методом чёрного ящика, то я тут выступаю
Speaker A
как обычный паренёк, который заполняет поля, особо не зная, какие есть для них правила. Можно, конечно, поисследовать и повводить разные значения, но я никогда не буду уверен, что всё работает именно так, как задумал создать. Однако, смотря на эту форму, я могу найти недочёты,
Speaker A
которые создатель продукта не продумал в техническом задании. Если у серого ящика, то тут у меня уже есть документация, в которой я могу посмотреть, а правильные ли мне отображаются тексты ошибок, правильно ли поля реагируют на значения, которые я ввожу, и если что, я могу пойти и
Speaker A
уточнить вопросы у команды. Тестирование же белым ящиком позволит мне в случае, если я найду какую-то ошибку, пойти залезть в код, который написал разработчик, найти там проблему и прийти к нему с подробным её разбором. Виды тестирования связанные с уровнями
Speaker A
системы. Начнём с юнит или модульного тестирования. Это такой вид тестирования, когда проверяются отдельные модули или функции [музыка] системы. Этот вид тестирование в основном проводится разработчиками, так как проверяет написанный код. Если вспоминать наш пример с калькулятором, то это будет проверка не всего
Speaker A
приложения, а, например, только функцию сложения. В современных продуктах отдельные части системы часто взаимодействуют друг с другом. Это называется интеграции. Например, есть две разные части кофемашины. Одна засыпает кофе, другая, когда оно засыпано, начинает лить воду. Так вот, интеграция - это когда вы нажимаете
Speaker A
кнопку эспрессо, запускается процесс, который автоматически перемалывает кофе, насыпает его в чашу, заливает водой, и через пару секунд вы получаете готовый напиток. Интеграционное же тестирование - это такой вид тестирования, когда вы проверяете взаимодействие отдельных частей системы с целью убедиться, что
Speaker A
они работают именно так, как написано в документации. Системное тестирование - это когда проверяют всю программу целиком, [музыка] как она работает со всеми своими частями вместе. Есть очень похожее на него тестирование, и называется оно end тестирование. При Endль самые важные пути пользователя.
Speaker A
Возьмём, например, телефон. При системном тестировании мы будем смотреть, как работает камера, виджеты, зарядка, будильник и так далее. Когда приn мы проверим только главную функцию телефона, а именно разблокировать телефон, позвонить кому-то, услышать голос трубки и ответить ему. Мы все
Speaker A
знаем, что в мире существуют разные платформы, например, MacOS или Windows, или же разные браузеры, например, Opera или Google Chrome. Конечно, одно приложение может работать и там, и там, но мы, как QA инженеры, должны убедиться, что всё работает так, как
Speaker A
задумано. Для этого существуют виды тестирования, которые проверяют разные среды выполнения приложения. Кроссплатформенное тестирование проводится с целью проверить работу функционала на разных платформах. К примеру, проверка на iOS и Android или MacOS или Windows. Кросбраузерное тестирование проводится для проверки функционала в разных браузерах и их
Speaker A
версиях. Конечно, можно и объединить те браузеры, которые написаны на одинаковой базе, но тем не менее реализация разных браузеров путь с одинаковой базой может отличаться. Поэтому рекомендую вам проверять каждый браузер на самых популярных версиях. Виды тестирования по этапу жизненного цикла. Тут выделяют
Speaker A
Shift Left и Shift right тестирование. Shift Left - это тестирование на ранних этапах продукта, например, таких как анализ требований. Shift R же - это про поздние этапы, например, когда функциональность доступна всем реальным пользователям или только их часть.
Speaker A
А сейчас поговорим про требования к программному обеспечению. Требования в разработке продукта играют одну из ключевых ролей. И мы, как QA инженеры, как никто должны понимать, что это такое и как мы с ними работаем.
Speaker A
>> Если бы мы знали, что это такое, мы не знаем, что это такое. Мы по ним проверяем продукт, мы их анализируем, ну и если находятся какие-то проблемы, о которых мы поговорим чуть позже, идём разбираться к коллегам. Требования - это
Speaker A
описание того, каким должно быть программное обеспечение, что оно должно делать, как работать, в каких условиях и с какими ограничениями. Давайте разберём некоторые виды требований.
Speaker A
Бизнес-трелебования описывают, зачем продукт нужен компании или пользователю. Например, система должна увеличить онлайн-продажи магазина на 10%.
Speaker A
Пользовательские описывают задачи, которые пользователь должен решать с помощью систем. Например, пользователь может заказать до 10ти товаров одновременно. Функциональные описывают, что именно должна делать система.
Speaker A
Например, система должна предоставить возможность фильтрации товаров по цене и отзывам в реальном времени. [музыка] Нефункциональный. описывают, как именно система должна работать, то есть характеристики и ограничения. Например, создание заказа пользователем должно происходить не более чем за 5 секунд при
Speaker A
нагрузке в 100.000 RPC. Системные и технические требования, [музыка] они определяют инфраструктуру, технологии и интеграции. Например, должна использоваться база PostG SQL, платёжная система Мир, а сервера должны быть науту. У требований есть несколько свойств для того, чтобы они были качественными. Однозначность - это когда
Speaker A
требования должны быть понятными одинаково для всех участников разработки ПО. Типичной проблемой является использование аббревиатур, ведь каждый из участников процесса может расшифровать аббревиатуру по-разному.
Speaker A
Полно. Требования должны описывать весь функционал в полной мере. Типичная проблема: кнопка должна работать и быть красивого цвета. Проверяемость или тестируемость. [музыка] Каждое требование должно быть таким, чтобы QA инженер мог его проверить. И типичной проблемой тут является, например, когда требования пишется к
Speaker A
свойству человека, а не системы. Пользователь должен быть весёлым, когда отправляет сообщение. Непротиворечивость. Требования не должны конфликтовать друг с другом. Вот вам пример противоречивого требования. После успешного входа в систему пользователем, у которого нет прав входить в систему.
Speaker A
Тогда как он успешно вошёл в систему, если он не имел такого права? А томарность. Каждое требование должно описывать только одну функцию или характеристику. Например, в системе есть несколько кнопок, но под каждую из них вы делаете отдельное требование. Кнопка
Speaker A
создать заказ неколекабельно, пока не заполнены все поля на форме регистрации заказа. Актуальность. Требования должны быть актуальны, поддерживаться и обновляться при изменении продукта. И вот типичная проблема, это если требование добавлено на всякий случай, ну, типа вдруг когда-нибудь пригодится.
Speaker A
Приоритизация. Каждое требование должно иметь приоритет. Типичной проблемой может всплыть, когда требование было очень срочным, заказчик его ждал, но так как оно было не приоритизировано на бумаге, разработчик ещё даже не начал его делать. Реалистичность или осуществимость. Требования должны быть
Speaker A
выполнимы в рамках разрабатываемого проекта. Типичные проблемы - это система должна выводить результаты поиска, когда пользователь только подумает о желаемом запросе. Прослеживаемость. Каждое требование должно быть с чем-то связано, например, с бизнес-целью или релизом. И типичной проблемой тут выступает, когда
Speaker A
требования не пронумерованы, не структурированы, не имеют оглавления или не имеют работающих ссылок. Мы, а именно QA инженеры, как никто должны обращать внимание на требования, потому что чем раньше найдётся баг, тем дешевле его исправить. Поэтому старайтесь всегда анализировать их и задавать вопросы,
Speaker A
даже если они вам кажутся странными. Принимайте участие в грумингах и локальных встречах, где обсуждаются задачи. Ведь ваше мнение учитывается так же, как мнение разработчика, аналитика или например менеджера.
Speaker A
Часто на работе в IT-командах мы можем услышать два слова: верификация и валидация. Кажется, раз они встречаются, то стоит разобраться в том, что же это такое. Верификация - это проверка, правильно ли мы сделали продукт и соответствует ли он требованиям. То есть
Speaker A
мы смотрим, всё ли сделано по техническому заданию. Это как ответить на вопрос: мы вообще правильно делаем продукт? Например, QA инженеры занимаются верификацией, когда проверяют ТЗ на ошибки или несоответствие.
Speaker A
Тестируют продукт после разработки, чтобы убедиться, что всё работает ПТЗ. Баги верификации - это, например, орфографические ошибки в тексте, неправильная вёрстка или ошибки в логике работы программ. Валидация - это проверка, подходит ли продукт для пользователей и решает ли он их задачи.
Speaker A
Здесь мы смотрим, удобно ли пользоваться продуктом и всё ли работает так, как ожидают пользователи. Валидация отвечает на вопрос: "Мы делаем нужный продукт?" Обычно её проводят на тестовых или рабочих версиях продукта, проверяя реальные сценарии [музыка] использования. Пример багалиции.
Speaker A
Пользователь добавляет товар в корзину, но ничего не происходит, и он не получает никакого сообщения об ошибке.
Speaker A
Это проблема с удобством использования продукта. На этом моменте наша глава подойдёт к концу. В дополнительных материалах будут прикреплены вопросы, которые спрашивают на собеседованиях, но ответы на них будут ждать тебя на бусте.
Speaker A
[музыка] Увидимся в следующей главе. Хаджбешрошкамас. Меня зовут Иван Булгаков. Я QA-ментор и за время своей пятилетней карьеры в QA я успел поработать и в продуктовых компаниях, и в криптовалютных проектах, и в международных стартапах, и даже в Финтехе. Где-то я работал на позиции
Speaker A
сини QA, где-то я работал QA лидом. У меня за спиной иероглиф таби, который переводится как путешествие. А это значит, что мы отправимся в прекрасный мир тестовой документации. Да, возможно, ты бы выбрал путешествие на букет или на бале, но, как говорится, first things
Speaker A
first. Сначала ты учишься писать хорошую тествую документацию, потом находишь удалёнку на пару тысяч долларов в месяц.
Speaker A
И вот тогда я жду тебя к себе в гости на просторах в Азии. Очевидно, что искать баги можно и без документации. Просто отправлять разрабу скриншот найденной ошибки и говорить чини. Но есть один нюанс. Цель тестирования - это не только
Speaker A
поиск багов, но и обеспечение качества по в целом. А для этого нужно построить грамотную тестовую модель, в рамках которой тесты будут воспроизводимы, понятны, настолько полны, насколько это вообще возможно и, в идеале, приоритизируемы. И для того, чтобы всё это осуществить, нам и понадобятся
Speaker A
различные виды тестовой документации, о которых мы сегодня поговорим. Основные виды тестовой документации. Первое, план тестирования и его разновидности. Мы можем кататься по клавиатуре лицом или долбить по ней как обезьяна, а можем наметить определённый план, по которому мы будем двигаться в
Speaker A
наших проверках. План тестирования - это общий термин, включающий в себя разные документы. И вот некоторые из них. А тестплан - это классический документ, где описаны цели, объём тестирования, критерии входа, выхода, риски, ресурсы, график. Встречался ли мне тестплан в
Speaker A
работе? Нет, но зато встречался его близкий брат ПМИ. Программа и методика испытаний - это полноценный документ, который описывает цели испытаний, объекты и предмет испытаний, методику проверки, порядок приведения, критерии оценки. применяется обычно в более формализованных сферах, таких как госзаказы оборонка энергетика авиация
Speaker A
и так далее, где всё тестирование должно быть строго задокументировано и утверждено заказчиком или, иначе говоря, в конторах, где просто нельзя расслабить булки и тестировать на авось. Нужно ли тебе разбираться заранее, как оформлять и использовать PMI? Нет, спаси, Господь.
Speaker A
Если ты попадёшь на проект, где используют PMI, то тебе всё и так объяснят на анбординге. Просто запомни его название. Б. Чек-лист - это наш бро.
Speaker A
Представляет из себя перечень проверок в свободном формате. По сути, это список функциональностей, которые вы хотите проверить. Пример: представь, что твой проект - это интернет-магазин, и тебе нужно провести полное регрессионное тестирование корзины. Чек-лист для такой задачи будет выглядеть примерно так:
Speaker A
добавление товара в корзину, удаление товара из корзины, изменение количества товаров одной позиции в корзине, применение скидок, отображение скидок в корзине, оформление заказа с последующей очисткой корзины, сохранение корзины после перехода в личный кабинет пользователя, соответствие дизайну, максимальное количество товаров,
Speaker A
минимальное количество товаров, максимальная сумма заказа и так далее. Чек-лист можно вести где угодно: в блокноте, в джире, в Excel, папирусе, даже на бересте. Также можно добавлять любые дополнительные поля, такие как статус проверки, типа пройден, не пройден, приоритет, ответственный за
Speaker A
проверку, дата выполнения, дополнительный комментарий и так далее. Если вы только тренируетесь оформлять чек-листы, то советую накидывать их без дополнительных полей. Если по приходу на настоящий проект окажется, что там ведут чек-листы как-то иначе, то просто придерживайся общепринятых практик.
Speaker A
Небольшой авторский совет от меня: не используй слово проверка в чек-листе. Каждый пункт чек-листа уже по умолчанию является проверкой, и нет нужды повторять это каждый раз. На дистанции сотни написанных чек-листов сэкономленного времени будет достаточно, чтобы, например, позвонить маме, в том
Speaker A
числе и своей. Третий вариант плана тестирования - это набор тест-кейсов. И тут мы плавно переходим к следующему виду тестовой документации. Тесткейс.
Speaker A
Тесткейс - это формальный документ, который представляет из себя набор шагов для проверки одной функциональности или одного ожидаемого результата. Тесткейс не является аналогом чек-листа, он скорее соответствует одному пункту из чек-листа, но максимально подробно расписанному. Где хранятся тесткейсы?
Speaker A
Обычно для них используют специальные сервисы, называемые TMS, Test Management Systems, но о них мы поговорим позже в четвёртой части этого видео. Мне встречались и тяжёлые случаи, например, когда тесткейсы хранились в ворде или в Excel, что не особо удобно. Из чего
Speaker A
состоит тест-кейс? Начнём с обязательных полей. Первое, уникальный номер тесткейса. Обычно это айдишник, и он присваивается автоматически при создании тесткейса как раз-таки в той же ТМЭске.
Speaker A
Название тесткейса, как правило, совпадает с названием функциональности, которую мы тестируем. Например, добавление товара в корзину, оформление подарочного сертификата, предоставление скидки на товар из избранного и так далее. Шаги - это последовательность действий, которые необходимо выполнить для достижения нашего ожидаемого
Speaker A
результата. Ожидаемый результат - это то, что мы ожидаем увидеть при успешном прохождении всех предыдущих шагов. Почти все ТМЭски предоставляют возможность добавлять промежуточные ожидаемые результаты напротив каждого шага, чтобы проще было ориентироваться. если в процессе прохождения тесткейса что-то пойдёт не так. Дополнительные поля в
Speaker A
тесткейсе, которые могут быть, а могут и не быть в зависимости от принятых на проекте стандартов. Первое - это статус.
Speaker A
После прохождения проверки обычно тесткейсу выставляется статус пройден, если всё хорошо, не пройден, если он там провален, зафейлился где-то. Скип в случае, если он пропущен или блок в случае, если выполнение тесткейса невозможно по каким-то причинам.
Speaker A
Preconditions или предусловия - это совокупность условий, которые должны быть соблюдены перед выполнением шага один из тесткейса. Например, если для проверки нам необходим зарегистрированный пользователь, то нам не нужно расписывать в шагах весь алгоритм регистрации пользователя.
Speaker A
Достаточно в предусловии указать просто пользователь зарегистрирован. Postcitions пост условия. В случае, если после теста нам необходимо прибраться за собой, удалить пользователя или очистить лишние поля в базе данных, то пишем это здесь. Приоритет. Насколько важен тест-кейс для пользовательского опыта?
Speaker A
Серьёзность? Насколько проверка важна с технической точки зрения? Тестп. Тип теста: функциональный, регрессионный, ск интеграционный, нагрузочный и так далее.
Speaker A
Тестовые данные. Какие входные данные нужно использовать? Automationстатус, типа ручной или автоматизированный. Автор: кто создал тесткейс? Если у тебя ещё нет опыта в составлении тесткейсов, то рекомендую использовать только эти поля для тренировки. ID, названия, предусловия, шаги, ожидаемый результат и
Speaker A
приоритет. Кстати, в различных компаниях в зависимости от процессов могут тестировать по-разному, например, только по чек-листам или только по тесткейсам.
Speaker A
Или промежуточный вариант, например, использовать тесткейсы для самых важных и часто повторяемых сценариев, а остальное тестировать по чек-листам.
Speaker A
Почему так? У тесткейса есть преимущество. Это супердетализированный документ, рассчитанный на то, что даже конченный дегенерат, незнакомый с нашим проектом, может открыть тест-кейс и выполнить по нему проверку. Если вы не поняли тест-кейс, то это не означает, что вы хуже дегенератор. Это просто
Speaker A
означает, что тесткейс плохой. Поэтому в огромных компаниях, где много различных команд, где высока вероятность разночтений, где часта ситуация, что план тестирования пишет один человек, а в итоге проверки выполняет другой человек, там часто используют тест-кейсы. В небольших стартапах, где
Speaker A
тестировщик работает один либо их несколько, они все досконально знают проект и понимают друг друга с полуслова, поэтому можно обойтись и чек-листами. Багрепорт. Во время тестирования ты будешь находить несоответствие между фактическим результатом работы программы и ожидаемым результатом, тем, что написано в
Speaker A
документации об этой программе. Это и есть баге. Конечно, ты можешь отправить разрабу скриншот с ошибкой и сказать, чтобы он разбирался сам, что там сломалось и где. Но чем ты тогда отличаешься от обычного пользователя?
Speaker A
Одна из ценностей тестировщика заключается в его умении локализовать баг, указать чёткий алгоритм его воспроизведения. И суть проблемы.
Speaker A
Документ, который представляет из себя отчёт о баге, называется багрепоort. Могу представить, что в некоторых компаниях багрепорты выглядят вот так.
Speaker A
Но сегодня мы разберёмся, как писать их таким образом, чтобы разработчики кончали радугой от вашей тестовой документации. Где хранятся багрепорты?
Speaker A
Обычно они представляют из себя отдельные карточки в тасктрекинговых системах, таких как Gir, Kiton и так далее. Также я видел, что багрепорты оформляются внутри карточки с самой задачей на разработку, например, в комментарии или в отдельном чеклисте с багами. Либо, если тестируется огромная
Speaker A
таска, например, появление целого нового микросервиса и ожидаются многие десятки и сотни багов, то создаётся отдельная таблица в Excel или Google Shits, просто чтобы не захломлять канбан доску огромным количеством карточек с багами.
Speaker A
Из чего состоит багрепорт? Начнём по классике с обязательных полей. И первое - это ID или уникальный номер багрепорта. Обычно он присваивается тесктекинговой системой автоматически, его писать вручную не нужно. Название багрепорта отвечает на вопросы: что сломалось, где и при каких условиях, или
Speaker A
чтобы проще было запомнить, что, где, когда. Например, ошибка 500 на странице каталога при добавлении товара в корзину или список избранного не отображается в личном кабинете пользователя, если не указана дата рождения. Кажется, что название слишком длинное, но на самом
Speaker A
деле нет. Если название составлено грамотно, то разработчик может только по одному названию понять, в чём проблема.
Speaker A
И это круто. >> Круто? Да. Это же круто. >> Шаги - это последовательный набор действий, который приводит к багу.
Speaker A
Фактический результат - это описание наблюдаемого бага, который воспроизводится после выполнения последнего шага. Ожидаемый результат - это описание корректного поведения системы, которое мы могли бы наблюдать, если бы багали, проще говоря, поведение системы в соответствии с требованиями. Какие ещё поля бывают в багрепорте? Описание. Это
Speaker A
более подробное описание проблемы, но если вы правильно составили название грипор, то описание вам не понадобится.
Speaker A
Вложение - это скриншоты, скринкасты, логи, всё то, что позволит лучше продемонстрировать проблему. Приоритет, насколько срочно нужно чинить этот баг.
Speaker A
Серьёзность, насколько сильно баг ломает систему. Не путать с приоритетом. Окружение, котором воспроизводится баг. Например, операционная система, браузер, версия приложения, устройство, сборка и так далее. Ответственный, кто будет исправлять баг, а также статус, сторилин, дополнительные теги и некоторые другие редко встречающиеся
Speaker A
поля. Основные рекомендации при написании багрепортов: а, не использовать слова корректный, некорректный правильный неправильный как следует, как положено, потому что кроме тебя никто не знает, как правильно и как неправильно, и уж тем более это не знает разработчик. Поэтому при написании
Speaker A
фактического и ожидаемого результатов используйте конкретику и какие-то измеримые величины. Например, не некорректный цвет кнопки, а фактический результат - кнопка красная. Ожидаемый результат - кнопка зелёная. или вместо слишком долгое время ответа от сервера пишем фактический результат. Время ответа 9 секунд. Ожидаемый результат
Speaker A
время ответа до 2 секунд. Далее. Не использовать поле предусловия, если действие из него можно уместить в один шаг. Предусловие нужно, чтобы экстремально сократить количество шагов.
Speaker A
Например, если нам для проверки нужен зарегистрированный пользователь, то вместо того, чтобы расписывать все шаги по его регистрации, мы можем написать предусловие: "Есть зарегистрированный пользователь, и все будут счастливы". Но если нам для прохождения тест-кейса нужно оказаться на главной странице, то
Speaker A
перейти на главную страницу - это не предусловие, это шаг номер один. Далее, не добавлять ашмётки ожидаемого результата в шагах воспроизведения. В шагах воспроизведения мы пишем только конкретные действия, которые мы совершаем. Для всего остального, для того, что мы наблюдаем или хотели бы
Speaker A
наблюдать, есть отдельные поля. Например, вместо шаг два нажать на кнопку here в строчке для перехода на следующую страницу. Ожидаемый результат происходит переход на следующую страницу. Вместо этого мы пишем шаг два, нажать на кнопку here, и ожидаемый результат происходит переход на страницу
Speaker A
X. Так гораздо лучше. Далее. Не добавлять ашмётки шагов воспроизведения в ожидаемом фактическом результате. Аналогичная ситуация. Часто в наблюдаемом результате поминают последние действия, которое мы совершили. Но это ни к чему. Для действия у нас есть отдельное поле- это шаги воспроизведения. Вместо шаг три,
Speaker A
нажать на кнопку Sign In. Ожидаемый результат. При нажатии на кнопку Sign In переходит на следующую страницу. Пишем шаг три. Нажать на кнопку Sign in.
Speaker A
Ожидаемый результат. Происходит переход на страницу X. Далее, несколько багов описано в одном багрепорте. Часто появляется соблазн заснуть несколько багов в один багрепорт, особенно если они как-то касаются одной функциональности или воспроизводиятся синхронно. Нам такое не нужно. сразу по трём причинам. Первое, велика
Speaker A
вероятность, что разработчик пофиксит только один баг и просто проигнорирует все остальные. В случае, если у багов будет разный приоритет, то один возьмут в работу, а второй отложат, и придётся перезаписывать багрепорт, чтобы он отражал актуальный статус багов. И последнее несколько багов - это отличный
Speaker A
повод создать несколько карточек в Джире, заспамить её результатами своего труда, залогировать больше времени, и счастливый менеджер просто не нарадуется на трудолюбивого QA и точно захочет поднять ему зарплату на следующем performanceмасрев. В общем, одни плюсы.
Speaker A
Вместо названия зелёная кнопка на главной странице имеет текст no и её нажатие не приводит к переходу на следующую страницу. Пишем название первого блогрепорта. текстно на зелёной кнопке на главной странице. Название второго багрепорта. При нажатии зелёной кнопки на главной странице не происходит
Speaker A
перехода на страницу X. Теперь ты готов репортить баги, как настоящий профессионал. Если хочешь потренироваться в составлении багрепортов, то используй следующие поля: названия, шаги, ожидаемый результат, фактический результат, приоритет и вложение. Эти поля ты увидишь на большинстве проектов в своей
Speaker A
карьере. Следующий вид тестовой документации - это отчёт о тестировании. Вы провели все необходимые тесты, завели багрепорты. Теперь было бы неплохо подвести итоги своей работы. В зависимости от того, кому вы направляете отчёт и насколько подробно его содержание, выделяют следующие типы
Speaker A
отчётности: формальные, такие как, например, PSI, отчёт по приёмоздаточным испытаниям. Это официальный документ для заказчика. Обычно используется в госке, в промышленности и так далее. Обычно он включает в себя титульный лист с названием организации, продукта, даты проведения, подписями и печатями.
Speaker A
Введение, включающее в себя цели испытания и состав их проведения. Объект испытаний - это версия системы, краткое описание функциональности и так далее.
Speaker A
Программа и методика испытаний, перечень проверяемых функции, условия и порядок проведения, а также используемые данные.
Speaker A
Ход испытаний - это перечень выполненных тестов дата продолжительность испытаний и ответственные лица. Результаты испытаний. Обычно это некая таблица выполненных проверок, типа, что прошло, что не прошло. выявлены баги и ссылки на соответствующие багрепорты.
Speaker A
Выводы и заключения. Соответствует ли продукт требованиям, например, техзаданию, условия, при которых допускается приёмка, например, устраните значительные дефекты в течение дней.
Speaker A
Приложение: протоколы тестов, скриншоты, логи, отчёты из тэсок, акты передачи и документации и всё такое. Такой документ не составляется одним человеком. Это работа целой комиссии по испытаниям, поэтому тебе совершенно точно не придётся составлять его в одиночку. Но иметь представление о его структуре
Speaker A
будет полезно присойно на проекты, связанные с госзаказами, например. Системные отсчёты - это отсчёты, которые формируются автоматически в специальных системах после прохождения тестов.
Speaker A
Обычно они адресованы клиду, менеджеру, разработчикам внутри команды и так далее. Короче, для своих. Как пример, можно привести отчёт, который формируется автоматически в ТМЭске после прохождения набора тесткейсов. Кстати, мы потренируемся его формировать чуть позже. В нём отображается перечень всех
Speaker A
тесткейсов и их статусы. Иногда с красивой диаграммой. И ещё там дата начала тестирования, его продолжительность ответственный тестировщик и так далее. И последнее - это оперативные отсчёты. Например, скриншот пройденного чек-листа или простое сообщение ск катем. Обычно оно адресовано менеджеру или просто
Speaker A
отправляется в общий чат команды. Это происходит, когда важны не детали тестирования, а сам факт его проведения или просто конечный результат, типа ок или не ок. Мы прошлись по основным видам тестовой документации. Помните, что за грамотные тест-кейсы и багрепорты
Speaker A
тостеру простят всё, что угодно, кроме критов на проде. Спасибо за внимание. Домашнее задание: написать чек-лист на проверку любого мессенджера. минимум 10 пунктов. Далее, составить тест-кейс на оформление заказа на твоём любимом маркетплейсе и найти любой баг на сайте userinarface.com
Speaker A
и составить по нему багрепорт. Успеха. Тестдизайн. Как известно, мануальному тестировщику почти не нужны хардскилы.
Speaker A
Серьёзно, порой достаточно просто быть адекватным и готовым разобраться в новом для себя проекте. Техники тестдизайна - это те самые хардскилы, которые всё же стоит добавить себе в арсенал. Это специальные приёмы, которые позволяют сократить временные затраты на тесты и
Speaker A
уделить время именно тем аспектам нашего ПО, где чаще всего сидят баги. Вот они слева направо. Эквивалентные классы или однородные классы. Эта техника тестдизайна гласит, что если у нас есть некое множество элементов, объединённых общим признаком, то мы можем проверить
Speaker A
только один элемент на наличие этого признака и на основе этого сделать вывод обо всём диапазоне. Звучит сложно, но на практике работает >> элементарно. Мой дорогой Ватсон, >> пример с бутылкой. Представь, что однажды ты узнал, что из бутылки можно
Speaker A
пить воду. Теперь, какой бы формы, размера или цвета бутылку ты не встретил, ты точно знаешь, что можешь выпить из неё. Тебе не обязательно изучать всевозможные виды бутылок, чтобы знать об этом. Достаточно было просто выпить из бутылки когда-то давно. И
Speaker A
теперь ты знаешь пример из тестирования. Представь, что ты тестируешь интернет-магазин товаров для дома. И разработчик говорит: "Теперь в общий каталог товаров подмешиваются товары из категории самурайские доспехи.
Speaker A
Чтобы проверить эту новую фичу, тебе не нужно перетряхивать весь каталог на наличие всех видов доспехов, которые у вас имеются. Достаточно найти всего один самурайский доспех в каталоге, и всё, ты великолепен. Техника эквивалентных классов применена. Теперь ты убедился в
Speaker A
том, что новая фича подмешивания доспехов в каталог работает. Для уверенности я бы проверил два тестовых случая, но большой роли это не играет.
Speaker A
Основная ценность техники эквивалентных классов - это экономия времени тестировщика. Техника граничных значений. Она гласит о том, что наибольшее количество багов находится на пересечении двух эквивалентных классов.
Speaker A
Представь, что ты тестируешь новый промокод на скидку, который активируется только, если сумма товаров в корзине 1.000 руб. или выше. Для того, чтобы это проверить, сначала нужно выявить шаг.
Speaker A
Что такое шаг? Это разница между двумя соседними отрезками на диапазоне. Как это? Например, если это российский интернет-магазин, то минимальная разница между ценами будет равняться 1му рублю.
Speaker A
Если это белорусский, то вполне возможно, что и одной коп. Если бы это был американский сайт, то шаг между двумя ценами ближайшими равнялся бы одному доллару или центу. Для удобства предположим, что шаг - это 1 руб. Теперь мы проверяем, как наш промокод ведёт
Speaker A
себя на самой границе и назначениях слева и справа от неё. Проверяем, что при сумме корзины ровно в 1.000 руб.
Speaker A
промокод применяется. 1.1 руб. применяется, 999 руб. не применяется. Отлично. Вы великолепны. и протестировали граничные значения на этих диапазонах. Соответственно, если бы наша скидка была ступенчатой, например, и давала разную выгоду при заказе от 1.000, 5.000 и 10.000 руб., то на каждой
Speaker A
такой границе мы бы проверяли по три значения: саму границу и значения слева и справа под неё. Попарное тестирование или pairwise. Техника попарного тестирования применяется, когда у нас есть огромное количество разных параметров. И у каждого параметра ещё к тому же большое количество разных
Speaker A
значений. И наша задача - протестировать, как будут себя вести их различные комбинации. Эта техника гласит, что нам не обязательно тестировать все возможные комбинации, ведь наибольшее количество багов находятся на пересечении уникальных пар значений. Пример из жизни. Бабушка приготовила нам завтрак. Перед нами на
Speaker A
столе стоят три вида выпечки: блины, оладьи и вафли. Также бабушка приготовила нам три вида топингов.
Speaker A
варенье, сгущёнка и отработанное моторное масло. Тебе, конечно же, хочется попробовать все комбинации выпечки и топпингов, но в таком случае тебе придётся попробовать целых девять вариантов. Например, блины с вареньем, блины со сгущёнкой, блины с моторным маслом и такие же комбинации для оладия
Speaker A
и вафеля. Но по факту, чтобы сэкономить время и при этом попробовать всё и не обидеть свою любимую бабушку, можно ограничиться только тремя комбинациями: блины с вареньем, оладьи со сгущёнкой и, конечно же, вафли с нежным, тающим во рту моторным маслом. В таком случае мы
Speaker A
сократили количество комбинаций с девяти до трёх и при этом ничего не забыли. Эта техника редко применяется вручную. Для её реализации есть специальные онлайнинструменты например Pcked All Payers, Pay Advice Online Tools и многие другие. Они аналогичны по функциональности. И сейчас я
Speaker A
продемонстрирую на примере последнего, как ими пользоваться. Представим, что мы тестируем интернет-магазин смартфонов. У нас есть следующие параметры: бренд Apple, Samsung, Xiaomi. Объём памяти 64 гига, 128 гигов, 256 гигов. И цена, например, до 20.000, от 20 до 50.000. и
Speaker A
от 50.000 руб. Если проверять всё подряд, то получаем три бренда умножить на три объёма памяти на три цены равно 27. 27 тестовых случаев. Для ручного тестирования это довольно много. А теперь магия. Вводим параметры на сайте для попарного тестирования. Название
Speaker A
колонок. Здесь у нас бренд, [музыка] объём памяти и цена. Под каждым параметром мы пишем возможные значения для этого параметра. Apple, Samsung, Xiaomi. Топ за свои деньги, кстати, до сих пор с ним хожу. Объём памяти 64, 128 256 и цена до 20.000 руб. 20 -ре 50.000
Speaker A
руб. и от 50.000 руб. Нажимаем на кнопку Generate Pairwise. Происходит некая магия, и нам скачивается таблица. Мы открываем эту таблицу и видим перечень тестовых сценариев, которые необходимы для проверки. Здесь представлены различные комбинации наших параметров, которые охватывают около 90% возможных
Speaker A
багов. Но самое главное, их всего девять, их не 27. И мы сократили количество тестов в три раза. Это основная ценность нашей техники тестдийна. То есть, например, мы проверяем оформление заказа с телефоном Apple объёмом памяти 64 ценой 20к, Samsung 128 от 50к, Samsung 256 до 20K и
Speaker A
так далее. Выполняем все эти сценарии, и мы охватили наибольшее количество тестовых случаев, где возможны баги.
Speaker A
Подытожим, мы проверили все пары значений. У нас, например, каждая память встречается с каждым ценовым диапазоном хотя бы один раз, а каждый бренд встречается со всеми вариантами памяти и со всеми ценами. Мы сократили количество проверок в три раза вместо 279 тестов.
Speaker A
Такой подход особенно полезен при многих параметрах. Например, если у нас параметров пять или шесть, то полный перебор даёт сотни [музыка] тестов, а Pwise оставит только десятки. Переходы и состояния. Диаграмма переходов и состояний визуализирует состояние программы в разные периоды времени и на
Speaker A
разных этапах использования. Визуальную информацию воспринимать проще, чем текст. И таким образом техника перехода состояний позволяет быстрее получить максимальное тестовое покрытие. Этот метод эффективен при создании наборов тестов для систем со множеством вариаций и состояний. Пример с банкоматом.
Speaker A
Банкомат тоже можно представить в виде некой системы с разными состояниями. Например, изначально он находится в состоянии, ожидает ввода банковской карты. После чего мы можем сделать переход в виде действия и вставить карту в банкомат. Далее банкомат переходит [музыка] в состояние, ожидает пин-код. И
Speaker A
тут мы можем ввести пин-код или отменить транзакцию. и так далее. Мы рисуем схему, отражающую каждое такое действие и состояние. В чём фишка? Когда у нас перед глазами все состояния системы и все переходы между ними, то мы можем на
Speaker A
каждое состояние и на каждый переход написать тест-кейс и быть уверенными в том, что мы не забыли ничего важного.
Speaker A
Таким образом, эта техника позволяет нам обеспечить более полное покрытие нашей системы проверками. Предугадывание ошибок и исследовательское тестирование.
Speaker A
Эти две техники подразумевают, что тестировщик использует свой собственный опыт, чтобы испытывать систему. В первом случае такое тестирование нацелено на поиск багов, а во втором случае оно нацелено на покрытие системы тесткейсами и параллельное дополнение общей документации проекта. Непонятно, зачем
Speaker A
эти две техники выделяют в отдельные техники тест-дизайна, потому что, ну, это просто нормальное поведение тестировщика, оно не подразумевает никаких особых приёмов. Но насобесе, если вас спросят, какие техники тестдийна вам знакомы, то можете называть и эти тоже. Таблица принятия
Speaker A
решений. Это техника тест-дизайна, которая помогает проверить логику системы при множестве условий и их комбинации. [музыка] Суть метода: у нас есть условия инпут и действия. Output.
Speaker A
Мы строим таблицу, где строки - это условия и действия, а столбцы - это возможные правила или комбинации условий. Таким образом, мы получаем наглядный набор тестов, который гарантирует, что мы проверим все важные варианты. Пример авторизация по паролю.
Speaker A
Очень распространённая история. Возможные условия: корректный ли логин? Да. Нет. Корректно ли введён пароль? Да.
Speaker A
Нет. И возможные действия, которые происходят по итогу - это либо вход успешен, либо ошибка, неверный логин или пароль. Вариант один: логин верный, пароль верный, вход успешен. Вариант второй: логин верный, пароль неверный, ошибка. Вариант третий: логин неверный, пароль верный, опять ошибка". И вариант
Speaker A
четвёртый: логин неверный, пароль неверный, очевидно, ошибка. Всего четыре комбинации, и сразу видно, что только одна из них ведёт к позитивному результату. То есть эта техника тест-дизайна позволяет предугадать развитие нашей проверки и обеспечить наибольшее покрытие нашей системы тестами, потому что мы точно ничего не
Speaker A
забыли. Есть и другие техники тестдизайна, но они применяются гораздо реже, не забивай себе голову.
Speaker A
Ну что, погнали. Тмэски. Как мы уже упоминали раньше, одним из видов тестовой документации являются тест-кейсы. В древние времена наши предки писали тесткейсы на стенах пещер.
Speaker A
Впоследствии они использовали Papруus, Бересту, блокнот и Microsoft World. Но впоследствии появились специальные сервисы, которые позволяют удобно хранить, группировать и выполнять тест-кейсы, а также имели различные интеграции с другим корпоративным булшитом. Такие сервисы называются TMS или Test Management System, системы
Speaker A
управления тестирования. Сегодня мы быстро пробежимся по одной из самых популярных ТМСК под названием Case.
Speaker A
Погнали. Когда вы регистрируетесь в Case, то перед вами открывается страница Projects. На этой странице мы можем создавать и удалять проекты. Что такое проект? Это отдельные репозитории или хранилище тесткейсов, которые относятся к определённому сервису или сайту.
Speaker A
Например, если наша IT-команда занимается разработкой сразу нескольких сайтов или программ, то для каждого отдельного ПО будет создан свой проект.
Speaker A
Когда вы устроитесь в новую компанию, у них, вероятно, уже будет создан проект, но мы представим, что мы стоим у истоков нашего проекта и, собственно, делаем его с нуля. Итак, мы нажимаем кнопку Create New Project, и у нас открывается вот
Speaker A
такое модальное окно. Здесь нам нужно ввести имя проекта. Ну, пусть это будет интернет-магазин. Зовём его Оzоon Capzone. Как мы видим, автоматически формируется Project code. В данном случае он выглядит вот так. Ок. По сути, это аббревиатура из названия проекта. И
Speaker A
с этого кода будут начинаться айдишники наших тесткейсов внутри этого проекта. Первый тесткейс будет называться ОК1, дальше будет Ок2, Ок. Ниже можно настроить уровни доступа, например, чтобы проект был открытым или только для определённых пользователей. Но нам пофигу, мы работаем одни, поэтому просто
Speaker A
нажимаем кнопку Create Project. Открывается меню репозитория. Тут есть всё для управления тесткейсами, но для базового понимания нам достаточно разобрать четыре раздела. Это создание тестюта, создание тесткейса, тест plans и test runs. Тест - это набор тесткейсов, объединённых по какому-то
Speaker A
общему признаку, например, по определённой функциональности или модулю системы. Давайте проще. Testute - это просто папка с тест-кейсами. На практике я видел два популярных подхода, как делили все кейсы на тестюты. Первый по функциональности. Например, если у нас интернет-магазин, то тестюты могут
Speaker A
называться корзина, каталог, чекаут, личный кабинет и так далее. Второй вариант - это по названиям микросервисов. Например, если под капотом нашего интернет-магазина есть микросервис по управлению товарами, продукт-менеджмент или микросервис по управлению пользователями, usеer manеджмент, то, в общем-то, тесюты наследуют своё название от этих
Speaker A
микросервисов и также называются, как и они. Напоминаю, что когда вы приходите на проект, где уже трудились тестировщики, там уже будут созданы тестюты. В данном случае мы делаем всё с нуля, поэтому мы нажимаем на кнопку сюe.
Speaker A
Вводим здесь название тестюта, например, главная страница и нажимаем на кнопку create. У нас появляется новый тест с названием главная страница. Мы можем создать ещё один, если хочется, например, давайте корзина. И вот у нас уже два тестюда. Далее, создание
Speaker A
тесткейса. Тестют без тесткейса - это как сушие без риса. У нас есть два способа, как мы можем создать тесткейс.
Speaker A
Первый нажать на кнопку new test. В таком случае мы создадим тесткейс, который не будет принадлежать никакому тестюту по умолчанию. Вариант второй - это в нужном тестте нажать на кнопку Create Quick Test. После этого вводим название тесткейса, например, добавление
Speaker A
товара в корзину. Enter. Отлично. Теперь мы кликаем по названию нашего тесткейса. И у нас открывается меню редактирования тесткейса. В этом меню нас ждут уже знакомые нам поля: название тесткейса, описание, предусловия, пост условия и самое главное- шаги. Давайте заполним. В
Speaker A
качестве интернет-магазина я буду использовать свой тренажёр для тестирования Q merch. Кстати, где он? А вот и он. Так, напомню, что наш тесткейс называется Добавление товара в корзину.
Speaker A
Предусловие: корзина пуста. Итак, начинаем описывать шаги. Нажимаем на кнопку Addstep, перейти на главную страницу сайта. Ожидаемый результат.
Speaker A
Открывается главная страница сайта. Добавляем ещё один шаг. Под произвольным товаром в каталоге нажать на кнопку плюс. Покажу, как это делается. Вот у нас главная страница. Первый шаг. Мы перешли на неё. Второй шаг под любым товаром нажимаем на кнопку плюс.
Speaker A
Ожидаемый результат. Счётчик под товаром в каталоге принял значение один. И счётчик под корзиной тоже принял значение один. Пишем.
Speaker A
Добавляем ещё один шаг. кликнуть по кнопке Корзина. Ожидаемый результат. Открывается модальное окно корзины. В составе корзины я вижу мини-изображение добавленного товара, его название и количество один. Так и пишем.
Speaker A
Save. Закрываем окно редактирования тесткейсов. Поздравляю, у нас полноценный тесткейсю. Создание тестового плана. В данном случае тестплан - это не какой-то там формальный документ на 10 страниц, а удобный инструмент для группировки тест-кейсов под конкретное тестирование.
Speaker A
Представь, что у нас интернет-магазин по классике, и мы хотим проверить самый главный путь пользователя - это процесс покупки от захода на сайт до оформления заказа. Для удобства я выберу другой проект, где у меня уже созданы тесткейсы для большей наглядности. Итак, переходим
Speaker A
в Testplans и нажимаем на кнопку Create Plan. Для начала введём название, например, Smoke Test, потому что мы договорились провести тестирование самого главного пути пользователя. Это и есть скст. В описании можно указать, для чего этот план. Например, там минимальная проверка перед релизом. Ниже
Speaker A
мы выбираем, какие именно тесткейсы попадут в наш план. Нажимаем на кнопку Add cases. Можно добавить всё подряд, но лучше включать конкретные тесткейсы.
Speaker A
Например, доступность главной страницы. каталог товаров, добавление товара в корзины, удаление из корзины и оформление заказа. После этого нажимаем на кнопку Done и Create plan. Теперь у нас есть тест-план, в котором аккуратно собраны все нужные нам проверки. А для
Speaker A
чего это нужно, я расскажу чуть попозже. Создание тестран. Тестран - это уже практическая реализация тест-плана, то есть прогон тестов. Если тестплан - это список, то тест - это некая сессия, где мы реально идём по шагам и отмечаем результаты наших проверок. Жмём Truns,
Speaker A
нажимаем кнопку Start New Test run. У нас открывается окно для создания тестраunна. Вводим название, например, скст и сегодняшнюю дату. Далее выбираем по классике тесткейсы, которые пойдут в наш тестран. И вот тут как раз-таки нам пригодится созданный ранее тестплан,
Speaker A
потому что мы можем не набирать тесткейсы по одному, мы можем нажать на кнопку from testplan и выбрать наш знакомый тестпланк теest и нажать Start run. Обратите внимание, теперь перед нами список тесткейсов. Мы нажимаем либо на первый из них, либо на кнопку Open
Speaker A
Wizard. У каждого тесткейса есть виды статусов. Например, p пройден, failed, не пройден, блокed. В случае, если выполнение тесткейса невозможно. skipt в случае, если мы не можем выполнить тесткейс по какой-то причине или он нам не нужен и invalid. Что это такое, я в
Speaker A
душе не ебу. >> Ты сказал, что ты шаришь в этой теме. Ты [ __ ] >> Идём по шагам тесткейсов и расставляем статусы. Например, первый тест добавление товара в корзину. Здесь я его не расписал, но предположим, что всё
Speaker A
чётко и тесткейс пройден. Я нажал P. Удаление товара из корзины. Ну давайте ради интереса его выполнен. Предусловие: открытая страница.ru есть. И в корзину добавлен один любой товар. Выполняется. Шаг номер один: нажать на кнопку корзины. Так, нажали, выполняем как пройденный. Второй шаг-
Speaker A
нажать на кнопку минус напротив товара в корзине. Нажимаем на кнопку минус. Ожидаемый результат. Товар удалён из корзины. Отображается сообщение: "Ваша корзина пуста". Есть? Есть. Прекрасно.
Speaker A
Нажимаем PT. И после этого мы можем нажать на кнопку P сверху, чтобы отметить, что весь тесткейс вройден.
Speaker A
Точно так же мы проходимся по всем шагам наших остальных тесткейсов. Чтобы не затягивать время, мы рандомно расставим статус. Например, этот тест-кейс не пройден, нам предлагают добавить какой-то дефект, но нам нет необходимости делать это прямо сейчас.
Speaker A
Поэтому здесь мы сделаем blлоocked, здесь pст и в последнем ст. Отчёт по тестран. Когда все кейсы отмечены, кейс сам формирует отчёт. Чтобы им поделиться, мы нажимаем на кнопку Share Report. Далее мы обязательно делаем этот отчёт публичным, чтобы её мог посмотреть
Speaker A
любой член команды без регистрации в кейс. И потом эту ссылку на отчёт можно либо скопировать и прикрепить в какую-то задачу, например, задача по проведению смок-теста, [музыка] либо просто отправить её в чат коллегам. Давайте просто откроем эту ссылку в браузере и
Speaker A
посмотрим, что там такого интересного есть. Во-первых, видно общее количество тесткейсов. Сколько из них прошло успешно, а сколько не очень. Можно открыть отчёт и сразу понять, ага, там из десяти тесткейсов прошлодва, упали.
Speaker A
Оба связаны с оформлением заказа. На это надо обратить внимание. В отчёте есть ссылки на конкретные кейсы, так что разработчики могут быстро открыть их и посмотреть какие-то там шаги, ожидаемые результаты, понять, что сломалось. Также отображается дополнительная информация, например, там кто выполнил тестовый
Speaker A
прогон или когда он его выполнил, сколько времени ушло, сколько времени заняло тестирование, ну и куда без красивой симпатичной [музыка] диаграммы, сколько тесткейсов прошло, сколько нет.
Speaker A
И это очень удобно, потому что вместо хаоса в Excel и скриншотов в чатике у нас аккуратная статистика, графики и история запусков. Итог, мы прошли весь путь, создали проект, разбили тест-кейсы на тестюты, описали полноценный тест-кейс, собрали тесткейсы в тестплан,
Speaker A
запустили тестран и получили отчёт и статистику. Теперь у нас есть не просто набор тесткейсов, а прямо целая система управления тестированием, где видно прогресс, есть прозрачность для команды и понятная история для менеджеров. Есть и другие ТМЭски, например, Zефир, СТil,
Speaker A
Testlink. Прости, господи. ALure Test Ops. И обзоры на них можно легко найти в интернетах. На этом наш обзор на ТМС закончен, а мы с тобой увидимся в одной из следующих глав катацкиной.
Speaker A
>> Ну ещё раз привет. В этой главе мы познакомимся со всем, что скрыто от глаз обычного пользователя. Мы поговорим о различных архитектурах, работе браузера и, наверное, самом популярном на данный момент в стиле проектирования приложений. Мы уделим внимание не только
Speaker A
теории, но и [музыка] практическим аспектам тестирования. Что именно тестировать, какие инструменты использовать и распространённые проблемы, и как архитектура влияет на качество продукта. Так зачем же вообще инженеру нужно понимать работу браузера и архитектуру, на которых работает его продукт? Вот представь, копает человек
Speaker A
яму двое суд. Приходит заказчик и видит, что копает он не той стороной лопаты, да и участок вообще не тот. Понимание архитектуры и принципов работы браузера критично для QA инженера, потому что оно помогает за меньшее время локализовать какую-либо проблему или хотя бы сузить
Speaker A
круг поиска её источника, не распыляясь на ненужные вещи. Работа браузера. Работа в браузере происходит посредством запросов и ответов с помощью HTTP протокола.
Speaker A
Давайте разберёмся в том, что это такое. >> Мы не знаем, что это такое. Если бы мы знали, что это такое, мы не знаем, что это такое. HTTP - это протокол прикладного уровня, с помощью которого осуществляется взаимодействие клиента и
Speaker A
сервера. А что же такое протокол, спросите вы меня? А я отвечу, что протокол - это некоторый набор правил и договорённостей, по которому общаются разные системы. Иными словами, если ты будешь со мной общаться не так, как мы договорились по протоколу, я тебя
Speaker A
просто-напросто не пойму. HTTP запрос состоит из нескольких составляющих, а именно метод, URI, версия HTTP, заголовки, ну и тело при наличии. В HTTP ответа же добавляется статус-код. Статус код - это некоторое числовое сообщение от сервера, по которому мы можем понять,
Speaker A
как сервером обработался наш запрос. Статус кодов существует очень много, поэтому мы тут разберём основные группы и поговорим про самые популярные. Сотые - это информационные коды. Эти коды сообщают о промежуточных состояниях обработки запросов. Двухсотые успешные коды указывают на то, что запрос клиента
Speaker A
успешно обработан с сервером. Трёхсотый. Коды перенаправления сообщают, что клиенту нужно предпринять дополнительные действия, например, перейти по-другому URL. Четырёхсотые - это ошибки на стороне клиента, а пятисотые - ошибки на стороне сервера. Теперь поговорим про самые популярные коды. 101. Switching
Speaker A
Protocols. Сервер подтверждает, что протокол соединения изменён по запросу клиента. Например, HTTP соединение обновляется до Websocket для поддержки двунаправленного обмена данными. В двухсотый - это о'кей. Запрос успешно обработан. Сервер возвращает запрошенные данные. Весть первый - это create.
Speaker A
Запрос выполнен успешно и в результате выполнения был создан какой-то новый ресурс. Четырёхсотый - это беqст. Сервер не может обработать запрос из-за какой-то ошибки на клиенте. 401 она вторая. Клиент не аутентифицирован, то есть не предоставил действительные учётные данные. 403 Forbiden. Клиент
Speaker A
аутентифицирован, но у него нет правдоступа к запрошенному ресурсу. 404- [музыка] not found. Запрошенный ресурс не найден на сервере. 405 Note alд [музыка] getре repost не поддерживается для данного ресурса пятисотый internal server error. Общая ошибка сервера, указывающая на проблему на стороне
Speaker A
сервера, которую он не может точно описать. Это далеко не все существующие статус-коды в природе. На бусте мы прикрепим шпаргалку с большим списком кодов и их описанием, чтобы ты мог подробнее ознакомиться с каждым. Ну и, конечно, хотелось бы знать, чем
Speaker A
отличается https от HTTP. А разница в том, что HTPS - это безопасный протокол, который использует шифрование. Протокол шифрует весь поток данных, то есть URL с параметрами, заголовки, тело и какие-либо передаваемые файлы. Процесс работает следующим образом. Когда вы открываете сайт, который поддерживает
Speaker A
https, браузеру нужно проверить подлинность сайта. Происходит запрос SSL или TS сертификата. Что это за сертификаты такие? Условно говоря, это уникальный документ сайта по типу паспорта. Если у сайта он есть, то вы можете быть уверены в том, что это
Speaker A
официальная платформа, а не, например, мошенники. >> Ну я спросил, мошенники они или нет, они сказали: "Нет".
Speaker A
>> Ну и, конечно, можете быть уверены, что ваши данные будут зашифрованы и не попадут в руки злоумышленника. Ну а ТС отличается от СС тем, что это более современная версия сертификата, которая пришла на смену предшественнику. В ответ сервер отправляет сертификат SSL,
Speaker A
содержащий открытый ключ. SSL-сертификат веб-сайта подтверждает личность сервера. И как только браузер удовлетворён, он использует открытый ключ для шифрования и отправки сообщения, содержащего секретный ключ сеанса. Веб-сервер использует свой закрытый ключ для расшифровки сообщения и получения ключа сеанс. Затем он шифрует сеансовый ключ и
Speaker A
отправляет подтверждающее сообщение в браузер. Теперь и браузер, и веб-сервер переходит на использование одного и того же сеансового ключа для безопасного обмена сообщениями. Вы когда-нибудь задумывались, а что происходит, когда вы вводите в браузере, ну, yandex.ru и нажимаете Enter? Давайте разберёмся.
Speaker A
Yandex.ru - это URL, унифицированный указатель ресурс. Проще говоря, адрессайт URL включает доменное имя, в данном случае yandex.ru, которое указывает на сервер или группы серверов в интернете. Сейчас мы поговорим про все этапы, которые проходят запрос. Проверка кэша. Сначала браузер смотрит свой кэш.
Speaker A
Есть ли там сохранённое соответствие доменного имени yandex.ru и IP-адрес. Если запись найдена и не устарела, браузер использует её, чтобы не тратить время на запросы к DNS. Если в кэше браузера ничего нет, проверяется кэшо- операционная система. Обращение к DNS.
Speaker A
Твой компьютер не понимает название сайтов, потому что, как правило, работает с цифрами. Эту проблему как раз-таки решает DNS-сервер. Это некоторый справочник домен. Браузер обращается к нему с доменом, и DNS у себя ищет, если связанный с этим доменом IP-адрес. В нашем случае сначала поиск
Speaker A
информации идёт в кэша. Это некоторое хранилище твоего браузера, которое помогает ускорить его работу. Потом же идёт запрос в DNS, где уже ищется IP-адрес для доме на y яandex.ru.
Speaker A
Установка соединения. Когда мы уже знаем IP-адрес сайта, браузер подключается к серверу с помощью протокола TCP. TCP - это такой способ передачи данных, где все данные идут по порядку и гарантируются.
Speaker A
>> Iartied it. >> То, что все данные обязательно дойдут в полном размере и без потерь. Перед началом обмена делается тройное рукопожатие. TCP Handshaк. Это небольшой обмен сообщениями между браузером и сервером. То есть браузер делает запрос к серверу с желанием подключиться,
Speaker A
сервер отвечает браузеру о готовности подключения, и браузер подтверждает это и начинает подключение. Таким образом происходит проверка того, что связь установлена и работает надёжно. После этого идёт работа по HTTPS. Это то же самое, что HTTP, только с шифрованием TLS, как я и говорил ранее, чтобы никто
Speaker A
не смог подслушать данные. Сегодня почти все сайты, включая yandex.ru, ru использует именно защищённое соединение.
Speaker A
Отправка запроса. После установления соединения браузер отправляет HTTP запрос, например, для получения желаемой страниц к серверу. Запрашивая страницу, TCP разбивает запрос на небольшие пакеты обычно от 1.000 до 3.000 байт, которые содержат заголовки с информацией об от, которые содержит заголовки с информацией
Speaker A
об отправителе, получателе и порядке сборки. Если какой-то пакет теряется, TCP запрашивает его повторную отправку.
Speaker A
Получение ответа и рендеринг. Сервер отправляет ответ обычно в виде HTML кода страниц. Браузер собирает пакеты, пасит HTML и загружает дополнительные ресурсы, рендеря страницу. Одной из самых популярных архитектур на данный момент является клиент серверной архитектуры.
Speaker A
Существует некоторый клиент, который отправляет сообщение серверу. Они проходят обработку и клиенту возвращается ответ. Общаются они с помощью разных протоколов, таких как, например, HTPS или Websocket. То есть клиент выступает за отображение интерфейса и взаимодействие пользователя, а сервер за обработку
Speaker A
данных, бизнес-логику и взаимодействие с базами данных. Давайте поговорим отдельно про каждый. Клиент. Клиент - это та часть сайта, с которой вы взаимодействуете, когда заходите на него. Он отвечает за интерфейс пользователя и удобство использования этого интерфейса. В IT-сфере его чаще
Speaker A
называют фронтend. В роли клиента могут выступать ваши персональные компьютеры, телефоны или даже умные часы с колонками. Существуют разные типы клиентов, и в этом курсе хотелось бы остановиться на некоторых из них. Тонкий клиент - это такой тип клиента, где
Speaker A
основная часть вычислений выполняется на стороне сервера. Клиент тут отвечает только за передачу запросов и отображение обработанных сервером данных. В роде тонкого клиента выступают браузеры или, например, облачные сервисы по типу Word или Excel, которые открываются как веб-версия. Толстый клиент - это когда большая часть
Speaker A
бизнес-логики и вычислений обрабатываются на стороне клиента. Сервер при таком типе используется как хранилище данных или точка обмена информацией. Самым ярким примером толстого клиента является игра на вашем компьютере или какое-то приложение из семейства Microsoft Office. Сервер.
Speaker A
Сервер - это основа, на которой стоит приложение. В IT-сфере это ещё называют бэкэнд. Мы, как обычные пользователи, его не видим, но он выполняет одни из ключевых функций, например, такие, как хранение данных, их обработку и безопасность. Теперь стоит поговорить
Speaker A
про виды клиент серверной архитектуры. Одноуровневая архитектура. Такой вид встречается крайне редко, но тем не менее о нём хочется упомянуть. Это такой вид клиентсервера, когда и отображение, и бизнес-логика, и хранение данных выполняются на клиенте. В основном это встречается в каких-то локальных
Speaker A
приложениях или приложениях на одного пользователя. Двууровневая архитектура. Двухуровневая архитектура разделяет систему на два уровня: клиент и сервер.
Speaker A
Клиент отвечает за пользовательский интерфейс и часть бизнес-логики, а сервер за хранение данных и иногда часть бизнес-логики. Это классическая клиент-серверная модель. Трёхуровневая архитектура. Трёхуровневая архитектура добавляет дополнительный уровень, разделяя систему на три компонента: уровень [музыка] представления, уровень бизнес-логики и уровень данных. Это
Speaker A
более сложная и масштабируемая модель, но тем не менее в наше время она встречается чаще всего.
Speaker A
Следующей архитектурой, которую мы рассмотрим, будет монолит. Он сейчас, конечно, используется реже, нежели чем микросервисы, но тем не менее ещё встречается, и знать о нём необходимо.
Speaker A
Что же вообще это такое? Монолитная архитектура - это стиль проектирования программного обеспечения, когда все компоненты вашего приложения объединены в неделимую единицу. Это значит, что монолит - это всегда монорепозиторий.
Speaker A
Пользовательский фнд, эээнд, базы данных и другие модули существуют как одна кодовая база и разворачиваются как один процесс. Примером монолита может быть, например, какое-то нативное мобильное приложение или, например, всем известный слаг. Что же касается нас, биоинженеров, бак в монолите чаще всего может повлиять
Speaker A
абсолютно на [музыка] всю систему. И процесс тестирования зачастую охватывает абсолютно всю систему. Ну и, конечно, стоит поговорить о плюсах и минусах монолита. Из плюсов можно выделить, что разрабатывать их проще, нежели чем микросервисы, где есть огромное количество интеграций. В монолитах проще
Speaker A
отслеживать какие-либо зависимости. Компоненты монолита общаются быстрее между собой, и у них практически нет сетевых задержек. Деплоить монолит гораздо проще, так как у вас по сути всего один огромный артефакт. С точки зрения тестирования проще проводить етуе-тесты. Из минусов монолит тяжело
Speaker A
поддерживается. У вас одна кодовая база с большим количеством зависимостей, каждой из частей. Проблемы с масштабированием. Чтобы масштабировать какую-то часть монолитной системы, неизбежно будут задронуты другие части.
Speaker A
Да и если одна из частей нагружена, то будет страдать весь монолит. В большинстве случаев, если упадёт один компонент, то упадёт и вся система. Так как нужно тестировать всё приложение при изменениях, эта процедура становится довольно дорогой и трудозатратной.
Speaker A
Ну, а теперь поговорим про микросервисную архитектуру. В наше время это, наверное, одна из самых популярных.
Speaker A
Работает это примерно так. Берётся один здоровый кусок, например, монолит, и начинает дробиться на какое-то количество независимых частей, которые общаются друг с другом посредством АИ.
Speaker A
Каждый из таких сервисов, а, отвечает за одну бизнес-функцию. Эта вещь называется границей микросервиса, которую очень важно соблюдать при разработке. Принцип работы. Мы уже с вами говорили, что микросервисная архитектура - это некоторое количество маленьких отдельных сервисов. Они выполняют разную
Speaker A
бизнес-логику, но глобально работают ради общей задачи. Как правило, разные сервисы разрабатывают разные команды, каждый из которых фокусируется на своём сервисе. Для общения сервисы используют API и контракт. Что же такое контракт?
Speaker A
Можно сказать, это некоторый договор о том, как микросервисы будут общаться друг с другом. То есть это то, какие методы будут отправляться, как будут обрабатываться ошибки, какие тела ответов и запросов будут приходить, ну и какие в них будут лежать данные. Мы же,
Speaker A
как QA инженеры, должны проводить контрактное тестирование. Это такой вид тестирования, где QA инженер должен проверить, а соблюдается ли контракт, о котором договорились разработчики. Мы проверяем Jon обязательность полей или, например, на совпадение типов данных и их валидацию. Также важно обратить
Speaker A
внимание на то, соответствует ли связка запрос-ответ описанной документации. Что же по плюсам и минусам? Из плюсов можно выделить масштабируемость. В микросервисной архитектуры можно увеличивать работоспособность разных сервисов по отдельности, не залезая на другие. Разный стек. Каждый микросервис может быть написан на разных языках
Speaker A
программирования с применением разных технологий. Гибкость. Каждая команда может работать независимо от другой, обновляя свою бизнес-логику. Надёжность, сбой. в отдельном сервисе, в большинстве случаев не положит вам всю систему, а только её часть. Из минусов - сложность управления. Когда у вас большое
Speaker A
количество микросервисов, существует довольно большое количество точек [музыка] отказа систем. Инфраструктура. Тут явно не обойдётся без команды сопровождения этой инфраструктуры. Такая команда называется DevOPS. Эти ребята отвечают за то, чтобы все сервисы правильно взаимодействовали между собой и это взаимодействие проходило гладко и
Speaker A
без сбояв. Задержки. Микросервисы общаются по сети, что ведёт к некоторым задержкам, >> на которые всегда стоит обращать внимание. Что же по тестированию микросервисов? Я бы сказал, что оно определённо точно сложнее, нежели чем у монолиты. Нужно тестировать не только
Speaker A
внутреннюю бизнес-логику микросервиса, но и взаимодействие с другими частями системы. Определённо точно, нужно учиться использовать Моки и стабы, чтобы не зависеть от других команд и большое внимание уделять контрактному, интеграционному и етуе-тестированию.
Speaker A
Отличие монолита и микросервисов можно объяснить на житейском примере. Представь, что монолит - это большое здание, в котором находится всё: и бухгалтерия, и серверная, и почта, и квартиры жильцов. Если вы хотите что-то туда добавить, придётся или достраивать этаж, или забирать площадь у кого-то из
Speaker A
соседей. Микросервисы же - это коттеджный посёлок, где все здания находятся на разных местах и работают автономно. Вы можете делать их, как захотите, и расширять сколько угодно душе.
Speaker A
Ну, а теперь поговорим про АИ. Что же такое АИ? Это интерфейс программирования приложений, то есть набор некоторых правил и инструментов, которые позволяют одной программе взаимодействовать с другой. А определяет, как запрашивать данные, как их получать и как обрабатывать ошибки, но не раскрывает
Speaker A
внутреннюю реализацию. Если брать какой-нибудь пример, то можно взять виджет с курсами валюты. Сам по себе он внутри себя данные не хранит, а по А делает запрос какой-то биржи и получает нужные ему данные. Одним из популярных подходов в проектировании АИ является
Speaker A
REST. REST - это архитектурный стиль для создания веб-приложений. Он определяет, как именно должны общаться клиенты и серверы, используя при этом HTTP протокол. А что же такое стиль?
Speaker A
Архитектурный стиль - это набор рекомендаций, которые глобально можно и не соблюдать, чего не скажешь о протоколе. У REST есть шесть основных принципов, на основе которых он, собственно говоря, и работает. Клиент серверная архитектура, о которой мы как раз говорили ранее. Отсутствие
Speaker A
состояния. Каждый запрос должен быть самодостаточным, так как сервер не хранит информацию о состоянии клиента.
Speaker A
Поэтому запрос в себе должен нести и нужный endpint, и заголовки, ну и, конечно же, тело. Все элементы, которые необходимы для его правильной работы.
Speaker A
Единообразие интерфейса. Смысл этого принципа в том, что все ваши ресурсы создаются по единым правилам. К примеру, единый формат передачи данных, использование HTP методов по назначению и единое название endpoint, кэшируемость. Смысл в том, что данные в ответах сервера, которые не часто
Speaker A
изменяются, кэшируются, чтобы тратить меньше ресурсов на обработку. Многоуровневая система. Этот принцип заключается в том, чтобы организовать между клиентом и сервером прокси или балансировщики для увеличения отказоустойчивости системы. Ну и для того, чтобы клиент никогда не знал, с каким именно из серверов он общается.
Speaker A
Код по запросу. Этот принцип встречается редко и является опциональным. Сервер может отправлять JS-код для выполнения на клиенте. Давайте пробежимся по методам HTTP. В рестатапе методы используются для круто операций: cre, read, update и delete. Но прежде чем говорить о методах, хочется поговорить о
Speaker A
таком свойстве, как идомпотентность. Идомпотентность - это такое свойство метода, когда при повторном использовании запроса состояние сервера не изменяется. Например, если вы используете метод пут для изменения объекта, первое использование изменит поля объекта, а последующий уже нет. Они ведь изменились в первый раз.
Speaker A
Идомпотентность нужна для того, чтобы делать операции надёжными и предсказуемыми. Иными словами, при использовании идомпотентного метода вы избежите неприятных побочных эффектов, например, дублирование или изменение состояния сверхнеобходимых.
Speaker A
>> Метод get. Этот метод служит для получения информации от сервера. GETзапрос не имеет тела, и вся необходимая информация передаётся в URL запроса с помощью query параметam.
Speaker A
[музыка] В целом в get можно передать даже JSON, но перед этим его нужно закодировать. Также стоит помнить, что у URL есть ограничение по количеству символов. Конкретно цифры тут сложно сказать, так как в разных браузерах он разный, но это определённо иногда
Speaker A
вставляет палки в колёса при использовании метода get. Также GET запрос кэшируется и является идомпотентным. С точки зрения безопасности тут всё не так однозначно.
Speaker A
Гетзапрос является безопасным с точки зрения работы с данными, но небезопасным с точки зрения передачи [музыка] данных, так как они передаются в URL. Метод пост. Используется он для создания какого-либо ресурса на сервере. У постзапроса есть тело, в котором можно
Speaker A
передать JSON или какие-либо файлы. Так как REST - это архитектурный стиль, можно отходить от прямого предназначения метода. Например, постзапрос часто используют для получения данных, чтобы можно было обходить лимит знаков URL при использовании getзапрос. [музыка] Также пост не кэшируется, является не
Speaker A
адемпотентным. Метод put служит нам для полного обновления объекта. Этот метод является идемпотентным и используется, когда нам нужно обновить не часть объекта, а весь объект полностью. Также при определённых настройках, если вы обновляете объект, которого, например, не существует, пут запрос сможет его
Speaker A
создать. Метод patch используется для частичного обновления какого-либо объекта. Иными словами, если для использования п нужно знать все поля объекта, то для patch нужно знать только то, которое вы хотите изменить. С идомпотентностью патч всё не так однозначно. Этот метод может [музыка]
Speaker A
быть как индемпотентным, так и неидемпотентным. Например, если поле, которое вы меняете, инкрементируется, [музыка] то есть плюсуется какое-то число, то патч является нейдмпотентом. Если же вы используете патч, к примеру, как пуд, ведь никто не запрещает вам прописать JSON все поля объекта, то патч является
Speaker A
идемпотентным. Метод Delete служит для удаления какого-либо объекта с сервера и является импотентным. Метод head служит для получения заголовков запроса. Метод Options. Этот метод служит для получения поддерживаемых методов для какого-либо ресурса. Также изучая рест, вы можете услышать такое выражение, как ст. Это
Speaker A
прилагательное, которое описывает апи приложение, которое следует принципам REST. Это не работает, как это приложение restful, а это нет.
Speaker A
Приложение может быть более, ну или менее реф. Ну и на этом моменте мы с тобой прощаемся. Я надеюсь, что тебе понравился ээкэнд, потому что, как по мне, это намного интереснее, чем тестировать фронт.
Speaker A
>> Нихуя не понял. Ну очень интересно. >> Желаю тебе успехов в обучении и, может быть, когда-нибудь [музыка] встретимся с тобой в продуктовой команде. Также не забывай, что в материалах будут вопросы с интервью и для этой главы. Ну а ответы
Speaker A
ты найдёшь на бусте. Пока. >> Привет, давно не виделись. Меня зовут Иван Булгаков, и на этот раз я расскажу про базы данных. Как упоминал Паша в предыдущем блоке про клиентсерверную архитектуру, есть трёхкомпонентные системы, где помимо клиента и сервера
Speaker A
есть ещё такая сущность, как база данных. Зачем она нужна? Чтобы хранить информацию, чтобы быстро делать выборку данных и чтобы предотвращать потерю этих данных даже при рестарте системы.
Speaker A
Какие бывают типы баз данных? Когда насобесе задают этот вопрос, то обычно ожидают услышать так называемую классификацию по модели данных. Это когда база данных делится на реляционные и нереляционные. Бывают, конечно, и комбинированные подходы, но о них мы здесь говорить не будем. Итак, самая
Speaker A
популярная модель BD, с которой ты столкнёшься 100% при работе QA - это реляционная база данных. Какая база данных? Называется реляционной. Да, та, в которой данные представлены в виде таблиц. Интересный факт. В интернете вам точно встретится определение, что в
Speaker A
реляционной БД таблицы связаны друг с другом на основе ключей. Это не обязательно. Таблицы могут быть вообще не связаны между собой или может быть вообще только одна таблица в такой базе данных. и она всё равно будет называться реляционной. Поэтому просто говорите,
Speaker A
что это такая база данных, где данные представлены в виде таблиц. Всё. Структура реляционной базы данных.
Speaker A
Реляционная база данных состоит из нескольких ключевых компонентов. Первое - это таблицы, они же отношения. Это прямо строительные блоки, реляционные базы данных. И каждая таблица содержит данные об объектах одинакового типа.
Speaker A
Например, может таблица называться clients, клиенты. или orders заказы, или вот, например, таблица. Поля они же атрибуты, это различные категории данных в каждой таблице, такие как name, имя или прайс, цена или там количество очков мощи в игре Shadow of Kingdoms. Записи,
Speaker A
они же строки или кортежи. Каждая запись - это набор значений атрибутов, которые описывают один объект или одну сущность.
Speaker A
Пример строки один. Катана, традиционный японский самурайский меч. Реплика 15.51. 51. Ключ - это особый атрибут или их комбинация, которая используется для идентификации записей и построения связи между таблицами. Первичный ключ primary key. Он уникально идентифицирует каждую запись. Как правило, это айдишник. В
Speaker A
одной таблице не может быть нескольких записей с одним и тем же значением первичного ключа. И значение первичного ключа не может быть NA, то есть пустым.
Speaker A
Раньше в качестве ID использовали просто порядковый номер, то есть 1 2 3 и так далее, но впоследствии из соображений безопасности всё чаще стали использовать шестнадцатиричные айдишники, которые называются uid. Внешний ключ forign key, он содержит ссылку на первичный ключ из
Speaker A
другой таблицы и привязывает одну таблицу к другой. Если утрировать, то это столбец, который является общим для двух таблиц. Например, есть уже знакомая нам таблица, которая хранит в себе все товары нашего интернет-магазина. Есть таблица category, которая хранит в себе
Speaker A
категории товаров. Так как любой товар в интернет-магазине имеет свою категорию, то две этих сущности связаны. Поэтому в таблице продукт есть поле category ID, которое указывает на определённую категорию из таблицы categories. Таким образом, можно сказать, что category ID из таблицы product является внешним
Speaker A
ключом. Это он и есть. Нереляционная база данных или новый SQL - это база, которая не использует классическую реляционную модель с таблицами. Такие БД появились, когда реляционные системы стали плохо справляться с огромными объёмами данных и распределёнными системами, такие как Big Data или там
Speaker A
соцсети и так далее. Вместо этого данные хранятся не в таблицах, а в более гибких структурах, таких как первое [музыка] документные. Данные хранятся в виде документов JON, Von, XML и так далее.
Speaker A
Каждый документ - это объект со своей структурой, которая может отличаться от других. Второе - это ключ значения. Это самая простая структура, очень быстрое чтение и запись по ключу. Третье - это графовые базы данных. Данные - это некие вершины и связи. отлично подходят для
Speaker A
анализа сетей, соцграфов и рекомендаций. Четвёртое колоночные данные хранятся по колонкам, а не по строкам. Удобно для аналитики и больших данных. Отличие нереляционных ВD от реляционных.
Speaker A
Во-первых, они легко масштабируются горизонтально, как в кластере серверов. Это нужно для того, чтобы при многократном увеличении нагрузки на базу данных не покупать суперкомпьютер, а просто докупить большее количество серверов. Нереляционные базы данных изначально заточены на такое масштабирование, в то время как с
Speaker A
реляционными базами данных пришлось бы сильно усложнять структуру. Далее, высокая скорость работы с огромными объёмами данных. Также нереляционные БД поддерживают сложные структуры, такие как вложенные структуры, документы, Jсоon, графы и так далее. Из минусов нет строгой схемы, что, в свою очередь,
Speaker A
приводит сразу к нескольким проблемам. Внереляционных базах данных сложнее контролировать целостность. Например, одно и то же по смыслу поля в разных документах может называться по-разному.
Speaker A
Иногда это приводит к бага. Ещё сложнее перенос данных и поддержка. Например, в SQL при добавлении нового поля ты меняешь структуру данных всей таблицы. В N SQL каждое приложение может писать новые поля без миграции. Поэтому часто через год база превращается в зоопарк
Speaker A
разнообразных разнотипных документов. И последнее. Сложнее аналитика, потому что когда структура данных разная, агрегировать данные становится труднее.
Speaker A
С типами баз данных мы разобрались. Теперь пару слов про СУБД. СУБД или система управления базами данных - это программное обеспечение, которое позволяет делать многие вещи, например, хранить данные в организованном виде, таблицы, документы, графы и так далее, обеспечивать быстрый
Speaker A
доступ к этим данным, управлять изменениями добавление удаление обновление, обеспечивать безопасность и целостность данных и работать с несколькими пользователями одновременно.
Speaker A
По сути, без УD наша база данных представляла бы собой простой текстовый файл, и с данными в нём пришлось бы взаимодействовать прямо самым топорным образом. Например, редактировать текст вручную побуквенно или тратить долгое время на поиск информации. Особенно в случае, если нам нужно найти что-то чуть
Speaker A
более сложное, чем просто совпадение. По словам, СУD позволяет нам использовать специальные языки запросов к базам данных, например, легендарный SQL, а также защищает данные при одновременном взаимодействии нескольких пользователей, позволяет настраивать разные уровни доступа и так далее. СУБД бывают разные
Speaker A
среди нереляционных базданных. Это, к примеру, Mongo ADB для документов, Redes для паркзначения, Orient database для графов, Click Houseу для колоночных баз данных и так далее. Если говорить про реаляционные базы данных, то самые популярные SUBD для них - это Oracle,
Speaker A
MySQL, Microsoft SQL Server и Postg SQL. Для системных архитекторов эти СУBD имеют отличие стоимости, сложности, внедрении, простоте и так далее. Есть ли разница для нас, как для QA инженеров?
Speaker A
Нет. Ко всем реляционным базам данных мы будем обращаться примерно одинаково с помощью одного и того же языка запросов SQL, о котором мы поговорим позже. Иван, непонятно. Вот есть СУБД. А как её пощупать? Как она выглядит? И это отличный вопрос. Суd - это программа,
Speaker A
которая установлена на сервере. И если мы хотим провзаимодействовать с нашей базой данных через СУBD, то есть два самых распространённых способа. Первый - это подключиться к серверу через консоль, чаще всего линуксовую, и отправлять запросы в базу данных через консольные команды. Это круто и
Speaker A
олдскульно, но не всегда удобно. Да и взаимодействие с Linux-консолью - это отдельная тема, которая здесь затронута не будет. Поэтому изобрели второй вариант, это графические интерфейсы для СУБD, те самые программы, которые запускаются с твоего рабочего стола или в браузере и спокойно управляются
Speaker A
координатным устройством ввода типа мышь. Эти программы, в свою очередь, делятся на специализированные, которые подходят только для одной определённой базы данных, как, например, MySQL Workbench для MySQL или PG Adдмин для PostgrQL и универсальные, которые подходят к большинству реляционных СУBD,
Speaker A
например, Deber или Valentin Studio. Чтобы добавить себе в резюме умение обращаться с базами данных, достаточно тренироваться отправлять запросы через любой из этих инструментов. Я возьму так называемого бобра, он же дебир, и покажу на его примере, как это делается.
Speaker A
Помните, я говорил, что тестировщику почти не нужны харскилы. Так вот, SQL - это единственная причина, по которой обезьяны ещё не отняли работу у мануальных тестировщиков. Просто потому, что знания SQL на базовом уровне чуть сложнее, чем умение найти кнопку на
Speaker A
сайте и кликнуть по ней. SQL Structured Query Language - это язык запросов к реляционным базам данных. Пригодится ли он в работе? С вероятностью 10-15%, потому что на проекте у вас может вовсе не быть доступа в БD или все запросы по
Speaker A
традиции выполняют разработчики. Пригодится ли SQL для подготовки к сабесам? Да, однозначно. На каждом втором собесе попросят собрать какой-нибудь простой запрос. Зачем? Ну, потому что тестировщика хоть о чём-то надо спросить на собеседовании, помимо его предыдущего опыта. Сегодня мы разберём, так сказать, базу.
Speaker A
>> Это базовый минимум, >> структуру у простых SQL-запросов и основные команды, которых будет достаточно для 80% тестовых заданий на Manual QA. Итак, я обещал показать интерфейс бобра для тестировщика.
Speaker A
Открываем debвеer. В левом верхнем углу жмём правую кнопку мыши создать соединение. В списке выбираем под.
Speaker A
Почему? Ну, потому что я заранее знаю, что это моя [музыка] СУBD. Меня об этом предупредили. Далее мы должны заполнить поля хост, название базы данных, порт, пользователь и пароль. У вас на проекте доступы будут примерно в таком виде. Они
Speaker A
либо лежат документацией, либо вам их присылает коллега в личку во время онбординга. Итак, нажимаем тест соединения.
Speaker A
Отлично, соединено, всё чётко. Нажимаем готово и подключаемся. Мы подключились к базе данных, но где же наша таблица? Открываем вкладку базы данных, название нашей BD и One Database, схемы и таблицы. Вуаля. Мы видим две таблицы: продукт и категории.
Speaker A
Чтобы обращаться к нашим базам данных, нам нужно написать SQL запрос к ним. Для этого мы кликаем правой кнопкой по названию базы данных редактор SQL открыть SQL Scriptриpt. Погнали. Чтобы не уходить в абстракции, возьмём простую модель интернет-магазина. У нас есть
Speaker A
таблица product с полями ID, Name, description price quantity L created at и таблица категория с полями ID, name, created. Эти две таблицы связаны через поле category ID таблицы product.
Speaker A
Это поле является внешним ключом и смотрит на поле ID в таблице category. Этой структуры уже достаточно, чтобы на примерах показать все базовые операторы SQL. Базовая структура запроса, самый простой запрос в SQL выглядит так: Select столбцы from таблица. Select -
Speaker A
это выбери. После чего указываем, какие именно поля или колонки мы хотим увидеть. Например, в таблице product есть колонки ID, name, price, quantity.
Speaker A
К примеру, возьмём вот такой простой запрос. Select name price from product. Это означает, что мы обращаемся к таблице product и нам нужны только колонки name, имя и price - цена.
Speaker A
Нажимаем на запуск и вуаля, из нашей таблицы product мы получили все данные по тем колонкам, которые мы указали. Имя и цена. Далее, вместо того, чтобы указывать отдельные колонки, мы можем добавить звёздочку. Звёздочка в сQL означает все столбцы. Если в таблице,
Speaker A
например, шесть полей, то селект звёздочка вытащит сразу все. Например, select звёздочка from product. Не забываем, что мы указываем, к какой таблице мы обращаемся и нажимаем выполнить запрос. Как видите, у нас указаны все поля из данной таблицы.
Speaker A
Напоминаю, что оператор указывает на то, из какой таблицы мы берём данные. То есть, если нам нужна таблица category, а не таблица product, то мы просто пишем запрос select name from category.
Speaker A
Нажимаем выполнить. И в данном случае у нас отображаются только имена категории. К таблице product это не имеет отношения. Немножко усложним. Добавим оператор Weare. Оператор Ware добавляет условия. Например, в случае, если нам нужно найти все товары с ценой больше
Speaker A
1.000, то в таком случае наш запрос будет выглядеть следующим образом: Select ID name price from product where price больше 1.000. Понятное дело, что в первой части мы можем просто всё заменить на звёздочку, чтобы нам вывелись все столбцы. Но самое
Speaker A
интересное происходит здесь. Здесь мы указываем условия, цена больше 1.000. Выполняем запрос и получаем все необходимые данные. Давайте проверим, действительно ли нам вывелись все товары с ценой больше тысячи. 15 7 4 3,5 2300.
Speaker A
Превосходно. Всё работает. Погнали дальше. К оператору можно добавить частичку note. В таком случае мы будем отрицать это условие, как бы переворачивать его. И в таком случае наш запрос выведет все товары. Цена которых не более 1.000.
Speaker A
Проверяем, пожалуйста. 600, 400, 350, 500, 700. Кажется, мы движемся к успеху. Погнали дальше. Можно делать более сложные условия, например, добавлять операторы или или и. Как это работает?
Speaker A
Давайте разберём вот этот запрос. Select ID name price from product where price меньше 500 or name like. Что это означает? Это означает, что у нас должно выполняться хотя бы одно из двух условий. Либо цена меньше 500, либо имя
Speaker A
включает в себя слово чай. Давайте проверим, пожалуйста. Мы выполнили запрос. Давайте проверим. У нас здесь присутствуют записи с ценой 400-350. Они соответствуют первому условию, но также присутствует товар, в имени которого есть частичка чай, хотя он стоит дороже 500. Погнали дальше. Следующий оператор
Speaker A
- это End. В таком случае у нас будут проверяться оба условия, и необходимо, чтобы наша запись из таблицы соответствовала сразу обоим этим условиям. Например, select ID name price quantity from product where price 1.000 and quantity 10. В таком случае
Speaker A
отображаются только товары, которые дороже тысячи и имеют больше 10 товаров в наличии. Пожалуйста, проверяем. Больше 1.000 цена 42500. Да. Больше ли чем 10 количество? 12. Превосходно. Погнали дальше. Оператор Order Buy. Он помогает упорядочить записи, например, по возрастанию определённого столбца или по
Speaker A
убыванию. Например, разберём вот этот запрос. Select ID name Price from product order by price. Это означает, что мы упорядочим наши записи в таблице по цене от меньше к большему. Проверяем.
Speaker A
Действительно, наши записи отсортировались по увеличению цены. Но что, если мы хотим отсортировать их по уменьшению цены? В таком случае нам нужно в конце добавить частичку desk.
Speaker A
Как вы видите, наши записи в таблице перевернулись. Теперь у нас сначала идут дорогие товары, и впоследствии мы спускаемся к более дешёвым агрегатные функции. Периодически нужно узнать максимальное или минимальное значение в каком-либо столбце. Как раз-таки для этого служат специальные агрегатные
Speaker A
функции. Про них я сейчас вам расскажу. Вот, например, так выглядит агрегатная функция Мак. Обратите внимание на синтаксис. Мы пишем select max. В скобочках мы пишем столбец, в котором нам нужно вычислить наше максимальное значение. И по классике указываем таблицу, из которой мы берём данные. В
Speaker A
данном случае продукт. Выполняем. В итоге мы вычислили максимальную цену из нашей таблицы. Она равняется 15.000. Что если мы хотим узнать минимальную цену? В таком случае давайте напишем вместо макс мину. Выполняем. Пожалуйста, нам предоставили минимальную цену. Это 350.
Speaker A
О'кей. А может быть, мы хотим среднюю цену? Пишем AVG, он же average. Выяснили, что средняя цена в нашей таблице - это 3.455.
Speaker A
Может быть, нам нужно узнать не среднюю цену, а среднее количество. О'кей, просто пишем название другого столбца.
Speaker A
Quantity, пожалуйста. Среднее количество наших товаров составляет 37,6. Ещё одна очень важная и очень часто встречающаяся агрегатка - это count. Count считает количество строк в нашей таблице.
Speaker A
Давайте проверим, как это работает. Select count from product. В данном случае мы просто считаем, сколько записей находится в нашей таблице без каких-либо условий. В данном случае 10.
Speaker A
Но что, если мы хотим добавить какое-то определённое условие, например, посчитать количество товаров, где цена больше 1.000. Здесь как раз-таки каунт очень сильно выручает. Мы выполняем этот запрос и понимаем, что товаров с ценой больше тысячи, всего пять. join объединение. Иногда нам нужно получить
Speaker A
данные сразу от двух таблиц одновременно. Например, нам нужно вывести все товары, а также название категории для каждого товара. Но категории хранятся в другой таблице. Что делать? Помните, что наши таблицы были связаны столбцами ID и category ID.
Speaker A
Благодаря этому мы можем объединить таблицы через оператор join. Давайте покажу, как это делается. Обратите внимание на этот запрос. Вначале мы указываем все столбцы, которые мы хотим отобразить. В данном случае очень важно также указывать таблицу, из которой этот столбец взят, потому что в разных
Speaker A
таблицах могут быть столбцы с одинаковым названием. В этом нет ничего удивительного, но нашей базе данных нужно понимать, а что конкретно мы имеем в виду. Поэтому в данном случае у нас здесь product.id. ID - это название столбца, product - это название таблицы.
Speaker A
также по аналогии product name, product price и category name. То есть, обратите внимание, мы выводим product name название товара и category name как название категория. Также с помощью частички S мы можем переименовать название столбца именно в нашей выборке,
Speaker A
чтобы не путаться, потому что у нас есть два имени, поэтому последний столбец category name мы переименуем просто в category. Далее from product. Я думаю, вы уже прекрасно понимаете, что это означает. И далее идёт оператор joint.
Speaker A
Он указывает на то, что таблицу product мы объединяем с таблицей category. И далее важно указать, а по какому столбцу. Это работает следующим образом.
Speaker A
Мы указываем он on. Далее указываем столбец productory id. Обратите внимание, здесь название таблицы product. Здесь название столбца, который является внешним ключом, и он равен столбцу categorте ID. То есть в таблице categorте есть столбец ID, который эквивалентен столбцу categorте ID в
Speaker A
таблице. Надеюсь, что вы не запутались. Выполняем этот запрос. Посмотрим, что он выведет. Итак, обратите внимание, в первых трёх столбцах у нас фигурируют данные из таблицы продукт. Это айдишник товара, его название и цена. Но к нему добавляется дополнительный столбец
Speaker A
category, где указано название категории, которой относится данный товар. Прекрасно. Возвращаемся к выборкам из одной таблицы. Дистинкт.
Speaker A
Дистинкт убирает записи с повторяющимися значениями. Или, вернее сказать, дистинкт выводит только уникальные значения из этого столбца. Давайте разберём на примере select distinct price from product. Что делает этот запрос? Select distinct price from product выведет только уникальные цены на наши товары. Вот они сверху вниз. В
Speaker A
случае, если бы у нас были товары с одинаковой ценой, то он бы вывел не 10 записей, а меньше, там девять или восемь, в зависимости от того, сколько у нас есть товаров с одинаковыми ценами.
Speaker A
То есть понятно, каждая цена, которую в данный момент вывел запрос, она уникальна. Повторений нет, в этом его фишка. Следующий оператор - это лимит.
Speaker A
Ограничить. Например, нам не нужно, чтобы в нашей выборке были все товары из нашей таблицы. Может быть, нам достаточно только пяти. В таком случае нам поможет подобный запрос. Select звёздочка from product или пять. В таком случае наш запрос выведет только пять товаров из нашей
Speaker A
таблицы. Может быть нам нужен один товар. О'кей, давайте выведем один. Отлично. Может быть, нам нужно семь.
Speaker A
Прекрасно. Лимит семь. Бам. Элементарно. Погнали дальше. Также мы разберём три оператора, которые выполняют не выборку, а другие действия. И они используются вместо select в начале запроса. Погнали.
Speaker A
Иsert буквально переводится как вставить, но в данном случае он добавляет запись в таблицу. Например, нам нужно добавить новый товар. Давайте посмотрим на синтаксис. Вначале у нас идёт insert intruct. После инта идёт таблица, в которую мы добавляем наши данные. Далее в скобочках мы
Speaker A
перечисляем, а в какие столбцы мы добавляем данные. В данном случае мы добавляем данные во все столбцы. И мало ли бывает ситуации, что нам нужно сделать запись, где будет только айдишник и имя. Тогда у нас было бы просто ID и name. В данном случае мы
Speaker A
делаем полноценную запись, полноценную строку. Поэтому здесь мы перечисляем название колонок, в которые мы добавляем данные. А дальше после оператора values мы добавляем сами значения этих колонок.
Speaker A
То есть ID [музыка] 11, name, маска Kitsune, description - традиционная японская маска лисы, price 220, quantity 7. Когда сделано, есть оператор сейчас и категори ID 1. То есть мы полностью прописываем, какие значения будут в этой записи. Выполняем. Судя по всему, запрос
Speaker A
выполнен успешно. Никаких ошибок нет. Давайте теперь проверим, а действительно ли у нас появилась новая запись в таблице.
Speaker A
Выберем все записи из таблицы продук. Опа! Посмотрите, у нас появилась новая запись с ID 11. Прекрасно. Погнали дальше. Update. Оператор Update позволяет обновить какие-то данные в нашей записи. Например, нам нужно обновить цену товара в новой записи. У нас была цена 2.200. Обратите внимание
Speaker A
на синтаксис. Оператор Update обновить. Опять же указываем таблицу продукт. Далее идёт оператор set, после которого мы указываем, что мы меняем. Название колонки Праice цена равно 1999.
Speaker A
Но если бы мы ограничивались только этой частью запроса, то он поменял бы цену на 1999 вообще во всех записях. А нам этого не надо. Нам нужно поменять только цену в записи с ID 11. Поэтому мы добавляем уже знакомое условие where. Where ID =
Speaker A
11. Выполняем. Ну, судя по всему, запрос проведён успешно. Давайте проверим. Да, действительно, обратите внимание, цена нашей маски поменялась на 1999. Всё чётко. И последний запрос - это delete, удалить. В данном случае мы можем удалить товар из нашей таблицы или
Speaker A
несколько товаров. Кстати, будьте аккуратны с этим, потому что если вы некорректно пропишете условия по удалению товаров, вам может прилететь под вашего начальника на работе.
Speaker A
Обратите внимание на синтаксис. Сначала идёт delete, потом уже знакомое from product. Мы указываем из какой таблицы мы удаляем данные. И прописываем обязательно условия, какие данные.
Speaker A
Whereare ID = 11. То есть мы удаляем товары из таблицы product. Такие товары, у которых айдишник равно одиннадцати. У нас, очевидно, айдишник является первичным ключом. Он относится только к одной записи, к последней, с которой мы вот как раз взаимодействуем. Пускаем наш
Speaker A
запрос. Он проведён успешно. И теперь мы проверяем, что наша таблица лишилась последней записи. Select звёздочка from product. БМ. Как было раньше 10 товаров, так и осталось. Прекрасно всё получилось. Очевидно, что все эти операторы можно комбинировать между собой самым безбожным образом. И,
Speaker A
например, в качестве домашнего задания попробуй определить, что делает этот запрос. цитирую: select product name product price category name from product join category on category id = product category id where category id = 3 order by product price limit one правильный
Speaker A
ответ в комментах и на утро к тебе прилетит фея корпоративного успеха и пригласит на оплачиваемую стажировку в Яндекс шутка стажировок не существует зато то существует в бусте Антона, где можно найти правильный ответ. На этом всё. Мы разобрали основные операторы
Speaker A
SQL. Я желаю тебе успеха в следующих блоках данного курса. И помни, что в современном мире нет недостатков информации. Лучше изучить основы и доучить то, чего не хватает уже на рабочем месте, чем терять время, сидеть изучать всё, что только может
Speaker A
пригодиться, при этом вечно откладывая выход на собесы. Начни уже зарабатывать больше кататься Киной. Всем привет. Меня зовут Эмин, и я аккуаментор с пятилетним опытом работы в крупнейших финтехах страны. Мне досталась самая лучшая глава в этом курсе, практика. Спасибо моим коллегам
Speaker A
за то, что разобрали всю необходимую теорию. А мы переходим к самому сладкому. Сегодня мы с тобой будем учиться с важным видом кликать на кнопочку на мышке и зарабатывать огромное количество бабла и называть себя айтишниками. Да, именно тут становятся миллионерами, а не во всяких
Speaker A
тапоках. Если ты понимаешь, о чём я. Прежде чем мы перейдём к практике, давай обсудим один вопрос, который беспокоит новичков и людей, которые хотят попасть в эту прекрасную профессию. Нужно ли тестировщику знать программирование? Я думаю, что 10 из десяти гейткиперов,
Speaker A
которые давно засиделись на своих местах и считают, что куаби знания языков программирования, автоматизации - это не настоящие специалисты, скажут тебе: "Да, обязательно нужно знать язык программирования, понимать код разработчиков, разбираться во всей архитектуре системы, знать каждую подногодную проекта и чуть ли не каждый
Speaker A
день общаться с ДВОOпсом по поводу любого изменения схеме продукта. Скажу тебе честно, в реальной работе это просто не нужно. Все, кто так говорят, хотят навесить на тебя как можно больше работы за ту же самую стоимость.
Speaker A
>> Опять работа. >> Поверь нам, менторам, через которых прошли десятки и сотни учеников, на старте достаточно уметь грамотно нажимать на кнопочку. Конечно, знание языков программирования - полезная штука, но важно понимать, зачем оно тебе. Хочешь ли ты уйти в автоматизацию,
Speaker A
тестировать в белом ящике, как именно ты получишь ощутимую пользу от изучения языка программирования? Без этой цели язык превращается не в инструмент, а в лишний груз. Куда же тыкать, чтобы стать практикующим тестировщиком? После окончания этого блока ты будешь владеть
Speaker A
всеми необходимыми инструментами для стартов, понимать, как работать с ними правильно и сможешь уверенно выходить на собеседование, закрывая требования большинства вакансий. Поэтому предлагаю долго не тянуть и перейти к самому интересному. Практике.
Speaker A
Во, теперь нормально. Стой, подожди. Пока ты не ушёл пранковать друзей на их девайсах, давай объясню, как я это сделал и почему это может пригодиться тестировщику. Что я вообще такое открыл?
Speaker A
Встречайте. Death Tools один из главных инструментов тестировщика. Хотя этот инструмент изначально создавался для разработчиков, но он также невероятно цен для нас с тобой. Ты можешь подумать, что самое главное, что может этот инструмент, я показал только что. Но нет, давай по порядку. Death Tools
Speaker A
доступен в большинстве современных браузеров, таких как Chrome, Safari, Firefox, но везде функционал плюс-минус похож. Я буду показывать всё на примере Google Chrome, так как это самый популярный браузер ВF. Как открыть Death Tools? Существует несколько способов, но основные - это F12 на Windows и Command
Speaker A
Option I на Maке, либо три точки, More Tools, больше инструментов, и выбираем Developer Tools. При первом открытии DEOLS обычно появляется снизу или справа, но это отображение мы можем настроить самостоятельно, тогда как для frontнд-разработчика расположение Death Tools может играть роль в вёрстке. Для
Speaker A
нас, тестировщиков, это больше эстетический выбор. Кстати, об эстетике. Нажимаем Ctrl Shift P на Windows или Command Shift P на macOS и switch to Dark Mode. Не благодарите. Ну или ладно, на Light Mode, но осуждаю. Итак, теперь можно приступать к структуре Death Tools
Speaker A
и обсудить четыре самых важных вкладки, которые тебе реально могут пригодиться на собесе и в работе. Первая вкладка - это Elements. Как только мы открываем DEOLS, то попадаем на вкладку Elements, на которой мы видим DOM. Document object model - это древовидное представление
Speaker A
HTML-документов. Да, многие из вас уже приготовили камни, чтобы закидать меня, потому что недавно я говорил, что язык программирования не пригодится, а сейчас мы говорим про какой-то HTML. Но не торопитесь, HTML - это никакой не язык программирования, а язык разметки,
Speaker A
который формирует структуру и правила отображений для веб-сайта. Теги HTML - это ключевые элементы языка размек. Как вы помните, в главе Proпи мой коллега Паша уже рассказывал про другой язык разметки XML, в котором также используются теги. Теги бывают открывающими и закрывающими. Закрывающие
Speaker A
обозначаются как слшнутри тега. На любом сайте в шапке HTML структуры сайта вы увидите обозначение Doc type HTML, а для XML, соответственно, DocPE XML, чтобы вы сразу понимали, какой язык перед вами.
Speaker A
Далее, вся эта структура обычно обёрнута в два тега: head и body. Они разделяют веб-сайт на шапку и тело. В рамках этого курса мы не будем подробно разбирать каждую строчку HTML-кода. Да и в целом, как тестировщики, мы не должны
Speaker A
разбираться во всём. Важно лишь понимать, что происходит в целом, и знать, куда смотреть. Также ты всегда можешь использовать джиптишку для краткой выжимки информации. CSS Cascading Style Sheets - это язык таблиц стилей, определяющий внешний вид страниц и то, как отображается HTMLконтент.
Speaker A
Например, backкground color блока с товарами можно поменять на, допустим, розовый, написав слово пин в строку или передав его код после хэштега. Наверное, вы уже несколько раз заметили, как я пользуюсь вот этой кнопкой слева сверху.
Speaker A
Она называется Инспектор. Зачем она вообще нужна? По сути, это инструмент, который позволяет подсветить информацию об HTML и CSS для любого элемента на странице. Но важно, инспектор не выбирает сам элемент интерфейса, он просто помогает нам найти его кодовую часть в структуре страницы. Вот,
Speaker A
например, я навожу на плашку с кнопкой Добавить в корзину. Всё хорошо. Пока я просто навожу, элемент подсвечивается, но стоит кликнуть и оп, плашка пропадает. Что делать в такой ситуации, когда элемент исчезает быстрее, чем ты успеваешь его поймать? Тут нам на помощь
Speaker A
приходит точка остановки breakpoint. Breakpints позволяют поймать момент, когда на странице происходят изменения. Например, добавляется или исчезает элемент, меняется класс или атрибут. По сути, это способ сказать браузеру: "Стоп! Остановись именно в тот момент, когда что-то поменяется". Итак, давайте разберёмся с более простым примером
Speaker A
Breakpoint, прежде чем вернёмся к нашему сайту. Потому что, ну, будем честны, не у всех сразу есть вебпроект с выпадающими окнами и сложными элементами, а потрогать хочется.
Speaker A
Перейдём на главную страницу Google и найдём вот этот ярлычок слева от аккаунта. Он открывает все сервисы Google. Инспектором кликаем по нему, находим его класс, нажимаем правую кнопку, выбираем break on и атрибут modifications. Теперь при следующем нажатии на этот элемент страница
Speaker A
остановится и сверху появится сообщение pa in thebugger. Значит, наш бakpoint сработал. Далее в стилях находим свойство background color и пишем white, у нас теперь белый фон блока со всеми сервисами. Теперь давайте перейдём к более интересному кейсу уже на сайте.
Speaker A
Как видите, при добавлении товара в корзину появляется вот эта плашка. Но фокус в том, что она открывается только при наведении мыши. И как только ты двигаешь курсор, она пропадает. В обычной ситуации инспектором её не поймать, поэтому используем другой тип
Speaker A
точки остановки. Sub3 Modifications. Также нажимаем на правую кнопку мыши break on и subtri modifications. Теперь, когда структура HTML поменяется, например, добавится элемент при наведении, страница остановится в этот момент. Теперь мы открываем вкладку Elements и находим этот блок. И,
Speaker A
например, меняем background color на Purple. Готово. Как мы можем видеть, break points - это реально полезный инструмент для QА, особенно если нужно изучить поведение динамических элементов, которые исчезают при инспекторе или потере фокуса.
Speaker A
Используются они часто, но когда пригодится, спасает время и нервы. Ну и чтобы далеко от касса не отходить, давай сразу разберём ещё одну полезную штуку.
Speaker A
Device togole Toolbar или, как я её называю, device Tools. Здесь можно выставить пресеты популярных мобильных устройств: iPhone, iPad, Galaxy и так далее. Если стандартных мало, жмём на edit, и открывается целый каталог.
Speaker A
Да-да, тут даже Blackberry есть, видимо, на случай, если кто-то решил протестировать прошлое. Можно добавить и свои пресеты или просто вписать произвольные размеры в разделе Responsive Dimensions, например, 500 на 1.000 пикселей. И, кстати, работает это всё на удивление стабильно. Теперь
Speaker A
главный вопрос: зачем нам это нужно? А нужно это, чтобы проверить адаптивность вёрстки, то есть как сайт выглядит на разных устройствах и разрешениях.
Speaker A
Например, давайте перейдём на тестовый сайт и выберем iPad Pro. И, как мы видим, выглядит вполне достойно, ничего не съехало, и разработчик молодец. Ну вот, переключаемся на Samsung Galaxy S8 Plus, и некоторые элементы уходят влево.
Speaker A
А название категории чуть-чуть залезло за рамки. Но не переживайте за нашего разработчика. Мы специально заплентили сюда несколько багов, чтобы ты мог их увидеть. А теперь давай перейдём ко второй важной вкладке в Death Tools. Это консоль. Если кратко, то это место, где
Speaker A
живут логи фронтенда, то есть логирование работы JavaScript кода страниц. Во-первых, обратите внимание, вот здесь можно фильтровать логи по типу. Нажимаем на кнопку слева и видим четыре ключевых категории: errors, warnings, info и verbow. Давай же разберём каждую. Info - это
Speaker A
информационные логи. Информационные логи - это просто общие уведомления о происходящем. Например, токен истекает через 10 минут или загруженной категории товаров. Полезно, когда нужно понять, что процесс вообще запустился. Также есть warnings. Это предупреждающие сообщения. Они не ломают сайт, но могут
Speaker A
намекать, что где-то под капотом уже зреет баг. Скажем так, если бы сайт был организмом, то Warnings - это лёгкий кашель. Вроде жив, но присмотреться стоит. Хотя, если по-честному, тестировщик редко следит за ними постоянно. Их может быть сотни даже на
Speaker A
полностью рабочих сайтах. ERORS - это уже серьёзные ошибки, которые могут повлиять на поведение веб-приложения.
Speaker A
Например, не найден элемент, не пришёл ответ по апи или возникло исключение в JavaScript. С ними нужно быть внимательным. Именно они часто объясняют, почему кнопка вдруг перестала работать. [музыка] Сейчас у нас, кстати, ошибок нет, но, поверь, появится, как только ты откроешь следующий проект.
Speaker A
Verbows - это сырой поток логов самого низкого уровня. Там подробнейшая информация для разработчиков, обычно связанная с внутренними событиями или перерисовкой компонентов. Честно, я туда и не лезу. Да и не нужно. По умолчанию Overboss включён в дефолтных уровнях логирования, но для QA он редко несёт
Speaker A
практическую пользу. Подведём итог. Консоль - это быстрый способ понять, где сломался фронт, и дать разработчику точную зацепку. Вкладка sources или источники нужна для просмотра всех загруженных файлов: HTML, CSS, JavaScript изображений шрифтов медиа и отладки JavaScript. Но тестировщиками не слышал, чтобы когда-то пользовалось.
Speaker A
Так что пропускаем network. Итак, переходим к одной из самых важных вкладок в Def Tools. Это network. Если DEOLS - это инструмент тестировщика, то network - это его рентген. Здесь видно всё, что происходит между фронтом и беком: запросы, ответы, статусы, файлы и
Speaker A
время загрузки. Каждое действие на сайте - это обмен запросами по HTTP или https протокола. Ты нажал кнопку, страница что-то отправила на сервер, а сервер ответил, и всё это фиксируется здесь.
Speaker A
Проще говоря, тут сниферится весь трафик. Чтобы не утонуть в сотнях запросов, можно включить фильтры по типам файлов и соединений. Еч XHR, запросы капи. Именно они отображают данные, полученные сервера. JS подключённые JavaScript файлы, логика фронтэнда. CSS- стили оформления, которые подгружается отдельно. AMG
Speaker A
изображение в форматах JPG, PNG, SVG и так далее. Медиа видео и аудиофайлы, ФНТ подключённые шрифты, Doc, документы, чаще всего HTML-страниц, манифест метаданные для установки веб-приложения, как PVA на устройство пользователя. WS Websocket двухсторонняя связь между клиентом и сервером без постоянных HTTP
Speaker A
запросов позволяет, например, обновлять данные в реальном времени. Чаты, уведомления, курсы валют. WASM Webassembly, код на C++ в браузере, используется в производительных и безопасных веб-приложениях, и all показывает всё подряд. Также сверху есть поиск по ключевым словам. Можно отфильтровать запросы по URL. методу или
Speaker A
даже по содержимому ответу. Да, фильтров тут целая армия, но ты не переживай, 95% времени ты будешь жить во вкладке FCH XHR. Каждый запрос - это как мини досье.
Speaker A
У него есть свои данные, которые важно уметь читать. Headers - это заголовки запроса и ответа, авторизация, тип контента, user agent и прочие параметры.
Speaker A
Payload - это тело запроса, то, что отправляется на сервер. Например, данные формы, логин, фильтры и так далее.
Speaker A
Preview - это форматированный человеческий вид ответа. А вотс - это сырой ответ в текстовом или Jonде.
Speaker A
Тайминг - это подробная шкала, показывающая этапы выполнения: DNS-разрешение соединение отправка ожидание и получение. Initiator - это тот кусок кода, который запустил запрос.
Speaker A
Например, конкретная JavaScript функция или события. На этом примере видно, мы можем увидеть весь путь от момента клика до ответа сервера. Если что-то пошло не так, тестировщик может сразу сказать: "Запрос не ушёл, значит, проблема на фронте". Или запрос ушёл, но вернул
Speaker A
пятисотый статус-код. Значит, ищем бак на беке. Что же ещё интересного можно посмотреть в Network? На самом деле, тут куча полезных мелочей, которые здорово облегчают жизнь тестировщику. Во-первых, можно отключить кэш. Когда стоит эта галочка, браузер не подгружает данные с
Speaker A
памяти, а каждый раз заново запрашивает всё с бэкэнда. Это важно, если ты хочешь убедиться, что изменения реально приходят сервера, а не всё осталось где-то в браузере. Следующая полезная штука - это preserve log. По умолчанию, когда мы перезагружаем страницу, все
Speaker A
запросы очищаются. Но если включить эту опцию, все старые запросы сохраняются даже после перезагрузки или перехода на другую страницу. То есть теперь можно спокойно проследить всю цепочку действий пользователя. Ещё одна крутая функция - это throtling. С её помощью можно
Speaker A
эмулировать разные типы сети: 3G, 4G, Wi-Fi или оффлайн. Очень удобно для проверки, как сайт ведёт себя при плохом интернете, например, не слетает ли форма или появляется ли сообщение об ошибки.
Speaker A
Также можно сохранить или импортировать H файл- это архив со всеми запросами, ответами и их содержимым. Достаточно нажать на кнопку Save all. Иногда разработчики или аналитики просят именно такой лог, чтобы воспроизвести твой кейс у себя. Можно даже скопировать отдельный
Speaker A
запрос как курлу, чтобы потом прогнать его в постман или консоли. Теперь давай немного попрактикуемся. Найдём запрос на Produxs и посмотрим, что оно возвращает.
Speaker A
Заходим во вкладку Response и видим в ответите семь продуктов. Ну, начинается с нуля, как и положено в разработке. У каждого есть ID name, а поле description пустое. Так тестировщик может быстро понять, что AP возвращает корректные данные, а значит, фontт рисует именно
Speaker A
то, что пришло с сервера. Теперь давай разберёмся, где именно браузер хранит данные и чем отличаются все эти страшные слова: Cash, cookie, local storage и session storage. Перейдём в последнюю важную вкладку для тестировщиков.
Speaker A
Application или приложение CAS Ш - это временное хранилище, где браузер сохраняет часто используемые ресурсы: страницы изображения стили скрипты.
Speaker A
При повторном заходе браузер подтягивает данные из кэша, а не с сервера. Страница загружается мгновенно. Кэш хранится локально. Его можно очистить вручную или он очищается сам со временем. Он нужен для ускорения загрузки, а не для хранения пользовательских данных. Важно,
Speaker A
кэш не отправляется вместе с запросами, он работает только на стороне клиента. По сути, кэш - это память браузера, чтобы не тратить время на повторной загрузки. Cookies - это крошечные текстовые файлы, которые сайт сохраняет у себя на устройстве. Они помогают
Speaker A
сайтам запоминать тебя: логины, настройки, язык, тему. Бывают временные, удаляются при закрытии браузера и долгосрочные. Живут днями и неделями.
Speaker A
Куки отправляются на сервер с каждым запросом, чтобы сервер узнал тебя. Обычно в них хранят токен авторизации или язык интерфейса. Ничего лишнего.
Speaker A
Объём куки ограничен примерно 4 Кбми, поэтому туда не кладут большие данные. Если сайт запомнил тебя без авторизации, почти наверняка дело в куках. Local Storage - это долговременное хранилище данных в браузере пользователя. Данные сохраняются даже после закрытия браузера. Используется для интерфейса и
Speaker A
мелких удобств: фильтры, тёмная тема, состояние корзины и так далее. Информация не отправляется на сервер, живёт только у пользователя. Объём обычно 5 или 10 Мб в зависимости от браузера, в сотни раз больше, чем cookie. Идеален для вспомогательных данных, которые не критичны для
Speaker A
безопасности. Local storage - это как заметки браузера о твоих предпочтениях. Session storage - это тот же Local Storage, но только на время открытой вкладки. Как только ты закрыл вкладку, данные исчезают. Используется для временных вещей: заполнение поля формы, шаг регистрации, фильтры просмотра, не
Speaker A
загружает сервер и не хранится дольше, чем живёт вкладка. Объём также около 50 Мб, но данные не передаются между вкладками. Session storage идеальным для временных сценариев, где данные не должны жить дольше сессии. Вот и вся магия. Теперь ты понимаешь, где браузер
Speaker A
хранит всё, что связано с пользователем, [музыка] чем отличаются временные, постоянные и серверные данные. Часть три. Кросбраузерное тестирование.
Speaker A
Кросбраузерное тестирование - это проверка того, как сайт или веб-приложение работает в разных браузерах, потому что каждый браузер использует свой движок и по-разному интерпретирует HTML, CSS и JavaScript.
Speaker A
На собеседованиях часто спрашивают, как правильно подобрать браузеры для тестирования. Ответ простой. Ориентироваться нужно не на количество браузеров, а на движки, потому что именно движок определяет, как страница будет рендериться. Сейчас есть три основных движка: Blink, на нём написан Google Chrome, Яндекс Браузер, Opera,
Speaker A
Ebrave, Geek, на нём написан Muzillo Firefox и Webkit. На нём написан Safari для MacOS и iOS. Соответственно, минимальный набор браузеров, который покрывает все движки - это Google Chrome как основной представитель Blink, Firefox как представитель ГКА, Safari как представитель Webkit и Яндекс
Speaker A
Браузеer. Он важен для российского рынка, несмотря на то, что он тоже написан на блин. Подводя итог, мы выбираем браузер не по популярности и не по количеству, а по движкам, чтобы гарантировать корректную работу продукта на всех типах рендеринга. Такой подход
Speaker A
экономит время и даёт максимальное покрытие без дублирования. Часть четыре. Posman. Мы рассмотрели инструмент Death Tools для тестирования веба, но в приложениях также используется. И для его тестирования одним из инструментов является Posman. Posman - это широко используемый инструмент для [музыка]
Speaker A
работы с API, отправки запросов, получения ответов и их тестирования. Он является ключевым инструментом в арсенале тестировщиков, ээнд-разработчиков, а также активно используется фнтэнд разработчиками и аналитиками, заинтересованными во взаимодействии спи в обход пользовательского интерфейса приложения.
Speaker A
Мы можем использовать Postman для того, чтобы протестировать БК, когда фронт, например, ещё не готов или на стадии разработки, либо, если нашли баг со стороны БКА, то, чтобы убедиться, используем также Посман для работы с запросами. Теперь давайте разберём коллекцию заказов Postman и посмотрим,
Speaker A
как она работает целиком, от создания заказа до его удаления. У меня уже есть коллекция, в которой собраны все запросы по разделу Orders. заказа, получение всех заказов, создание, изменения, частичное изменение и удаление. Это полноценный тестовый сценарий, который можно запускать как по одному запросу,
Speaker A
так и всей цепочкой сразу. Сначала я покажу, как это выглядит вручную. Открываем GET запрос, отправляем и смотрим, какие заказы мы получили.
Speaker A
Теперь давай создадим новый заказ. Выберем постзапрос. Введём имя, email пользователя. Введём ID товара и количество этого товара. Нажимаем на send. И заказ успешно создан. Проверяем, запустив ещё раз getзапрос, и видим новый заказ в списке. Всё верно. ID заказа, имя, mail, ID товара и
Speaker A
количество отображаются корректно. Теперь переходим к путзапросу. Это полное обновление данных заказа. Давай изменим имя и email пользователя и нажмём Send. Запрос успешно выполнился.
Speaker A
И снова проверим get. Заказ обновился и данные пользователя изменены. Перейдём к патч. Это частичное изменение данных заказа. Давайте поменяем, например, только количество. [музыка] Отправляем запрос. Он выполнен успешно. Проверяем ещё раз getт запросом. И количество обновилось. Остальные поля остались без
Speaker A
изменений. После этого удаляем заказ через Delete. Отправляем и получаем статус 200. Проверяем getт запросом. И последнего заказа больше нет. Если повторно запустить Delete и придёт 404 статус-код, то есть не найдено, то значит удаление прошло успешно. А теперь самое полезное. запуск всей коллекции
Speaker A
одним нажатием. Для этого мы используем Postman Collection Runner. Нажимаем на три точки рядом с коллекцией. Нажимаем Run и отключаем последний пост. Он нам понадобится дальше. Всё остальное оставляем включённым. Получение заказов, добавление изменения частичные изменения и удаление. Нажимаем Run. И
Speaker A
Postman запускает запросы по очереди. Мы видим, что все шаги прошли: и создание заказа, и обновление, и удаление.
Speaker A
Последний гетзапрос возвращает 404. Логично, потому что заказ был удалён, и это означает, что сценарий прошёл корректно. И теперь о важном. В коллекции используется переменное окружение. Это так называемый environment. Например, Order ID сохраняется автоматически после создания заказа и передаётся в следующие запросы.
Speaker A
Благодаря этому тебе не нужно копировать ID вручную. Пос это делает за тебя. И, кстати, в Posman можно ненадолго почувствовать себя автоматизатором. Для этого достаточно открыть вкладку Scripts и добавить небольшой тест, который проверяет, что при создании заказа сервер вернул статус код 200. И самое
Speaker A
приятное, для этого вообще не нужно уметь программировать. Посман есть раздел, где лежат готовые шаблоны тестов. Просто кликаешь и снизу появляется рабочий код проверки. Ну или можно просто попросить и сгенерировать этот тест, вставить его в скрипт и получить такой же результат.
Speaker A
Swager - это документация IP. где можно не только смотреть структуру запроса, но и выполнять его через try out и execute.
Speaker A
Если выполнить запрос без данных, получим ошибку. Но это не так важно нам сейчас. А важно то, что в Свагере можно копировать курл команду прямо отсюда. И этот курл полностью описывает запрос: метод, адрес, заголовки, тело. Мы можем взять этот курл и перенести в Посман. В
Speaker A
Посмозётся новая коллекция, к ней добавляется пустой запрос. Ну или можно добавить этот запрос в уже существующую коллекцию. Вставляем курl и Postman автоматически собирает запрос. Подбирает HTTP метод, переносит заголовки, приносит тело. Получается полностью готовый запрос, который можно редактировать. Теперь разберём
Speaker A
телозапроса. Поле ID - это ID категории, который мы добавляем товар. Полиame - это название товара. Поле description - это описание товара. И поле - это метаданные, например, ссылка на изображение или, а структура может быть вложена. Created ad и updated ad можно
Speaker A
удалить, они для нас сейчас не обязательны, сервер заполнит их самостоятельно. На реальном проекте чаще есть документация по апе, где всё описано, но в нашем случае я вам просто подскажу. Чтобы понять, в какую категорию добавлять товар, открываем Death Tools Network и находим запрос,
Speaker A
который загружает список категорий. Сред них нам нужна категория итальянские животные. У неё есть свой ID. Его нужно поставить в поле ID. Теперь заполняем товар. Название пусть будет балерина капучино. Описание любое, например, разбивает сердца. Метаданные в продукт можно вставить свои, например, ссылку на
Speaker A
картинку, что я и сделал. А create и удаляем. В итоге остаётся чистое тело запроса с нужными полями. Вправляем запрос и получаем успешный статус код.
Speaker A
Проверяем. И в нашей категории создался товар. В Postman запрос уходит напрямую на бэкэнд, минуя фронт. Это полезно, когда нужно протестировать апи напрямую, когда фронт недоработан или когда UI блокирует отправку. Например, клиентская валидация не даёт отправить неправильный ail, когда нужно быстро создавать
Speaker A
тестовые данные или воспроизводить баги. Таким образом, мы создаём новый товар в нужной категории, используя курlл и swager и поман для оправки запроса. Это базовый, но очень важный навык QА. Уметь повторить поведение фронта через инструмент для апи и подставить нужные
Speaker A
значения вручную. А на этом у меня всё. Если хочешь попрактиковаться, то можешь попробовать самостоятельно создать коллекцию в Postmon, используя openсоourсный сайт бронирования по этой ссылке, и создать коллекцию на следующие запросы: получение списка всех бронирований, получение конкретного бронирования, создание нового
Speaker A
бронирования, получение токена, полная замена данных бронирования через пузапрос, частичное изменение данных бронирования через патч запрос и удаление бронирования через delete, последние три с использованием токена, если это пока слишком сложно, для тебя, то можешь заглянуть к нам на Бусте, где
Speaker A
тебя будет ждать текстовая инструкция для этого задания и трёх дополнительно. Увидимся в следующей главе.
Speaker A
>> Надеюсь, дорогой мой друг, что ты посмотрел все предыдущие части и уже понимаешь, как проводится веб-тестирование. Если нет, то советую посмотреть их, потому что сейчас мы будем погружаться в мобильное тестирование путём сравнения с вебом.
Speaker A
В первую и самую главную очередь мобилка отличается от веба способами доставки приложений до конечного пользователя.
Speaker A
Напомню тебе, как проводится релиз на вебе. Ты тестируешь фичу на предрелизных стендах. Сборка проходит критерии приёмки. У всех компаний они немного отличаются. Дальше фичу выкадывают на прот, и ты переходишь в режим ждуна и поддержки. Это когда тебе звонит тимлит
Speaker A
и орёт трубку по каждому багу. Но орёт он не сильно, потому что наши бравые друзья разработчики нажатием одной кнопки могут откатить фичу для всех, либо быстренько произвести ход фикс. Это когда баг фиксится прямо напротив. А вот при баге напротив нативных мобильных
Speaker A
приложениях орать будет совсем по-другому, потому что фикс на мобилках не предусмотрен. Если сейчас ты не понимаешь, что такое нативные, не переживай, мы рассмотрим виды мобильных приложений чуть позже. Разберёмся же, почему никакого хфикса нет и как релизится на мобилках. В отличие от
Speaker A
веба, в мобилках появляется новый персонаж. [музыка] Знакомьтесь, store. Store нам был бро, когда мы хотели порубиться в Clash of Clans или скачать Instagram. Но для IT команды store не бро. Именно Store во второй части Мафии сказал: >> "Прости, FIС в сделку не входил".
Speaker A
>> Сторы бывают разные. В основном это App Store и Play Market. Но жители РФ, наверное, знают, с какими проблемами сейчас сталкиваются пользователи этих сторов. Поэтому, если ты будешь работать на фмпанию, вероятно, ты столкнёшься с релизами и через rotore. У каждого из
Speaker A
этих сторов есть свои проверки, о которых мы поговорим чуть позже. И пока мы не пройдём ревью от сторов, а пользователи не скачают новую версию приложения, фикса не будет. Понятное дело, что если сломается что-то важное, а Фикс будет проходить ревью 1-2 дня, то
Speaker A
пользователи будут крайне недовольны. Как же эту проблему решают на мобилке? Полностью эту проблему не решить, но попытаться можно с помощью фичафлагов или же тоглов, переключателей, которые при нажатии откатывают фичу приложение на всех устройствах. Обычно фичатоглы хранятся в режиме разработчиков
Speaker A
приложении либо же в приложении Firebase Remote Config. Проблема фича Тогла для нас тестировщиков в том, что её работу тоже нужно тестить. Включил, проверил, что фича работает, отключил, не работает. А также фича флагов обычно несколько, так что нужно проверять их
Speaker A
взаимодействие, что один не отменяет другого. Кстати, неплохой пример для попарного тестирования, про который вы слышали в главе Ваня. Также в мобилках намного чаще проводится тестирование прямо на Проде именно по причине сложности фиксов и часто используют поэтапную раскатку для проверки
Speaker A
ограниченным кругом пользователей, чтобы потом раскатить на всех. Давай поговорим про другие типы мобильных приложений, чтоб ты на работе не удивился, что ХТфиксы у вас на мобилках всё-таки ставится или приложение на Андроиде или Айосе написано на одном языке программирования. Про нативное мы уже
Speaker A
поговорили. Оно пишется на котlн для Android и Свифте для айOS. Доставляется конечному пользователю через сторы. Это самый популярный тип приложений, но тут есть свои нюансы. Нужны две команды разработки под каждую систему. Также есть гибридные приложения, где, в отличие от нативных они написаны на
Speaker A
одном языке. Раскатываются [музыка] практически одинаковые сборки для обеих систем. Но, конечно, есть подвох. Из-за попытки в универсальность железо системы используется не на полную мощность и часто вылезают ошибки вёрстки. Примером является Uber. Ещё есть мобильные веб-приложения. По сути, это просто
Speaker A
веб-сайты, которые свёрсаны под мобилку. Если ты смотрел предыдущую главу про практику со мной, то девайс Toolза, как в Death Tools, как раз отображал мобильную веб-версию сайта. Примером, тут может служить любой сайт, который ты открыл [музыка] в интернете через
Speaker A
телефон. И, наконец, есть PVA приложение. Это что-то среднее между вебом и настоящим приложением. По сути, это сайт, который можно установить на телефон, и [музыка] он будет вести себя почти как нативный. У него появится иконка, кэш, буши уведомления, даже
Speaker A
оффлайн-режим. Кстати, возможно, ты уже пользуешься ими, потому что наши банки после блокировок в основных сторах предлагают альтернативно поставить их PVA приложение Точка, Газпромбан и так далее. Главное отличие от обычного веба: ты можешь открыть сайт один раз, добавить его на домашний экран, и дальше
Speaker A
оно запускается как будто отдельное приложение без браузера. Но, конечно, и тут не без ограничений. На iOS такие штуки часто работают нестабильно. Apple их не слишком любит, а доступ к системным IP сильно ограничен.
Speaker A
Давай поговорим о различиях Android и iOS. Все мы привыкли к тому, что мир крутится вокруг двух экосистем: Android и iOS. Каждая живёт по своим правилам: разные языки разработки, разные подходы к тестированию и куча особенностей, о которых важно знать куас специалисту.
Speaker A
Разберём ключевые различия. Во-первых, это экосистема. [музыка] Android - это открытая среда. Здесь можно установить приложение из любого источника, собрать билд локально и протестировать без то.
Speaker A
Разработчику достаточно иметь устройство и желание. Усё строго. Чтобы создать или протестировать приложение под iOS, нужен MacBook, а установка вне App Store запрещена. Система полностью контролирует дистрибуцию, что делает экосистему закрытой, но [музыка] более стабильной. Второе - это разнообразие устройств. У Android сотни
Speaker A
производителей и тысячи моделей. У каждого своя комбинация железа, версия OS, оболочка и поведение системы.
Speaker A
Поэтому одно и то же приложение на Samsung и, например, к Xiaomi может вести себя совершенно по-разному. Усё прочее: линейка айфонов немного, и поведение системы предсказуемо.
Speaker A
Тестировать меньше, но требования выше. Третье - это вендеры. Android - это как конструктор LEGO. Samsung, Xiaomi, Google, Huawei десятки других компаний выпускают свои устройства с разными интерфейсами и настройками. У каждой собственная оболочка, свои датчики, свои фишки. Из-за этого могут отличаться
Speaker A
работа Bluetooth, NFC, GPS или камеры. Apple всё делает сама: и железо, и софт, и экосистему. Благодаря этому устройства ведут себя одинаково, отличаясь разве что версия региона. Четвёртое - это гайдлайны и актуальные версии OS. У каждой системы есть свой Йдлайн. Android
Speaker A
опирается на Material Design 3 Эсpresser, используемый в Android 16, [музыка] где акцент сделан на динамике, глубине, адаптивных цветах и плавных анимациях. Это развитие идеи Material U, которая позволяет интерфейсу подстраиваться под тему и фон пользователю. iOS придерживается Human Interface Guidelines. Минимализм,
Speaker A
аккуратные переходы и визуальная частота. В iOS 26 Apple представила новый стиль Liquid Glasss. Эффект жидкого стекла с полупрозрачностью, отражениями и мягкими световыми слоями.
Speaker A
Гайдлайны постепенно обновляются под этот новый визуальный подход. И Android, и iOS описывают не только внешний вид, но и то, как должны реагировать кнопки, как строить анимации. Без соблюдения этих правил приложение просто не попадёт в стоore. Доставка и установка билдов.
Speaker A
На нативных приложениях ещё нужно как-то доставить приложение на тестовые стенды для тестировщиков. [музыка] В Android обычно скидывают APK файлы, либо используют Firebase. Экосистема iOS более закрытая, поэтому доставляется [музыка] приложение либо сразу на про, но доступно только для тестировщиков
Speaker A
через настройку в режиме разработчика приложения, либо через теestстфай. У >> тестирование мобильных сборок проводится либо виртуально, либо на реальном банке устройств. Симулятор - это программный инструмент, который воссоздаёт поведение операционной системы, но не самого устройства. Он просто показывает, как
Speaker A
приложение будет работать в среде системы без участия реального железа. Типичный пример - это симулятор XCд.
Speaker A
Если провести аналогию, то симулятор - это твоя голограмма. выглядит как ты, двигается как ты, говорит как ты, но внутри пустота. Он показывает, как всё должно быть, но не чувствует ничего вокруг. Ни света, ни температуры, ни касаний. [музыка] Эмулятор - это
Speaker A
программное обеспечение, которое воспроизводит работу аппаратного устройства, имитируя его процессор, память, датчики и сетевые модули. Проще говоря, он создаёт виртуальную копию телефона внутри компьютера, чтобы можно было запускать и тестировать приложение без физического устройства. В экосистеме Android для этого используется Android
Speaker A
Studio, самый популярный инструмент разработки и тестирования Android приложений. [музыка] Если сравнить с метафорой, то эмулятор - это твой клон по ДНК. У него есть такие же органы: мозг, сердце, нервы, но они искусственные. Он повторяет поведение телефона, но не передаёт реальных
Speaker A
факторов: накрева, разряда батареи, отклика сенсоров и случайных лагов. Реальное устройство - это, собственно, настоящий телефон, с которым взаимодействует пользователь. [музыка] Это единственный вариант, где можно увидеть реальное поведение приложения в живых условиях, как оно реагирует на слабую сеть, нагрев, разряд батареи,
Speaker A
приход уведомлений, ворота экрана, работу камеры и сенсоров. Если продолжить аналогию, то реальное устройство - это ты сам. Живой, настоящий, с эмоциями, реакциями и непредсказуемостью. [музыка] Для того, чтобы написать приложение, использует IDE. Android Prлы пишут в Android Studдию iOS W XCode. Зачем они нужны
Speaker A
тестировщикам? Во-первых, чтобы собрать бил с новой фичей. Во-вторых, чтобы протестировать билд на эмуляторе или симуляторе. И в-третьих, чтобы снять логи с реального девайса. Теперь мы выяснили, что есть инструменты, через которые происходят разработка и тестирование. Через них можно собрать
Speaker A
билд с новой фичей, установить его на устройство, протестировать, а главное- снять логи. И вот на логах давай остановимся поподробнее, потому что это один из самых частых инструментов в реальной работе, когда нужно посмотреть, почему приложение упало или зависло.
Speaker A
Первым делом мы идём именно в логи. Чтобы снять логи с реального устройства, нужно первое установить тестовую сборку на телефон, [музыка] второе- подключить устройство к компьютеру по кабелю.
Speaker A
Третье- открыть Android Studio или XCД, если это iPhone. [музыка] Четвёртое - перейти во вкладку Lockcat в Android Studio или консоль в XCOД. Пятое - нажать кнопку GetLog или Run, и ты сразу видишь поток системных сообщений. В этот момент на экране начинают появляться все
Speaker A
события, которые происходят в приложении: сетевые запросы, ошибки, отладочные сообщения, исключения и системные логи. Если во время теста случается краш, то в логах ты увидишь строку с пометкой Fatal Exception. По ней можно понять, где именно приложение упало и почему. Дальше всё просто. Ты
Speaker A
сохраняешь эти логи и прикладываешь их к багрепорту в Таске, чтобы разработчик быстро нашёл причину. Или пытаешься локализовать сам. Ищешь человека, читаемую ошибку в логе, запросе или ответе апе.
Speaker A
В основном используют три снифера Чарльз, Фидлер или Proxyman. У них похожи инструменты, но абсолютно разный интерфейс. Для чего же они нужны?
Speaker A
Сниферы умеют смотреть трафик, запрос, ответ, их содержимые коды статусов и подменять ответы. Breakpoint - это точка остановки. Она ловит конкретный запрос или ответ и позволяет вручную изменить его перед тем, как он пойдёт дальше. То есть Снифер буквально перехватывает
Speaker A
трафик и даёт тебе возможность снести правку, поменять тело запроса, статус или часть данных в ответе. После этого ты нажимаешь продолжить и запрос продолжает движение уже в изменённом виде. Map local делает то же самое, но автоматически. Вместо ручного вмешательства ты заранее создаёшь
Speaker A
локальный файл, например, durfверestenu.jon. И sniffer каждый раз подменяет ответ сервера с этим файлом. Но у Mapocal есть ограничение, он заменяет весь ответ целиком. Если нужно изменить одно поле, придётся справить файл или использовать другой подход. Вот для этого и
Speaker A
существует rewrite. Это самая гибкая функция снифера, которая позволяет не подменять весь ответ, а изменять только отдельные части данных по заданным условиям. Например, можно сказать: "Если в ответе приходит статус говнокурсос", то автоматически поменяй его на менторство. После этого Снифер найдёт
Speaker A
все места, где статус говнокурса, и наконец-то поменяет его на мечество. А если Снифер смог, сможешь и ты.
Speaker A
Плин - это ссылка, которая открывает не просто приложение, а сразу нужный экран внутри него. По такому диплинку приложение банка должно открыть экран перевода с заранее заполненной суммой и номером счёта получателя. На схеме, которая сейчас перед тобой, показана разница между переходом по обычной
Speaker A
ссылке и поди плинку. Visз de diplлиinking, который находится у тебя вверху. Пользователь кликает по баннеру, попадает в App Store, устанавливает приложение и сразу же после первого запуска попадает на нужный экран.
Speaker A
Например, акцию с -35%. [музыка] Visout deeplinking, которая у тебя внизу. Пользователь кликает по баннеру, попадает сначала на мобильный сайт, потом Webstore, устанавливает приложение, открывает главную страницу и только после этого доходит до нужного экрана. То есть много лишних шагов. Это
Speaker A
и есть ключевое преимущество диплинков. Они сокращают путь пользователя и ведут его прямо к нужному действию. При тестировании плинков обычно проверяют открытие из разных источников: SMS, email, push, [музыка] переход именно в нужный раздел приложения, корректную передачу параметров, сумма, счёт,
Speaker A
промокод, работу на iOS и Android, [музыка] поведение в разных состояниях приложения, не запущено, свёрнуто, активно, обработку ошибок и отсутствие доступа, редирект на логин или сообщение об ограничении. Какие ещё инструменты стоит упомянуть, которые тебе могут пригодиться в тестировании? ADB Android
Speaker A
Debug Bridge - это инструмент, который позволяет управлять Android устройством через терминал. Подключаешь [музыка] телефон к ПК и можешь выполнять команды logcat - снять логи. Pull забрать файл, скрин - сделать скрин. Скрин recordкоord записать экран. Удобно, когда нужно быстро проверить, что происходит под
Speaker A
капотом, без лишних кликов. Firebase - это платформа от Google, где через app-тестер устанавливают билды, а вкрашлитик смотрят краши, какие устройства, какая версия, какая ошибка.
Speaker A
Очень выручает, когда приложение падает не у тебя, а у пользователей. Режим разработчика есть и на Android, и на iOS. На Android он включается так: настройки, о телефоне, номер сборки и жмёшь по нему семь раз. Пока не появятся [музыка] сообщение, вы стали
Speaker A
разработчиком. После этого откроется новое меню, где можно включить USB-отладку, [музыка] передачу файлов и им имитацию разных багов. На iOS тоже можно включить devвед прямо в настройках. Настройки, конфиденциальность и безопасность, режим разработчик. После активации iPhone попросит перезагрузку и можно запускать
Speaker A
тестовые билды, подключать X-Cд и отлаживать приложение прямо с телефона. Также на собеседованиях часто спрашивают про жизненный цикл приложения. как на iOS, так и на Android. Это, по сути, набор этапов, которые проходят приложение или от момента запуска до полного завершение работы. OS - это
Speaker A
состояние note running, [музыка] inactive, active, background и suspended. В Android жизненный цикл Activity, который проходит последовательность on Create, On start, on resume, on pause, Onstop и On destroy. При первом запуске выполняется Oncreate, on start и on resume. Если
Speaker A
пользователь сворачивает приложение, вызывается on pause и on stop. Когда приложение закрывается полностью, система завершает работу через Onestroy.
Speaker A
Теперь главный вопрос. Зачем тестировщику это знать? Понимание жизненного цикла помогает точно определить, в какой момент произошёл дефект. Например, если приложение падает при сворачивании, значит, [музыка] проблема в переходе между onp и он. Если интерфейс ломается после поворота экрана, значит Activity пересоздалось.
Speaker A
Он destroy, on create и не всё состояние восстановилось. На iOS аналогично можно понять, произошло ли зависание при переходе из EC в backкграунд или уже в suspended. Когда тестировщик понимает, в каком состоянии и на каком этапе произошла ошибка, ему проще локализовать
Speaker A
баг, предположить его источник, UI, логика, сеть, кэш и передать разрабу на доработку. Часто на собесах спрашивают, как подобрать банк устройств под тестирование приложения. Основной подход к формированию банкустрой строится по уровню данных. Сначала смотри внутреннюю статистику, если она у тебя есть. Какие
Speaker A
модели, версии ОС и устройства чаще всего используют реальные пользователи? Если своей статистики нет, обратись к данным из стора Google Play, App Store.
Speaker A
Там можно увидеть агрегированную информацию о версиях операционных систем, моделей телефонов и распределения устройств по типам. Если и этих данных нет, используй региональную статистику рынка. Посмотри, какие бренды и модели наиболее популярны в твоём регионе, чтобы твой банк устройств отражал реальную картину аудитории.
Speaker A
Кроме источников данных важно учитывать и технические факторы. Во-первых, вендеры и бренды. Старайся иметь хотя бы по одному устройству от каждого крупного производителя: Samsung, Xiaomi, Apple, Huawei и других. Во-вторых, класс устройства. Включай слабые, средние и флагманские модели, чтобы тестировать
Speaker A
производительность и стабильность на разных мощностях. Также обрати внимание на разрешение экрана и плотность пикселей, чтобы убедиться, что адаптивная вёрстка отображается корректно. Не забывай о разных форм-факторах: смартфоны, складные устройства, fold, flip и планшеты. На них часто проявляются отдельные баги
Speaker A
интерфейс. И, наконец, версии OS. Важно тестировать не только последнюю, но и предыдущие версии, особенно, если приложение рассчитано на широкую аудиторию, где пользователи не всегда обновляют систему. Полезные ресурсы, где можно собрать статистику и подобрать устройство. Android Distribution Dashboard от Google - это распределение
Speaker A
устройств и версии Android на Google Play. App Analytics App Store Connect - это от Apple. Статистика по версиям iOS, устройствам и активности пользователей.
Speaker A
Stat Counter - это глобальная статистика по устройствам, разрешениям и брендам с разбивкой по регионам. и Браузер Stack Device Pressets. Готовые подборки устройств и конфигураций под разные бюджеты и типы тестирования. Для повторения перечислим, какие вопросы тебя спросят на собеседовании. Разница
Speaker A
между мобилками и вебом. В чём специфика мобильного тестирования? Как у вас доставлялись приложения? Как вы тестили БК на мобилках? Как подобрать банк устройств? Какой жизненный цикл у Activity? Тестировал липлинки? Если да, то как? В чём разница между симуляторами, эмуляторами и реальным
Speaker A
устройством в тестировании? На этом наше увлекательное путешествие в мир мобильного тестирования заканчивается. Спасибо, что досмотрел до конца. Желаю тебе удачи в покорении новых [музыка] коренных высот. И, я надеюсь, ещё увидимся.
Speaker A
Сейчас мы переходим к более технической, но не менее важной теме, предвинутым инструментом, который должен знать каждый современный Qнженер. Мы детально разберём три ключевых направления: CCD процессы, работу с логами и основы тестирования Кавка. Если ты думаешь, что эта тема только для разработчиков или
Speaker A
девопсов - это большое заблуждение. Понимание этих инструментов отличает начинающего тестировщика от настоящего профессионала, который может находить сложные баги, понимать архитектуру системы и эффективно взаимодействовать с командой.
Speaker A
Давайте начнём с фундаментального понятия CCD - это не просто модное слово, а реальный процесс, который кардинально меняет подход к разработке и тестированию. CCD расшифровывается как continuous integration и continuous delivery либо deployment, то есть непрерывная интеграция и непрерывная доставка либо развёртывание. Давайте
Speaker A
разберём каждую часть отдельно. Continuous integration - это практика, при которой разработчики часто отправляют свой код в общий репозиторий.
Speaker A
Представьте, что у вас есть команда из десяти разработчиков, и каждый работает над своей частью функционала. Если они будут выливать изменения раз в месяц, это будет катастрофа. Вместо этого они делают это ежедневно, а иногда по несколько раз в день. Что происходит?
Speaker A
После каждого изменения запускается автоматический процесс, который включает в себя три ключевых этапа: сборку проектов, запуск тестов и анализ кода на ошибки и соответствие стандартам.
Speaker A
Главная цель C - быстро обнаружить ошибки при интеграции нового кода до того, как он попадёт в продакш и дойдёт до пользователей нашего продукта.
Speaker A
Давайте рассмотрим конкретный пример из жизни тестировщика. Ты написал автотесты для новой фичи, сделал пуш в GitHub.
Speaker A
Далее происходит магия C. Твой код автоматически собирается, запускаются все тесты и твои, и разработчиков, и через несколько минут ты получаешь отчёт. Всё прошло успешно, отлично. Если нет, ты сразу видишь, что сломалось, и можешь оперативно исправить. Теперь перейдём к CD. Continuous Delivery. Это
Speaker A
следующий шаг после C. После того, как код прошёл все проверки, он автоматически подготавливается к релизу, создаётся сборка, артефакты. Всё это может быть автоматически установлено на тестовый стенд. В случае continuous deployment развёртывание в production также происходит автоматически. В случае
Speaker A
Continuous Delivery по нажатию кнопки главная цель CD - это обеспечить быструю, безопасную и автоматическую доставку изменений в коде от разработчика до продакшн среды с минимальными рисками и задержками.
Speaker A
Давайте разберём C pipйine на уровне отдельных шагов, которые происходят после каждого комита в репозитории.
Speaker A
Представьте завод с идеальным конвейером. На каждой станции свой робот. Каждый робот выполняет чёткую функцию. Это и есть CPй. Сейчас вы инженеры этого конвейера. Первый этап Cплайна. Инициализация окружения.
Speaker A
Представьте, что перед каждым изменением создаётся стерильный рабочий стол. Ни одной старой бумаги. Это и есть инициализация окружения. Если говорить конкретнее, создаётся чистая виртуальная машина или контейнер, устанавливаются необходимые зависимости, клонируется репозиторий с последними изменениями, настраиваются переменное окружение и секреты. Кстати, подумайте, почему важно
Speaker A
начинать каждый запуск в чистой комнате? Что произойдёт, если там останется старая конфигурация? И напишите обязательно ответ в комментариях. Второй этап Cплайна- статический анализ кода.
Speaker A
Этот этап как медосмотр для кода. Мы измеряем температуру, ищем аритмии, ищем аллергию на небезопасные библиотеки.
Speaker A
Если говорить конкретнее, проверяется синтаксис и стиль кодирования, проходит анализ безопасности, проверяются уязвимости в зависимостях, измеряются метрики качества, покрытие тестами, сложность кода, технический долг. Третий этап Cйплайна. Сборка проект. Мы собрали все ингредиенты. Теперь готовим блюдо.
Speaker A
Код компилируется, превращается в артефакты, то есть в готовый продукт. Если говорить конкретнее, происходит компиляция исходного кода. Создаются артефакты, те же докеробразы. Артефакты подписываются цифровой подписью и загружаются в репозиторий. Четвёртый этап Cйплайна. Запуск тестов. Не всё запускаем сразу и в разнобой, а
Speaker A
двигаемся от дешёвого к дорогому. Если что-то упало, дальше [музыка] не идём. Начинаем с юнит-тестов. Это быстрые, изолированные проверки отдельных компонентов. Они требуют менее 5 минут на выполнения, но обеспечивают покрытие кода на уровне не менее 70-80%.
Speaker A
Далее идут интеграционные тесты. Это проверка взаимодействия между компонентами, то есть тестирование рестапе, баз данданных и внешних сервисов. Под конец гоняем end to end тесты. Это полноценные сценарии через пользовательский интерфейс, запуск в реальных браузерах или эмуляторах, проверка критических пользовательских
Speaker A
сценариев. Пятый этап Cплайна. Анализ результатов. После полёта самолёта инженеры анализируют чёрный ящик. Ся делает то же самое, собирает отчёты, проверяет качество [музыка] и решает, летим дальше или возвращаемся на базу.
Speaker A
Происходит генерация отчётов в различных форматах: анализ качества и покрытия кода, уведомление команды о результатах, а также принятие решения о продолжении пайплайна. Рассмотрим несколько продвинутых стратегий C. Первое - это Fit Branch Workflow. По сути, безопасная изоляция изменений. Здесь каждая
Speaker A
функциональная ветка имеет свой изолированный пайплайн. Возможно, автоматическое создание тестовых окружений для ревью. И это создаёт пространство для параллельной разработки нескольких фич. Вторая - это Trunbased Development. По сути, максимальная скорость интеграции. Разработчики комитят в основную ветку несколько раз в
Speaker A
день и используют FFX для управления доступностью функционала. Это требует высокой культуры тестирования и автоматизации. Последнее - это Matrix Builds. По сути, широкое покрытие окружений. Она подразумевает параллельный запуск сборок для разных окружений. Тестирование проходит на различных версиях OS, браузеров,
Speaker A
зависимостей. Например, сборка для Windows, Linux и MacOS запускается одновременно. Мониторинг и оптимизация CI процессов. Метрики, которые мы обычно отслеживаем - это время выполнения пайплайна, время от комита до продакшена, частота развёртываний и процент успешных сборок. Инструменты мониторинга, которые мы обычно
Speaker A
используем - это встроенные дашборды Gitlabs CCD, GitHub Actions, либо специализированные решения типа DataDoc CI или Build Pulse, а также кастомные решения на основе Prometeус вместе с графана. Для оптимизации производительности используем кэширование зависимостей между запусками, параллельное выполнение независимых этапов, использование более
Speaker A
мощных раннеров для тяжёлых задач, а также инкрементальная сборка и тестирование. Давайте теперь перейдём к CD и начнём со стадий CD пайплайна.
Speaker A
Первое - это defреда, автоматическое развёртывание после успешного C. Дальше идёт тестовая среда. делаем ручное или автоматическое развёртывание для QA тестировщиков. Далее идёт стейдж -с среда. Она идентична продакшену, нужна для финального тестирования. И последнее идёт продакшн-среда. Это среда, где
Speaker A
находятся наши пользователи. Здесь проходит контролируемый релиз с мониторингом. Давайте теперь поговорим про стратегии развёртывания. Первая стратегия - это Blue Green Deployment.
Speaker A
Это как два идентичных моста через реку. Все машины едут по синему мосту, пока мы строим зелёный. Когда зелёный готов, мгновенно переключаем всё движение на него. Если обнаруживаем проблему, также быстро возвращаем транспорт на синий мост. По сути, есть две идентичные
Speaker A
среды: синяя и зелёная. Трафик между ними переключается мгновенно. В случае проблем мы быстро откатываем изменения.
Speaker A
Вторая стратегия - Caner Releases. Представьте, что вы вводите новое блюдо в ресторане. Сначала его пробует только шеф-повар, затем остальные повара, потом весь персонал ресторана. И только убедившись в качестве, вы добавляете его в основное меню. То есть происходит постепенное раскатывание на
Speaker A
пользователей на 5%, затем на 10, на 15 и так далее. Это всё ведёт к существенному снижению риска массового инцидента. Последняя стратегия- Фичафкс.
Speaker A
Фичефлаги - это как светофор на дороге. Вы можете дистанционно переключать цвета. Зелёный функционал доступен всем.
Speaker A
Жёлтый функционал доступен только тестовой группе и красный функционал выключен. Эта стратегия обеспечивает нам динамическое управление доступностью функционала, а также аб-тестирование и постепенное включение фич, а также экстренное отключение проблемного функционала.
Speaker A
Теперь, когда мы понимаем CCD, давайте поговорим о микросервисах, архитектурном подходе, который хорошо сочетается с CCD. Микросервисная архитектура - это подход, при котором приложение состоит из набора автономных сервисов одного приложения, каждый из которых отвечает за одну чёткую бизнес-функцию, разворачивается и масштабируется
Speaker A
отдельно, но общается с другими сервисами и хранит свои данные. Представьте себе компанию, где есть отдел продаж, склад, бухгалтерия и отдел поддержки. Все они работают отдельно, отвечают за свою зону ответственности, но взаимодействуют между собой. Точно также работают микросервисы.
Speaker A
Противоположный подход- монолит. Монолитная архитектура - это когда приложение разрабатывается и разворачивается как единый артефакт. Вся логика плотно связана. Все модули работают в едином процессе, используют общую базу данных. Монолит - это огромный общий офис без перегородок. Все команды сидят в одном помещении,
Speaker A
пользуются общей инфраструктурой и выходят на работу одновременно. Если в офисе погас свет, в одной зоне страдает весь офис. Представьте, что мы сделали интернет-магазин в виде монолитной архитектуры. Пользователи, товары, заказы, платежи, всё в одном огромном приложении. В микросервисной архитектуре
Speaker A
это будет разделено на отдельные сервисы. Userice для пользователей, Product Service для товаров, Order Service для заказов и Payment Service для оплаты. Каждый сервис в микросервисной архитектуре имеет свою базу данных, своё API, может разрабатываться разными командами даже на разных языках программирования. Как
Speaker A
это связано с C ICD? Очень просто. В микросервисной архитектуре каждый сервис может иметь свой собственный pipeline CCD. Например, user service имеет свой CCD, Order Service - свой CCD. Это позволяет поддерживать и быстро выпускать новые версии только необходимых компонентов, не затрагивая
Speaker A
весь проект целиком. Практическое применение CICD в тестировании. Теперь давайте посмотрим, как всё это работает на практике. Представьте себе типичный рабочий процесс. Разработчик делает push кодв Git. Это может быть новая фича, исправление бага изменения в тестах.
Speaker A
Gitсервер, например, GitHub или Gitlab автоматически запускает C Pipeline, цепочку заранее настроенных действий. Тесты прогоняются в чистом изолированном окружении, обычно в докерконтейнерах или в кубернетис для масштабируемости в изолированном окружении. Это значит, что этот процесс никак не влияет на рабочие
Speaker A
процессы, и все тесты проходят безопасно для основного продукта. Впоследствии генерируются подробные отчёты с использованием различных инструментов вроде ALР. Система показывает статус проверки. Если тесты прошли успешно, можно мрджить. Если нет, Cй блокирует мрдж. На этом этапе наступает фаза CD.
Speaker A
После успешного прохождения Сй система автоматически собирает готовый артефакт Docker Obr или пакет приложения. Артефакт последовательно продвигается по цепочке окружений. Сначала в деф, затем в тест, после этого в прот. На каждом этапе могут запускаться дополнительные проверки: функциональность, интеграционные тесты, проверки
Speaker A
безопасности и другие. Для prodдаction окружения часто используется постепенное развёртывание, такое как Canary или Bluegreen с мониторингом метрик. В случае проблем система может автоматически откатить изменения к предыдущей стабильной версии. После успешного развёртывания команда получает уведомление о завершении релиза. Что это
Speaker A
даёт тестировщику? Ну, во-первых, мгновенную обратную связь о качестве кода. Во-вторых, возможность находить баги на самой ранней стадии. И в-третьих, уверенность в том, что новые изменения не сломали существующий функционал. Популярные системы CCD, которые ты обязательно встретишь в работе. GitHub Actions, Gitlab CD,
Speaker A
Jenkins и Team City. Каждый имеет свои особенности, но принцип работы у них схожий. Переходим ко второму важному инструменту, логом. Если CICD - это процесс, то логи - это информация, которая помогает нам понять, что же на самом деле происходит в системе. Логи -
Speaker A
это записи о событиях в системе, которые приложение создаёт в процессе работы. Представьте себе чёрный ящик в самолёте.
Speaker A
Он записывает всё, что происходит во время полёта. Также логи. Они фиксируют все значимые события в работе приложения. Зачем тестировщику уметь работать с логами? Давайте рассмотрим.
Speaker A
несколько практических сценариев. Сценарий один: ты нашёл баг, но не понимаешь его причину. В логах можно найти Stackтрейс, подробную информацию об ошибке. Он покажет, в каком методе и на какой строке кода произошёл сбой. Это поможет сузить область поиска, быстрее
Speaker A
понять контекст ошибки и найти возможную причину. Сценарий два. Нужно проверить, дошёл ли запрос до бэкэнда. В логах можно найти информацию о входящих HTTP-запросах и ответах сервера.
Speaker A
Сценарий три. Тестируешь асинхронный процесс, например, отправку имейла. В логах можно увидеть, когда и с какими параметрами вызывался сервис отправки почту. И сценарий 4: столкнулся с проблемой производительности. В логах можно найти информацию о времени выполнения различных операций. Где искать логи? Это зависит от окружения. В
Speaker A
developмент среде логи могут выводиться в консоль. В тестовых и prodдаction средах обычно используют централизованные системы сбора логов ELTК. В него входит Classic search, logш и также можно использовать графана, логики и сплан. Что важно уметь тестировщику при работе с логами? Первое
Speaker A
- это фильтровать логи по уровню. Второе - это искать по ключевым словам. также анализировать стекace, понимать временные метки и коррелировать события и использовать контекстную информацию, то есть дополнительную информацию, которая помогает отслеживать цепочку событий. Поиск и анализ логов- практические сценарии. Сценарий один:
Speaker A
отладка последовательности событий. Сюда входит поиск по ID для отслеживания запроса через все сервисы, анализ временных меток для построения временной линии, выявление узких мест в обработке запросов. Например, когда мы хотим проследить за цепочкой событий внутри нашего сервиса после внедрения нового
Speaker A
функционала. И мы хотим посмотреть, как он вообще отрабатывает. Сценарий два [музыка] расследование инцидентов. Сюда входит поиск ошибок по конкретному пользователю или транзакции, анализ логов за определённый временной промежуток, сравнение поведения системы до и после инцидента, например, когда у нас произошла ошибка с какой-нибудь
Speaker A
конкретной сущностью: заказ, товар, пользователь и так далее. Сценарий три- мониторинг производительности. Сюда входит поиск медленных запросов по времени выполнения, анализ паттернов использования ресурсов, выявление периодических проблем производительности. Например, когда у нас есть какие-то систематические баги, связанные с производительностью, или
Speaker A
высокий процент ошибок, связанных с временем ожидания ответа от сервера, и так далее. Небольшая практическая задачка- расследование инцидента с потерянными заказами. Симптомы.
Speaker A
Пользователь сообщает о пропавшем заказе после успешной оплаты. Шаг один - это сбор информации. Мы определяем временной промежуток инцидента. Мы ищем ошибки в логах, которые связаны с ID нашего проблемного заказа. Тут это ID 124. Шаг 2 - это анализ временной линии.
Speaker A
Поставьте видео на паузу и подумайте, в чём может быть проблема. Давайте к объяснению. Обратим внимание на все логи с ID заказа 124. Как мы можем видеть, платёж был успешно подтверждён. Однако статус заказа не обновился из-за слишком долгого ожидания ответа от базы данных.
Speaker A
Такая ошибка распространена при проблемах с интернет-соединением. Система попыталась ещё раз обновить статус заказа, но при повторном запросе база данных не смогла найти запись по этому заказу. Вывод: [музыка] вероятная проблема нестабильное сетевое взаимодействие между сервисом базой данных, что привело к задержке и
Speaker A
последующей потере консистентности данных. Теперь перейдём к самому сложному, но и самому интересному. А Кавка. Если ты работаешь в компаниях со сложной распределённой архитектурой, ты обязательно столкнёшься с Кавкой. Что такое Кавка? Это распределённый потоковый брокер сообщений, который позволяет различным системам
Speaker A
обмениваться данными в реальном времени. Представьте себе почтовое отделение, которое принимает письма от отправителей и доставляет их получателям. Кавка работает по похожему принципу, только делает это в масштабе миллионов сообщений в секунду. Основные сущности в Кавка, которые нужно понимать тестировщику. Топик - это категория или
Speaker A
поток, в которую публикуются сообщение. Можно думать о нём как о таблице в базе данных или папке в почтовом ящике.
Speaker A
Партиция - это часть топика, неизменяемая упорядоченная последовательность сообщений. Именно партиции позволяют Кавка масштабироваться и обрабатывать сообщения параллельно. Сообщение - это основная единица данных в Кавках.
Speaker A
Состоит из ключа, но он не обязателен. Значе, таймстемпа и метаданных. Продюсер - это приложение, которое публикует сообщение в топик. Конюмер - это приложение, которое читает сообщения из топика. Также есть группа консюмеров.
Speaker A
Это механизм объединения потребителей для масштабирования обработки. Также есть две системы управления метаданными. Крафт или же Кавкара. Более современно используется в версии 4.0 и далее. Это встроенный механизм управления метаданными. И ZOKI, более устаревшая технология, используется в версиях 391 и
Speaker A
ниже. Это внешняя система координации для управления метаданными. Основная разница в том, что раньше ZKкипер был внешней системой отдельной откавки, а теперь он заменён на новый встроенный механизм крат, который делает то же самое, но уже внутри Кавки без отдельного зукипера. Представьте, что
Speaker A
Кавка - это огромный логистический склад с конвейерными лентами. Каждая лента - это топик. Например, заказы или уведомления. Эти ленты разделены на параллельные дорожки, партиции, что позволяет обрабатывать несколько заказов одновременно, не создавая очередей.
Speaker A
Когда приходит новый заказ, продюсер, то есть система оформления заказов, помещает его на соответствующую ленту.
Speaker A
Каждое сообщение содержит ключ, например, ID пользователя, который гарантирует, что все заказы одного клиента будут обрабатываться в одной партии, сохраняя порядок обработки.
Speaker A
Конюмеры - это команды курьеров, которые забирают заказ с лент. Если курьеров несколько, ну, то есть группа консюмеров, они распределяют между собой работу. Каждый забирает заказы только со своей партией. Это предотвращает ситуацию, когда два курьера забирают один и тот же заказ. Роль крафта
Speaker A
изукипера в этом всём деле, это как если бы на склад пришёл новый сотрудник-продюсер. Он ещё не знает, от кого по ссылке на какую конвейерную ленту выкладывать, и он идёт в такую адресную книжку смотреть, куда же ему что класть. Что особенно важно для
Speaker A
тестировщика, Кавка хранит все сообщения определённое время, даже если они уже были обработаны. Это как камеры наблюдения на складе. Вы всегда можете перемотать плёнку и посмотреть, что происходило вчера или неделю назад. Если консюмер заболел и перестал работать, сообщения будут накапливаться в топике,
Speaker A
а когда он выздоровет, продолжит чтение именно с того места, где остановился благодаря офсетам. Это специальные метки, такие позиции в партиции. Такой подход обеспечивает надёжность. Даже при сбоях в работе отдельных систем данные не теряются, а просто ждут, когда получатель сможет их обработать. Для
Speaker A
тестировщика это означает необходимость проверять не только корректность доставки сообщений, но и работу механизмов повторной обработки, балансировки нагрузки и восстановления после сбоев. Теперь давайте поговорим о самом главном. Как тестировать системы, использующие Кавка. Когда мы говорим о тестировании Кавка, мы должны понимать,
Speaker A
что работаем с распределённой системой, где данные постоянно перемещаются между различными компонентами. Мы можем разделить тестирование на два основных подхода: по компонентам и по принципам работы. Тестирование по компонентам включает в себя проверку топиков.
Speaker A
Необходимо убедиться, что сообщение попадает именно в тот топик, который указан в требованиях, что топик создан с правильным количеством партиций.
Speaker A
Проверку партионирования, то есть сообщения с одинаковым ключом, должны попадать в одну и ту же партицию. Это обеспечивает порядок обработки для этого ключа, проверку сообщений, то есть ключ, значение и заголовки сообщения должны соответствовать ожидаемым форматам.
Speaker A
проверку консюмера. Он должен быть подписан на корректный топик, правильно обрабатывать сообщения и корректно реагировать на ошибки. Проверку продюсера. Он должен отправлять сообщения в правильный топик в соответствии с выбранной гарантией доставки, но об этом я расскажу далее.
Speaker A
Тестирование по принципам работы включает в себя проверку порядка обработки, так называемой FIFO. В рамках одной партиции сообщения должны обрабатываться в строгом порядке следования. Затем мы переходим ко второму виду тестирования по принципам работы- это тестирование гарантии доставки сообщений. В Кавка существует
Speaker A
три основных типа гарантий: at most ones, at least ones и exactly ones. At most ones означает, что сообщение может быть потеряно, но никогда не будет доставлено дважды. Это как отправить письмо без уведомления о вручении. Вы не знаете, дошло ли оно. Это listes
Speaker A
гарантирует, что сообщение будет доставлено хотя бы один раз, но возможны дубликат. Это уже похоже на отправку письма с уведомлением. Если уведомление не пришло, вы отправляете письмо снова.
Speaker A
И exactly once это золотой стандарт, когда сообщение доставляется ровно один раз. Достигается это за счёт транзакций ипотентности продюсеров. Важно проверять, что сообщение с одинаковым ключом всегда попадает в одну и ту же партицию. Это обеспечивает сохранение порядка обработки для связанных
Speaker A
сообщений. Например, все сообщения о конкретном заказе должны обрабатываться последовательно. Давайте также рассмотрим тестирование отказоустойчивости и тестирование производительности Кавка.
Speaker A
Кавка проектировалась как распределённая система, способная выдерживать сбои. Мы должны тестировать, что происходит при отказе отдельных брокеров, как система ведёт себя при проблемах с сетью, как быстро происходит перевыбор лидеров партий. Особое внимание стоит уделять тестированию консюмеров и их групп.
Speaker A
Консюмеры - это приложения, которые читают сообщения из Кавка. Когда несколько консюмеров объединяются в группу, они распределяют между собой нагрузку по обработке партиций. Важно тестировать процесс ребалансировки. Что происходит, когда к группе подключается новый консюмер или когда один из существующих отключается? Ещё один
Speaker A
важный аспект - это мониторинг отставания консюмеров. Конюмерлак. Он показывает, насколько консюмеры отстают от продюсеров в обработке сообщений.
Speaker A
Если это отставание постоянно растёт, это сигнал о проблемах с производительностью. При тестировании Кавка мы тоже должны учитывать работу со схемами данных. Когда используется Авро или Протобав, нужно проверять совместимость версий схем, чтобы старые консюмеры могли читать сообщения от новых продюсеров. При тестировании
Speaker A
производительности Кавка важно учитывать множество факторов: размер сообщений, настройки батчинга, количество партиций, факторы репликации. Нагрузочное тестирование помогает определить предельные возможности системы и выявить узкие места. Важно помнить, что тестирование Кавка - это не только проверка технической составляющей, но и понимание бизнес-логики, которая
Speaker A
реализована поверх неё. Нужно понимать, какие данные передаются, как они преобразуются, какие последствия могут быть от потери или дублирования сообщений. В реальных проектах тестирование Кавка часто связано с миграцией с монолитной архитектуры на микросервисную. В таких случаях особенно важно тщательно тестировать
Speaker A
согласованность данных и корректность обработки сообщений во всех компонентах системы. Инструменты для тестирования Кавка, который должен знать каждый тестировщик. Для тестирования всех этих аспектов существуют различные инструменты. Это и визуальные клиенты для просмотра топиков и сообщений, и консольные утилиты для ручной отправки и
Speaker A
чтения сообщений, системы мониторинга для отслеживания метрик в реальном времени. Визуальные клиенты для анализа данных в топиках используются, когда нужно быстро исследовать сообщения, ключи, таймстемпы, офсеты, партиции и сериализацию. Я могу выделить такие, как Cafka UI, Offset Explorer и CDOP.
Speaker A
Консольные утилиты Кавка для ручного взаимодействия используются, когда нужно сымитировать продюсера или консюмера вручную и проверить поведение брокера, ретрай, продиционирование. Я могу выделить такие, как Кавка консольпродюсер и кавка консоль consumer. Это must have для проверкийсов, таких как пустой ключ, очень большое
Speaker A
сообщение, задержка, рекный формат или ретрай. Системы мониторинга и метрик используются, чтобы отслеживать состояние и производительность Кавка в реальном времени. Лаги, количество сообщений, ошибки, отставание консюмеров и перераспределения. Я могу выделить такие, как графана, Prometeus, Conductor [музыка] Matrix и DataD. Давайте
Speaker A
рассмотрим несколько реальных инцидентов из практики [музыка] и извлечём из них ценные выводы для тестирования распределённых систем. Первый инцидент произошёл в системе обработки заказов.
Speaker A
Из-за ошибки в конфигурации ретрав консюмер постоянно перезапускался и обрабатывал одни и те же сообщения снова и снова. В результате некоторые пользователи получили по несколько одинаковых заказов. Вывод: всегда тестируйте сценарии с повторной обработкой сообщений. Убедитесь, что ваши консюмеры импотентны и могут
Speaker A
безопасно обрабатывать дубликат. Второй инцидент был связан с миграцией схемы сообщений. При обновлении схемы добавили обязательное поле, но старые консюмеры не были готовы к этому. В результате обработка сообщений остановилась. Вывод: всегда тестируйте обратную и прямую совместимость схем. Третий инцидент
Speaker A
произошёл из-за network partition между дата-центрами. Репликация между кавкой и кластерами прервалась, но продюсеры продолжили отправлять сообщения. Когда сеть восстановилась, возник конфликт данных. Вывод: тестируйте сценарии сетевых разделов и убедитесь, что ваша система может корректно восстанавливаться после них. Подводя итоги, хочу подчеркнуть, современный
Speaker A
тестировщик - это не просто человек, который кликает по интерфейсу. Это полноценный инженер, который понимает архитектуру системы, знает инструменты разработки и умеет находить проблемы на всех уровнях: от пользовательского интерфейса до подтоков данных в Кавках.
Speaker A
CCD Логи и Кавка - это не просто модные слова, а реальные инструменты, которые помогут тебе находить сложные баги, понимать систему в целом и эффективно коммуницировать с разработчиками. Не бойся углубляться в технические детали.
Speaker A
Именно это отличает хорошего тестировщика от великого. Каждый из этих инструментов открывает новые возможности для поиска багов и улучшения качества продукта. Если есть вопросы, пиши в комментариях, я с радостью на них отвечу. Удачи в изучении и помню, лучшая инвестиция - это инвестиция в свои
Speaker A
знания. Это снова я. вы уже знаете, как устроено тестирование, и готовы искать первую работу, если, конечно, не сразу промотали до этого раздела. Теперь давай поговорим о том, почему работа тестировщиком действительно стоящий выбор в 2025 году. Первое - это
Speaker A
зарплата. По статистике Джун может рассчитывать на 50-70.000 со старта, но самое интересное начинается дальше. К уровню midл зарплата растёт практически в 2 с по раза. Ну а учитывая реалии текущего рынка, устраиваться ты, скорее всего, будешь на медла, поэтому это та
Speaker A
зарплата, которой ты можешь ожидать. Второе - это удалёнка. Согласно статистике, 67% вакансий тестировщиков предполагают удалёнку, а значит, ты можешь работать из путешествий, из дома или даже из другого города от офиса компании. Это, кстати, довольно важный бонус, потому что, опять же, по
Speaker A
статистике, наибольшее количество вакансий у нас располагаются в Москве и Санкт-Петербурге. По регионам их меньше, зарплата там, соответственно, тоже меньше из-за региональных коэффициентов.
Speaker A
Но если ты на удалёнке работаешь на МСК, зарплату ты получаешь по здешним вилкам. Давайте сразу заземлимся. Не стоит мечтать об удалёнке, где вы с пляжа, с коктейлем, из кокоса сидите и отвечаете на звонки и что-то там тестируете. Это,
Speaker A
конечно, красивая картинка, которую нам пытаются продать авторы всяких курсов, но всё-таки в удалёнке есть свои плюсы: отсутствие дороги до офиса, работа в комфортной домашней обстановке. Также много вакансий предполагают работу гибрид. Это когда ты сам выбираешь, в какие дни ты в офисе появляешься.
Speaker A
Например, когда есть важные митинги с командой или там релиз, а в какие дни ты никуда не едешь, встаёшь, открываешь компьютер и просто начинаешь работать.
Speaker A
Понимаю, что для людей, которые пришли из других сфер, из офисов или из физической работы, где надо что-то руками делать, удалёнка звучит как наеба.
Speaker A
>> Но на самом деле это не так. Во многих IT-офисах сейчас есть политика, что у людей нет закреплённого за ними места.
Speaker A
Это как-то там по-модному называется, типа деперсонализированный OpenAC. >> Чего? >> Что это означает? По факту, что мест в офисе прямо на всех сотрудников не предусмотрено. Наоборот, когда ты приходишь, ты заранее выбираешь, где ты будешь сидеть, там сидишь, уходишь, и на
Speaker A
следующий день на этом месте уже новый человек может сидеть. То есть сами компании заинтересованы в частичной удалёнке сотрудников, потому что всё равно в компанию нанимаются со всей России. Никто не стремится перевести всех разработчиков в один конкретный офис. И смешно, но даже если ты будешь
Speaker A
ходить в офис, скорее всего, на планёрках и митингах у вас всё равно будет включен какой-нибудь софт для звонка, потому что часть команды будет работать из других городов, мест или вообще из дома. Третье, не надо учиться кодить. Я могу раскрыть этот плюс
Speaker A
немного, потому что много общался с тестировщиками и программистами. В общем, основное отторжение у людей, которые пытаются стать айтишниками, конечно же, вызывает код. Потому что помимо просто каких-то умных слов или правильного синтаксиса языка, нужно понимать и втыкаться в какие-то
Speaker A
абстракции, типа там цикл, функция. Я, конечно, понимаю, что если ты продвинут, ты всё это уже знаешь, но даже лично у меня были ученики, которым вот можно 2 недели подряд объяснять, что такое функция. Они вроде бы кивают, но по-прежнему не понимают этого, потому
Speaker A
что, ну вот не укладывается эта концепция как-то в голове, скажем, пока этот блок знаний не будет пробит и пока вот они как-то в голове не сложатся, программировать очень трудно. Поэтому наибольший процент людей, которые когда-то в IT пытались войти, но
Speaker A
разочаровались и сдались, сказав, что всё это прогрев гоф. Вот это, конечно, в программировании. Ну, потому что ты вот месяц пытаешься язык понять, 2 месяца язык пытаешься понять, через 3 месяца понимаешь, что я по-прежнему не могу ничего сам написать, только с подсказкой
Speaker A
из чат GPT. Да ну его нахер. Это какая-то сложная тема. В тестировании же, напротив, ручное тестирование не требует понимания каких-то абстракций.
Speaker A
Да, лексикон, который мы выше обсуждали и термины, но вот прямо научного такого технического образования не предполагает. Изучил ручное тестирование, уже можешь идти на собеседование и с успехом их закрывать.
Speaker A
Четвёртое - это реальные перспективы. Я не хочу тебя пугать. Ты только что посмотрел сложный материал, делал домашки, учился. Но обычно в понимании людей работа - это что-то такое, куда ты вот как бы приходишь, работаешь и, ну, может там на Новый год чуть-чуть
Speaker A
зарплату поднимут, проиндексируют, да, может быть, премию начальник выпишет. >> А мне что-то за это будет. Тебе ничего не будет за это. Просто почёт и респект бесконечный.
Speaker A
>> Но в целом вот как бы на какую зарплату мы пришли, на той мы и работаем там до скончания веков, условно.
Speaker A
>> Просто денег нет сейчас. >> IT - это совсем про другое. Здесь ты приходишь и начинаешь участвовать в большой такой вот гонке по зарплатам.
Speaker A
Добавляешь к своему резюме и портфолио новые навыки, термины, изучаешь новые области знаний и постоянно шагаешь на следующую ступеньку по доходу. пока не упрёшься в зарплатный потолок, но и там есть дальнейшие лестницы, просто уже они как бы не для всех, более сложные.
Speaker A
Перспективы тестировщика таковы. Это, во-первых, рост додла и синьора по ветке просто ручной тестировщик. Далее можно обучиться автотестам на понятных концепциях тебе тестах, понять, как это запрограммировать и автоматизировать.
Speaker A
Тут уже, да, разработка всё-таки войдёт в твою жизнь, но вход в неё будет, так сказать, плавным из-за общего уровня насмотренности. Ну и давайте честно, из-за того, что зарплату ты уже получаешь и не в подвешенном состоянии находишься, тебе гораздо легче что-то
Speaker A
новое изучать, потому что ты как бы в сейфспейсе, комфортно что-то учишь, пробуешь, спрашиваешь у старших коллег автотестировщиков, они тебе что-нибудь помогают, и в результате навык получается гораздо легче, чем если бы ты изучал это с нуля. плюс QA, как мы ранее
Speaker A
упоминали, интегрируется во все процессы внутри команды. QA общается и с аналитиками, и с менеджерами, и с разработчиками, и с темледами, да, короче, со всеми. Бывает, что даже с маркетологами. Если ты вдруг пропустил это, пожалуйста, перемотай повыше и посмотри заново. Эта насмотренность даёт
Speaker A
тебе общее понимание, как работает бизнес. Скажу кромольную мысль, многие разработчики сильно проигрывают по уровню насмотренности на компанию, бизнес, продукт, процессы тестировщикам, потому что они сидят, свой код пилят, залили фичу, протестировали, вот и всё, а тестировщик со всеми бегает, общается.
Speaker A
Зачем тебе эта насмотренность? Потому что далее, если вдруг тестирование тебе наскучит, у тебя открываются интересные карьерные возможности. Ты можешь свичнуться в аналитика, в продуктового менеджера, в разработчика через автотесты. Короче, все ветки открыты, потому что ты уже всё знаешь. И на этом
Speaker A
фундаменте гораздо легче дотягивать необходимые компетенции, чтобы сменить специализацию. Короче, хочешь, оставайся в комфортном тестировании, работай, переключайся между компаниями, ищи зарплату побольше. Хочешь каких-то других задач? Выбирай понравившуюся сферу и свичись туда. А ещё, если есть знания английского, можно попробовать
Speaker A
себя на рынке валютных удалёнок и работать на удалёнке на зарубежья и получать доллары либо евро. Тут, конечно, есть страх, что >> английского не хватит. О, боже мой.
Speaker A
>> Ну не переживай, специально для тебя, у нас внутри сообщества есть сервис по обучению английскому языку. Так, оно очень-очень, >> где учим не всякие слова типа там собака кошка и не листаем дуалинга, а стараемся натаскаться конкретно на прохождение
Speaker A
собеседования, потому что собеседование - это самый сложный момент. Дальше уже общение с командой в чате, там можно и через чат GPT что-то переводить, и в переводчики смотреть. Короче, наш английский рассчитан именно на то, чтобы грамотно отчитаться за свою экспертизу
Speaker A
на собеседовании. >> Tomor, ну, Tomor сейчас митинг будет EUR Association. National. >> Как устроено собеседование на QA? Теперь про собеседование. Во-первых, скорее всего, тебя ждёт несколько этапов.
Speaker A
Исключение составляет совсем маленький процент компании, где за одно собеседование принимается решение о том, брать тебя или нет. База, такой среднестатистический вариант - это собеседование с HR на полчаса, выполнение тестового задания и потом техническое собеседование на час.
Speaker A
Собеседование с HR - это, извините за прямоту, проверка на дебила. То есть тебе задают базовые, простейшие вопросы и просто проверяют, что ты хотя бы два слова связать в состоянии и что ты не какой-нибудь студент, который прошёл один курс и теперь
Speaker A
думает, как он классно будет срочносрочно работать тестировщиком. Помимо базового вопроса расскажите о себе, на который ты отвечаешь идеально отрепетированной легендой, в который рассказываешь какой-то классный специалист, могут задать простые технические вопросы. Например, расскажите, что такое тестирование, расскажите, какие вы знаете методологии
Speaker A
разработки и расскажите, какие виды тестирования бывают. Важно здесь HR просто ожидает от тебя базового понимания и уверенного рассказа про всё это. Ответы на вопросы, которые тебе могут задать на этом этапе, уже есть в этом курсе. Важно понимать, что да, они
Speaker A
не сложные, но не нужно в тупую заучивать формулировку. Нужно понимать, о чём ты говоришь, и уметь это объяснить, не знаю, маме, папе, так, чтобы они поняли, потому что HR может задать какой-нибудь каверзный вопрос или переспросить, например, объясните, в чём
Speaker A
разница между двумя системами. Мы это тоже обсуждали, да, но просто выдать определение с Википедии, с крама или от Джайла не получится. Нужно уметь что-то проанализировать и подстроиться под гибкий вопрос, выдав ответ, который, ну, покажет, что ты не верблюд и
Speaker A
действительно что-то знаешь. Теперь про тестовые задания. Тут, конечно, можно сказать: "Блин, это какой-то обман. Меня просят поработать бесплатно, сделать какое-то там тестовое задание, которое займёт моё бесценное, драгоценное время.
Speaker A
Не оплачивают ещё его. К тому же я не хочу этого делать. Мы не будем сейчас дискутировать на эту тему. Это видео не про это. Просто скажу, что сейчас большинство компаний предложит тебе делать тестовое задание, и отказавшись от него, ты очень сильно сузишь свою
Speaker A
воронку найма. Для начинающего тестировщика тестовые задания обычно такие: напиши багрепорт по такому-то багу, протестируй API Google [музыка] и составь тесты по таким-то требованиям.
Speaker A
Это примерно, если тебя интересует прямо конкретная формулировка тестового задания до начала похода по собеседованием, что ж, мы выложим несколько на бусте. Плюс, ну, интернет ими полнится, потому что сотрудники эти тестовые задания выкладывают, интервьюируемые эти тестовые задания выкладывают, компании их иногда
Speaker A
выкладывают, короче, они прямо типовые и все под копирку примерно. Помни, что тестовое задание - это вот как бы всё выполнение задания. То есть нужно не просто решить задачу, но грамотно структурировать информацию, провести коммуникацию. То есть просто скинуть какой-то рандомный файл, где-то что-то
Speaker A
накалякал. Наверное, будет плохим здесь вариантом. Пожалуйста, не теряй эти выполненные тестовые задания, подшивай их в какое-нибудь портфолио, сохраняй. У меня, ну, я правда iOS разработчик, пару раз прокатывало что-то типа: "Да, хорошо, вот я понимаю, вы хотите мне дать тестовое задание, но у меня есть
Speaker A
почти такое же, которое я делал для другой компании". Может быть, вы просто его посмотрите и всё. Это абсолютно адекватный вопрос. Если вам скажут, что нет, делай Маше, ну, сделайте. Но порой значительное портфолио этих тестовых может вам сильно сэкономить время. Также
Speaker A
не забывайте, что иногда тестовые задание, которое дают вам, уже кто-то делал до вас и этот ответ куда-то выложил. Я не буду показывать в конкретные места, но не поленитесь и забейте формулировку вашего тестова в Google. Может быть, вам выдастся
Speaker A
какой-то конкретный ответ. Ну и в нашем сообществе, понятно, люди тоже делятся выполненными результатами. Если вы новичок, наверное, имеет смысл сделать тестовые с нуля, хотя бы раз 5-10. Но если вы уже задолбались их делать, я не вижу большой проблемы, чтобы, так
Speaker A
сказать, позаимствовать, не списывая один в один. Только не забудьте правила. На техническом собеседовании ты познакомишься с будущим руководителем.
Speaker A
Скорее всего, тебя поспрашивают по твоему тестому, почему сделал так, а недек, почему задача решена таким образом? Тебе нужно учиться его защищать. Дальше тебя начинают гонять по вопросам из списка вопросов на тестировщика, которых в целом ограниченное количество. И я бы на твоём
Speaker A
месте перед походом просто со всеми ими ознакомился и выучил. Могут начать с чего-то простого, типа, что такое баг или в чём цель тестирования. Пожалуйста, не допускай главную ошибку новичка.
Speaker A
Начать рассказывать всё обо всём. Блин, я столько знаю, я столько всего выучил. Давайте, я вам сейчас всё расскажу.
Speaker A
Собеседование - это не просто сверка правильности ответа и вопроса. Это ещё и общий анализ того, как ты умеешь общаться, как ты слышишь, что у тебя спросили: структурность, чёткость, лаконичность и правильность ответа. Всё это оценивается в совокупности. Банально человеческий фактор тоже играет роль.
Speaker A
Ну, типа, если ты будешь бурчать что-то под нос, запинаться и заикаться, конечно, так плохо выбирать сотрудников, но твой руководитель может подумать: "Блин, ну и зачем мне вот это вот бормотание будет слушать во время работы? Я хочу у кого-то, кто с
Speaker A
расправленными плечами громко и твёрдо и чётко отвечает мне на вопросы. Поэтому готовься к собеседованиям, репетируй, записывай эти собеседования, просматривай, как ты смотришься со стороны, и постоянно улучшай свою технику ответа на вопросы. Тебе могут задать типовую задачу, например, протестируй форму ввода даты рождения и
Speaker A
собери на неё объём данных для тестирования, но условие такое, что пропускаем только восемнадцатилетних. Или попросить протестировать какой-то объект реального мира, например, там цветочный горшок, окно или лифт или протестировать веб-форму. Люди обычно очень сильно стесняются и смущаются на таком вопросе, потому что ну как горшок,
Speaker A
что что ну типа ну цветок поставить. Поэтому специально для вас мы записали образец с того, как бы я отвечал на такой вопрос. Заходи на бусте, чекай дополнительные материалы. Там есть пример. Даже если ты туда не зайдёшь, я тебя прошу возьми какую-нибудь такую
Speaker A
задачу, открой перед собой камеру и запиши ответ. А потом пересмотри на свою мимику, жесты, как у тебя, возможно, косят глаза, как ты запинаешься, что-то мнёшься, слова паразиты используешь. Это правда очень важно. Многие люди думают, что просто, ну, я же как-то ответил,
Speaker A
значит, я победил. Нет. И ещё раз, нет. В текущих условиях найма с большой конкуренцией нужно работать над всеми своими косяками и недостатками, не только над техническими и теоретическими. Подытаживая и строя планы на будущее, я хочу, чтобы вы сейчас запомнили одну важную мысль. Это
Speaker A
видео не просто ещё один курс или какая-то скомпилированная солянка разномасных технических статей, которую кто-то сваял на коленке и выдал за охренительный образовательный материал.
Speaker A
Это видео скомпилированный результат работы десятка менторов PQA, которые в общей сложности вкатили там сотни учеников и помогли повысить зарплату ещё десяткам. Эти люди, они не просто рассказывают там вот теория, надо вот это выучить, вот это, было бы неплохо
Speaker A
ещё вот это, а это не надо. >> Нет, это проверяется на рынке прямо сейчас. Прямо сейчас, пока вы смотрите этот ролик. Люди устраиваются на работу тестировщиками, а менторы корректируют свою программу прямо как, извините за высокопарную метафору, но как садовник,
Speaker A
который ухаживает за своим садом. То есть ненужные гнилые росточки, какие-то вопросы, которые уже не спрашивают, мы убираем здесь. недостаточно подробно раскрыли удобрения, насыпали в программу добавили материала. И все эти люди долго-долго с дискутировали, что в программу включить, что оставить. Потом
Speaker A
мы это отсматривали, перечитывали. Это я всё к чему. Ну, во-первых, поставь, пожалуйста, лайк и подпишись на канал.
Speaker A
Но важно другое. Когда ты посмотрел это видео и освоил всё, что в нём есть, не нужно думать: "Ну, сейчас я ещё другое посмотрю, а потом третье, а потом пятое". Нет, всё, вот в этой точке ты готов к поиску работу. Надо идти и
Speaker A
пробовать как бы оббивать свои знания о реальный мир, смотреть, получать от него обратную связь и потихоньку улучшаться.
Speaker A
Если вдруг у тебя есть сомнения, и нет, нет, это всё ещё слишком страшно, я предлагаю обратиться к ментору, который будет тебя пинать, вести через всё это за ручку, контролировать, развеивать твои страхи и недостатки, ревью твои ответы на вопросы, просматривать вместе
Speaker A
с тобой записи твоих собеседований и подмечать там эти косяки. Но запомни главное, вы готовы вот прямо сейчас. Я буду рад, если это видео оказалось вам полезным и вы что-то поменяли в своих планах на вкат в IT или на обучение.
Speaker A
Пожалуйста, поделитесь в комментариях. Полезно, [ __ ] какая-то. Уже было неглубоко-глубоко. Также мы планируем записать такой же видос по автотестам, но нам от вас нужно немножко ажиотажа и желания, поэтому открой комментарии к этому ролику и найди там комментарий
Speaker A
"Никакого ручного труда" и поставь ему лайк. Ну а если такого комментария нет, значит, напиши его первым. По количеству лайков под этим комментарием мы поймём, насколько сильнее нам нужно ускориться и взять этот видос в работу, чтобы ты наконец выучил автотесты и никогда
Speaker A
больше не работал руками, если ты, конечно, понимаешь, о чём я. С вами был Антон Назаров. Большое спасибо за просмотр и начни уже зарабатывать больше.
Topics:
QA testing
software testing
quality assurance
IT mentoring
job readiness
Python programming
test automation
software development
career in IT
testing course