Тестирование ≠ QA

Еще пара моментов по помощи: 1. Могу пособеседовать на английском, чтобы уменьшить стресс от первых интервью (я в свое время нехило стрессовал) 2. Пишите, если нужно просто пообщаться/выговориться/обсудить синдром самозванца/задать вопросы по жизни в западных странах — такого было даже больше, чем самих рабочих вопросов. Второй пункт, возможно, даже более важен, так как я вижу, что люди сейчас в первую очередь пытаются найти опору в ситуации, когда мир катится куда-то не туда.

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

Почему Unity Прошло 2 года с начала работы в Unity, я поработал в трех разных командах, и сегодня хочу рассказать, почему выставил в Линкеде статус “Happy at Unity, not looking for something new”. Вдруг кто-то не знает: Unity это движок для real-time 3D. Давно уже не только игры, но и VR, AR, стройка с их digital twins, автомобилестроение, 3D эффекты в кино и прочее, где есть графика. В компании больше 7000 человек, и да, это не Google и Facebook, но из топ списка и со своей особенной культурой. Итак, почему меня до сих пор прет от работы здесь. [Для объективности и задротности надо сказать, что перед каждым пунктом можно добавить предусловие «конечно, не прямо всегда, не на 100%, не все команды, не каждый человек» и тд. Идеального не существует, но главное — общее стремление большинства, которое и вдохновляет] — Действительно следуют принципам У большинства контор это просто буквы на стене. Но не здесь. Users first — все решения преследуют одну цель — нам надо сделать лучше пользователям. Best ideas win — если сотрудники выбирают решение, но менеджер против, то выигрывают первые. Go bold — когда не зазорно упасть и быстро учиться на ошибках, двигаясь к большой цели. In it together — мы вместе идём к этой цели, наши коллеги из других команд это такие же пользователи, а Users First. — Нанимают большинство сеньоров Не по годам выслуги, а по реальному скиллу разработки. Насколько быстро идёт коммуникация, когда не нужно тратить время на разъяснения банальных вещей, а можно просто хреначить во всю силу. Чем сеньорнее становишься, тем больше это ценишь. — Дают (очень) много инженерной свободы У меня как-то был популярный твит о компании, в которой ждут добро на названия веток в гите. Так вот это — полная противоположность. Инженеры драйвят решения и сроки. Сначала обсуждаем с продуктом, какой вопрос или боль мы в принципе хотим решить, потом внутри думаем над решением в софте. Лучший код — отсутствие кода. — Фокус на потоке Есть понимание, что чем меньше инженер занят фигней à la общие собрания, тем красивее burndown chart. Нет митингов по пятницам, зато есть возможность этот день превратить в hackday, когда ты можешь это время потратить на изучение новых технологий или заняться улучшением какой-то штуки, которая нам облегчит жизнь, но в спринт такое включат не скоро. — Take care of yourself and your family first В то же время, если у вас семья с тремя детьми, кошкой, собакой и тещей, то нет вообще никаких проблем отложить работу в абсолютно любой момент, всегда коллеги подставят плечо. Также не нужно одобрения менеджера на отпуск, нужно просто предупредить команду. — Реально слушают фидбек Мы — граждане Unity с правом выражения своего мнения. Мы можем публично высказываться на острые темы и задавать вопросы топ менеджменту в том числе и лично, не боясь быть уволенным. Это одна из частей культуры Unity, к которой многие с опытом других даже топ компаний сперва не привычны. — Акции компании, зарплаты, бесконечные бенефиты Осознанно ставлю на последнее место, потому что со временем это становится нормой, а вышеописанное — нет. —— Можно возразить, что о публичной компании либо хорошо, либо ничего. Но это правда, я не вижу ни одного критичного отрицательного момента. Да и не критичного тоже.

Почему «почему» Это не опечатка. Будет серия постов с таким названием, где я расскажу: — Почему Unity: почему меня прет от работы здесь — Почему Cypress: как эти ребята подвинули Selenium, и почему стоит за ними следить, даже если вы пользуетесь другими фреймворками — Почему Hexlet: откуда доверие, и как я качаю хард скиллы программиста, не планируя становиться разработчиком

Для тех, кто выбирал Playwright вместо Cypress из-за отсутствия поддержки WebKit, есть долгожданные новости

Visual regression testing: лидер с AI на рынке: Applitools Может делать всё, что делают другие, только больше и лучше, а главное — из коробки. Да, их преимущество в изначальных инвестициях в AI, что сейчас сначала звучит как buzzword, но даже если там миллион if, оно делает свою работу. Applitools фейлит тест, который бы зафейлил человек, и в этом главное отличие от pixel-to-pixel инструментов. На данный момент они поддерживают: сайты, мобильные приложения, PDF, accessibility (Contrast Advisor). Может фокусироваться или наоборот игнорировать конкретные элементы на странице. Тесты в идеале должны быть детерминированными, однако, у этих есть возможность игнорировать динамичный контент (например, новостные сайты) и проверять саму вёрстку. Root cause анализ тоже присутствует. Плюшек много, и за это надо платить. Немало. Это главный «минус». Убедить менеджеров выделить такой бюджет чисто на visual regression — не самая простая задача. —— Мой вывод на текущий момент: Applitools это пример того, куда развивается индустрия автоматизации фронта. И именно таких вещей стоит бояться манкитестерам. Однако, кто-то всё равно будет это все настраивать и обслуживать, поэтому нужно вовремя начать качать свои скиллы в нужное же направление. Как всегда, если есть свои наработки, делитесь в комментариях!

Visual regression testing. Вторая часть: обзор инструментов. Для понимания контекста POCs, вот <задача>, которую я пытался решить — хрупкость UI у всем ненавистного баннера с куками. Это iframe, код фронта которого просто копипастой вставляется на сайте провайдера 🤯 Для каждого региона/страны/штата с уникальными настойками кук (US vs Cali с их CCPA, EU с GDPR, разношёрстный APAC, всё с «вычислением по IP») свой код. Что с локализациями и брейкпоинтами даёт множество комбинаций для унылой ручной рутины. Однако, это связано с юридической волокитой и потенциальными штрафами, поэтому бизнесу крайне важно, чтобы эта штука проверялась регулярно. Соответственно технически нужно, чтобы сервис мог фокусироваться на конкретном элементе для уменьшения потенциальных ложных падений. Однако, с немалым удивлением обнаружил, что большинство решений умеет только в full screen. </задача> Теперь про сами инструменты. Как писал в начале, есть один дорогой лидер и все остальные. Начну с этого остального. Это обычно плагины к e2e фреймворкам, делающие скриншоты в указанных местах, либо сервисы, которым указывают страницы для регулярной проверки на изменения. На деле разница в качестве не сильно большая, так как это всё это работает на основе pixel-to-pixel comparison с регулируемой допустимой погрешностью. Но и с ней это может давать false negative просто при повторных запусках на одной и той же машине. Пожалуй, все более-менее сеньорные девелоперы рано или поздно пытаются что-то подобное применить, но, на мой взгляд, именно из-за этих рандомных результатов зачастую сдаются, так как кажется, что обслуживание этого добра стоит дороже выгоды. —— Начнём с варианта «дёшево и сердито»: Cypress + бесплатные плагины #snapshot Рекомендую посмотреть этот плейлист, там Глеб, ex CTO Cypress, пошагово объясняет, как добиться стабильных прогонов на локальной машине и на CI с помощью использования контейнеров с предустановленным фреймворком и зависимостями. Пример локальной команды: $ docker run -it -v $PWD:/e2e -w /e2e cypress/included:10.7.0 На CI та же версия: runs-on: [self-hosted] container: cypress/included:10.7.0 Главная боль подобных бесплатных плагинов — менеджмент и апдейты baselines через CLI в отсутствие какой-либо админки. —— Отдельной группой идут сервисы с девайсами в облаке, они все дружно решили, что нужно иметь такую приблуду в копилке. Более-менее всё стандартно. 1. У нас на тот момент была лицензия BrowserStack, который незадолго до этого купил Percy. Не подошёл, так как могли только в full screen. 2. Полгода назад конкуренты BS, Lambdatest, начали работать над альфа-версией их собственного решения SmartUI. Тогда мы с ними коллаборировали над продуктовыми хотелками. Сейчас оно доросло до беты, но, судя по описанию, это все ещё не очень «смарт». 3. Ну и из крупных ещё SauceLabs: обещают «more than just pixels. Sauce Visual compares both screenshots & DOM snapshots to show changes». У нас с ними сразу не заладилось по некоторым причинам, поэтому фидбека не будет. —— Внезапно приятно удивил нано-стартап из Европы Happo.io Они за весьма доступный прайс дают всё, что нужно: возможность делать скриншот конкретного элемента/секции, интеграции с CI, контейнеры для десктопных и мобильных браузеров для параллельного запуска. Опенсорс бесплатно. On-premise на месте. Рекомендую попробовать. Из минусов: из коробки взлетело не всё, пришлось несколько раз уточнять какие-то обходные пути для ситуаций, в которых у других фреймворков проблем не возникало. Однако, ответы были быстрыми и точными. —— Про лидера не поместилось, читайте в третьей части ⬇️

Visual regression testing для интеграционного тестирования или Манкитестерам приготовиться Часть первая. Для кого пост: #sdet #middle #senior Давайте про что-то более сеньорное. Выложу свои мысли после нескольких POC на тему визуального тестирования для интеграций где-то на фронте. Компонетное в другой раз. TLDR: манкитестинг (наконец-то) начинает умирать, но есть нюансы. Для начала поясню за манкитестинг. Для меня это — относительно бездумный человеческий проход по чек-листам еще и на разных девайсах. Ключевое слово – “бездумный”, потому что умелое исследовательское тестирование будет жить еще достаточно долго в зависимости от прогресса и наработок по AI и, что ещё важнее, стоимости его применения. Так как вопрос у менеджмента (говорю про североамериканский, но можно экстраполировать на просто страны с высоким уровнем жизни) в снижении издержек на сравнительно несложную ручную рутину, которую так или иначе кто-то должен тащить. Тратить время высокооплачиваемых инженеров — не очень разумно, нанимать QC чисто для этого — их зарплаты и бенефиты в совокупности тоже не настолько маленькие, отдавать на дешёвый аутсорс — кто контролировал такое, поймёт боль без слов. В итоге, умное визуальное тестирование в ближайшие годы будет получать инвестиции и дальше, это 💯. Для тех, кто ещё не пробовал, пара вещей про неочевидные с первого взгляда плюсы данного тестирования. Это в теории так-то мощный инструмент, который покрывает сразу все: то, что на данном шаге логика отработала корректно на всех концах, API отдал нужные данные для всех видимых зависимых элементов, и это все вместе еще и срендерилось на нужном брейкпойнте, как нам надо. Вместо хитровыдуманных проверок наших по факту слепых e2e тестов с их отдельными кнопками и элементами, можно просто дождаться полного рендеринга контента и сравнить с эталоном. С учётом того, что тесты можно запускать в параллели либо на реальных девайсах в клауде, либо в более быстрых контейнерах (если ваши баги не ловятся при простых изменениях брейкпойнтов, привет Safari mobile), это до какой-то значимой степени элиминирует необходимость в манкитестинге. На рынке сейчас появляется всё больше инструментов, но в действительности есть один лидер за много денег с их большими вложениями в «искусственный интеллект» и все остальные. Об этом всём во второй части.

Вопрос ко всем из зала про: Performance review и метрики для тестировщиков —— Коллеги, разрешите попросить рассмотреть тему оценки производительности QA-инженера. У нас в компании любят термин "performance review", но что именно в работе QA следует оценивать и по каким критериям? Количество новых кейсов в месяц? Покрытие тестами требований или функционала? Процент автоматизации? Динамику вылавливаемости багов? Динамику багов на проде, их вылавливаемость клиентами или службой поддержки? Есть какие-то популярные практики? Какой QA в итоге — хороший QA, а не "underperforming"? —— Я свои мысли размещу в комментариях, присоединяйтесь.

Курсы по автоматизации тестирования Для кого пост: #junior up to #middle #course_automation Цены в российских рублях. —— Бесплатно Если вы всерьез планируете нырнуть в автоматизацию, я бы советовал хорошо структурированные курсы с кучей практики да еще и ментором в помощь (то есть, за деньги), потому что в этой теме просто посмотреть видео с ютуба и стать востребованным джуном, скорее всего, не выйдет либо выйдет, но долго. Однако, кое-что все же посоветую, если у вас уже есть какой-то опыт в данной сфере. Cypress, JavaScript Cypress вместе с Playwright и дедом Selenium - основные инструменты на рынке, но первый имеет отличнейшую документацию, которая грамотно подает пути автоматизации. И, помимо обучению самого фреймворка, они рассказывают, как правильно тестировать веб в принципе. То есть, даже если вы используете любой другой инструмент, будет полезно изучить доки. Также они заделали репозиторий, где есть тестовое приложение с примерами того, как писать E2E и API тесты (да, тут можно совместить). Основы основ: https://docs.cypress.io/guides/overview/why-cypress Best practices: https://docs.cypress.io/examples/examples/tutorials Много примеров того, как тестировать типовые сценарии: Recipes | Cypress Documentation Полезный блог их амбассадора с простыми объяснениями, как что работает на примерах: https://filiphric.com/blog —— QA Guru Курсы среднего уровня. Ближе к понятию Bootcamp. Продолжительность: 3 месяца. По итогу: сертификат. Формат: живое общение Один из основателей — Алексей Виноградов, давно известен в сообществе, и он же – один из контрибьютеров фреймворка Selenide. Дают самое основное: Основы языка Git Фреймворки (Selenide - обертка Selenium) Непрерывная интеграция - основы CI/CD Тестирование API Автоматизация мобилок Дипломный проект (см планы) Помощь в карьере (см планы) Цена: 3 варианта ~20000, ~30000, ~40000 в зависимости от хотелок. Java: https://qa.guru Python: https://qa.guru/python —— Яндекс Повторюсь, Яндекс это технологическая компания, так же слышал хорошие отзывы о среднем качестве выпускников. Вводная часть бесплатно. Желательно иметь опыт ручного тестирования. У Яндекса есть отдельная большая профессия инженера по тестированию с погружением в автоматизацию, об в посте про курсы по ручному тестированию. Python: веб-приложения — короткий курс, позволяет взять основы. Продолжительность: 2 месяца. Цена: 40000. https://practicum.yandex.ru/qa-automation-web-python/ Java: веб-приложения, Selenium, Git API, юнит-тесты — оптимальный набор и продолжительность Продолжительность: 5 месяцев. Цена: 65000. https://practicum.yandex.ru/qa-automation-engineer-java/ —— Skillbox К удивлению, не так много курсов по JavaScript, тем более по Cypress. Поэтому решил добавить данный от Skillbox. В программе: достаточно много JS, Selenium, Cypress, API тесты, Git, настройка CI + 2 проекта. Продолжительность: 12 месяцев, что долго. Однако, по итогу лишь сертификат, а не диплом. Цена: ~75000 В итоге: программа ок, цена и продолжительность на берегу кажутся несколько завышенными. Но если знаете курс лучше, дайте знать. https://skillbox.ru/course/autotesting-javascript/ —— Нетология Достаточно большой комплексный курс с дипломом о переподготовке по итогу и карьерной помощью. В программе вебинары, видеолекции, много практики: 238 часов суммарно. В программе оба компонента: ручное и автоматизированное: Java, Selenium, API, BDD, Unit tests. Ссылка на основную профессию: netology.ru/programs/qa Продолжительность: 8 месяцев. Цена: 78900. Кто больше хочет развиться именно в автоматизации, есть (весьма) расширенный курс «Инженер по тестированию»: netology.ru/programs/qa-middle Все 3 популярных языка автоматизации: Java и JavaScript, видеокурс по Python в подарок. Все нужные фреймворки: Selenium, Selenide, Jest, Puppeteer, Playwright, Cypress. Вспомогательные тулзы: SQL, Docker, CI/CD. Продолжительность: 15 месяцев. Цена: 159000.

Курсы по ручному тестированию Для кого пост: #entrylevel #junior #courses_manual Цены в российских рублях. —— Бесплатно На ютубе оказалось не так просто найти что-то достойное: ⁃ Основы manual QA за 10 часов с примерами тестов того, что и как тестировать ⁃ Леша Маршал ⁃ QA School 2020 ⁃ Техносфера Mail.ru Group —— Школа Портнова Отдельно указываю её, потому что школа — одна из известных и люди из Северной Америки про нее нередко спрашивают. Посмотрите записи лекции и оцените, насколько вам лично заходит подобный подход. Мне по ряду причин — нет, но это не повод не пробовать. Сайт: portnov.com Записи на ютубе —— Дешево, но с нюансами LearnQA Набор отдельных курсов по разной стоимости. По итогу сертификат. Базовые знания за неделю. Дешево и минималистично. Есть песочница на поковыряться. В целом, неплохой баланс сжатости подачи и цены для новичка, не рискующего сразу тратить кучу денег. Азы тестирования: learnqa.ru/stageone Цена: 2000 Если понравилось, у них есть курсы по направлениям: ⁃ Тестирование мобильных приложений (работают над новой версией): learnqa.ru/manual 6800 ⁃ Тестирование безопасности: learnqa.ru/security 9500 ⁃ Основы SQL: learnqa.ru/sql 4500 —— Алексей Баранцев с software-testing.ru Я сам учился у Алексея на заре карьеры на курсе по автоматизации тестирования. К тому же он один из разработчиков Selenium. Если вам подходит формат записанных лекций с поддержкой в чате, и сама подача лектора (сухо, но по делу: образец), то в курсе собрано достаточно много теории за очень умеренную цену. Курс Тестирование веб-приложений 2.0 Цена: 12000 —— Полноценная переподготовка Мой главный вопрос был бы - смогу ли я выдержать такой достаточно длинный марафон, это действительно долго, даже если в занятиях не будет воды. SkyPro от SkyEng Для тех, кому нужен диплом о переподготовке, большая программа и немало практики. Поддержка наставника, сопровождение до трудоустройства, подготовка к собесам. Время обучения: 7.5 месяцев. Цена: 80000. Много маркетинговой шелухи (как и у коллег по цеху) на этапе привлечения. Если списаться с ними и перестать отвечать, то могут предложить «грант» ещё на 10% скидки. Ссылка на презентацию с подробностями Ссылка на пробный урок Ссылка на собственно профессию —— Яндекс Я бы обратил внимание на эти курсы, так как Яндекс в первую очередь технологическая компания, так же слышал хорошие отзывы о среднем качестве выпускников. Недешево. Вводная часть — бесплатно. Bootcamp (запихать максимум в кратчайшие сроки): 2 месяца Цена: 112000 Курс «Инженер по тестированию»: 4 месяца Дипломный проект и помощь в трудоустройстве Цена: 72000 Профессия «Инженер по тестированию плюс»: 9 месяцев (диплом о переподготовке) Сильно больше заданий, включая проект от реального заказчика + автотесты на Python с изучением Git, Selenium. Цена: 124000

Краткая теория тестирования ПО Для кого пост: #entrylevel #junior В продолжение поста про 3 самые важные штуки для желающих стать тестировщиком, предлагаю почитать и иметь под рукой шпаргалку по теории: — Терминология (верификация VS валидация, что баг, что не баг, его атрибуты) — Техники тест-дизайна (состояния-переходы, таблица принятия решений, доменный анализ, и т.д.) — Виды тестирования (мильон видов) — Документация (требования, чек-листы, тест кейсы, отчет о баге) Теория тестирования ПО просто и понятно / Хабр

Чтобы все опытные не разбежались: будет ещё пара постов для джунов, и потом начнём говорить про SDET, Cypress и GitHub Actions.

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

Первый тест почти всегда исполняется для позитивного сценария, чтобы проверить, что это всё работает в принципе. Тогда вводим данные существующего пользователя и смотрим, что мы можем успешно войти в приложение. Негативный тест соответственно делается для того, чтобы убедиться, что приложение адекватно показывает ошибку в случае если мы вводим, к примеру, несуществующий email или существующий, но с неправильным паролем. Подытожив, когда мы видим задачу протестировать какую-то функциональную штуку, минимальный минимум будет заключаться в том, как оно работает (и работает ли) и как реагирует на некорректные данные/сценарии использования. ❓Задание новичкам на подумать: в случае с чайником, какими будут негативные тесты? Тоже можно в личку. То, как приложение в идеале должно бы работать, узнаем от заказчика (stakeholder), как оно было запрограммировано — у разраба, ну и в итоге даём им всем отчет о состоянии «ожидание-реальность». Наша задача — не найти все баги в мире, а именно донесение информации, с помощью которой люди решают, насколько страшно это творение выпускать на пользователей. —— На сегодня всё, про курсы для джунов будет один из следующих постов, приглашайте своих знакомых будущих тестировщиков :) И заходите в комментарии, туда, помимо прочего, буду кидать релевантные мемасы, про тестирование их тоже немало! P.S. Дополнения из комментариев: 1. Если больше подходит академическая подача, то рекомендуют книгу Святослава Куликова "Тестирование программного обеспечения". 2. Книга Савина была написана достаточно давно, поэтому некоторые моменты могут быть неактуальными.

Азы тестирования Для кого пост: #entrylevel #junior Это собственно ответ на «как начать входить» по шагам. Все сразу в одном посте не поместятся, поэтому воспользуемся методом Дудя: ТОП-3 вещи для первоначального изучения тестирования ПО. Шаг первый: прочитайте книгу Романа Савина «Тестирование Дот Ком или Пособие по жестокому обращению с багами». Рекомендую купить, так люди больше ценят то, во что вложились. Вы же серьезно хотите в тестирование, правда? В книге легким языком и в виде истории описаны все необходимые базовые штуки, с которыми сталкивается начинающий (но не только) тестер(есса). Автор в своё время работал в Штатах, поэтому информация расширит и этот кругозор. Я сам с неё начинал. —— Шаг второй: изучить и знать, как применять техники «Классы эквивалентности» и «Граничные значения». Буду давать термины сразу и на английском (всё равно все уедете, если ещё не): «Equivalence classes/equivalence partitioning and boundary value analysis». Краткое объяснение: все наборы/комбинации данных невозможно и не нужно тестировать, поэтому давайте это делать с умом — с помощью данного тест-дизайна протестируем только минимально необходимые случаи, покрыв при этом все диапазоны значений. Возьму стандартные примеры из интернета и объясню своими словами: представим, что наша программа выводит на экран состояние воды в чайнике в зависимости от текущей температуры. Для простоты, возьмём только такие условия: — 0 и ниже (чайник в морозильник): «замерзает» — 1-99: «греется» — 100 и выше: «кипит и испаряется» Из этих условий понятно, что замеряя температуру при 10, 20, 50 градусах, программа всё равно даёт один и тот же (эквивалентный) результат — покажет статус «греется». Поэтому можно сделать всего 3 теста (а не 100+), по одному на каждый диапазон: Например: •-5: замерзает, • 50: греется, • 105: кипит и испаряется. Это и есть классы эквивалентности вкратце. Однако, все опытные тестировщики знают, что разработчикам нельзя доверять почти (вообще) никогда, они вечно путаются в условиях в коде (меньше или равно нуля, больше одного и меньше либо равно 99, и т.д.). Именно здесь ловится больше всего ошибок, поэтому добавляется ещё вспомогательная техника «Граничные значения»: те, что находятся прямо на границе — справа и слева от условия, ведь от «замерзает» до «греется» всего как раз один градус. И в зависимости от того, как программист напишет эти условия, именно этот +-1 градус может оказаться в неправильном диапазоне и вызвать ошибку, где 0 покажет «греется», например. Поэтому добавим к тем трём тестам ещё и граничные градусы вокруг заданных условий: +-1 для 0, +-1 для 1, +-1 для 99 и +-1 для 100. Бесконечности не в счёт. Убираем дубликаты, и вуаля: -1: замерзает ❄️ 0: замерзает ❄️ 1: греется 🔥 2: греется 🔥 98: греется 🔥 99: греется 🔥 100: кипит и испаряется 💨 101: кипит и испаряется 💨 Эти диапазоны гораздо нагляднее рисовать и анализировать на бумаге, поэтому потренируйтесь на досуге над вот этим заданием попроще: 📚Посмотрите на форму ввода из мема выше, она принимает числа от 2 до 12. Сколько минимум тестов нужно, чтобы покрыть эти требования? Можете прислать в личку. 💡А вот еще хорошее объяснение данных техник с картинкой на английском: Equivalence classes and boundary value analysis - Crosslake 💡И на русском на примере расписания на день: Техника тест-дизайна: Классы эквивалентности (equivalence partitioning) Я вас уверяю, большинство даже сеньоров в разработке не знают/не слышали/не практикуют эти базовые вещи. А зря. По факту, данными штуками можно закрыть подавляющее число функциональных тестов, основанных на линейных данных. Поэтому для вас: практика, практика и ещё раз практика. —— Шаг третий: понять, как составлять позитивные/негативные сценарии (positive/negative). Некоторые в индустрии не любят это именование из-за того, что адекватная реакция приложения на ошибочные действия и данные это всё тоже нормальные, обычные сценарии работы без негатива :) Пример. Представим, вам дали протестировать приложение, где нужно вводить имя пользователя и пароль.

Иллюстрация для поста «Азы тестирования»

Сделал лого, отражающее суть нашей профессии

Входоки в айти через тестирование. Часть 1: как понять, что это твоё Для кого пост: #entrylevel Все годы, что я в тестировании, получаю вопросы на тему «как понять, что это моё» и «с чего вообще начинать». Среди этих людей много тех, кто считает, что тестирование это лёгкий способ и в общем-то без особых знаний путь как-то войти в наши конюшни с хорошими зарплатами и прочими ништяками. Программирование или там дизайн это всё как-то сложно, а тут вроде где-то даже случайно клацаешь и что-то же обязательно находишь. И внезапно… это правда в общем и целом. Подробнее будет в посте про эфемерность качества и магию QA, а пока давайте по порядку. Сегодня остановимся на первом вопросе: как понять, что тестирование это твоё, и это то, чем можно заниматься годами, и к тому же не сойти с ума от рутины. Главное — все ли смогут идти в тестирование? Мой ответ: нет, однако, это гораздо больший процент, чем в программирование. Я считаю, что есть люди, которые в айти не зайдут при всём желании. Но гораздо важнее пробовать и убедиться самому, нежели доверять рассказам таких, как я. Если вас мотивируют только деньги за «непыльную» работу, советую читать дальше. Опишу два, пожалуй, самых важных качества просто и открыто. На мой взгляд после 10 лет в профессии, самые классные ручные тестировщики это те, у кого есть: а) шило в попе б) тяга к прекрасному. Вот честно, без этих двух основных черт в будущем может быть сложно (да и вообще — зачем это всё). Без шила можно сойти с ума от всех этих рутинных регрессов, без него же нет тяги мягко, но упорно доносить до команды своё видение всех важных проблем. А прекрасное это то, куда должен быть настроен ваш маяк в нашем океане ошибок. Мы сами должны хотеть сделать мир лучше, но можно хотя бы начать с нашего продукта. Конечно, есть и многие другие скиллы. Например, у вас хорошо получается находить «10 отличий»? Это большой плюс для визуальных тестов. Коммуникабельность экстраверта? Быстрее поможет преодолеть преграды общения. Вы перфекционист, к примеру, в уборке или исправляете опечатки, даже если сообщение уже прочитано — вы на верном пути! Но вновь: первые два это то, что помогает расти в профессии, получать удовольствие и зарабатывать доверие команды, а не просто тупо раз за разом идти по чек-листу, выдавая хоть какой-то результат, иногда получая повышение по-армейски за выслугу лет, а не за ваше отношение к тестирование и постоянный рост скиллов. Ведь, как по мне, главная эмоциональная проблема у ручных тестеров в том, что ты-то сам собственно ничего не создаёшь, ничего до конца не гарантируешь, да и вообще, задумайтесь на минуту: весь наш профессиональный фокус в том, как бы так не пропустить критичную бажину. А все рано или поздно такое пропускают вне зависимости от сеньорности. И это очередная эфемерность, которая больше сконцентрирована не на позитиве (созидании), а на негативе вокруг косяков (ошибки требований к продукту, ошибки разрабов и дизайнеров, да и собственные ошибки + вечное чувство ответственности за «как бы чего не вышло»). С одной стороны, зачем столько заботиться об этом, но с другой, зачем вы нужны команде, если вам всё равно на результат? А ведь даже если вслух не говорят, всё равно в случае серьёзных ошибок подсознательно смотрят на тестера, это ж наша первоочередная роль — найти подобные ошибки до выхода в прод. И не забываем, что разработчик может прожить без тестера, а тестер без хренового разработчика нет. Это всё были важные дисклеймеры, которые я очень хотел, чтобы вы знали до того, как погружаться в нюансы. P.S. Всегда рад дополнениям и дискуссиям в комментариях, ведь у меня свой опыт, у вас свой, и тем, кто будет читать данные материалы, важнее видеть разные точки зрения, чем один как бы авторитетный взгляд.