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

Нам, наконец-то, проаппрувили GitHub Copilot, и хочу сказать, что примерно половину из своих тестов я пишу с его помощью. Так как AI пока лучше всего справляется с более-менее шаблонными штуками, автотесты как годятся. При этом радует то, что всякую рутину типа описания шагов пилот быстро схватывает, и часто нужно подправить не более одного-двух слов, сам смысл он угадывает весьма точно. В эту же тему Postman выпустил новость о том, что их AI assistant, который генерит тесты на запрос (не так круто, как пилот, но все же), доступен для early access. Записаться в очередь: https://www.postman.com/lp/postbot-early-access/

В Штатах и Канаде айтишные СЕО решили сговориться и вернуть народ в офисы на гибридную модель. Одна из причин в том, что экономика сейчас переживает не лучшие времена, и они, видимо, думают, что это один из способов повысить продуктивность и лояльность сотрудников за счет офисных печенек и игры в пинг-понг. Проблема в том, что в ковид все искали таланты, а потом уже смотрели на геолокацию, поэтому на данный момент коллеги находятся где угодно, только не в одном городе. А вновь тратить 3 часа на дорогу не повысит желание вкалывать. Менеджеры вполне понимают, что это время народ теперь будет включать в рабочее и просто работать меньше. В то же время, в офисе многие будут так же сидеть в зуме и трещать с коллегами по миру. В отсутствие переговорок на всех, опенспейс превращается в базарную площадь. В общем, единственная надежда, что топ менеджмент посмотрит на результаты продуктивности и даст возможность командам самостоятельно выбирать оптимальный вариант работы.

Load testing в Postman Postman наконец-то сделал шаг в логичную сторону, и в текущем канареечном релизе можно пощупать поддержку нагрузочного тестирования. Пока там только базовые вещи типа: - использовать уже имеющиеся запросы из коллекций - добавлять виртуальных пользователей - указывать длительность теста - ramp up период - базовая аналитика Скачать: https://www.postman.com/downloads/canary/

Git-Worktrees Удивительно, но автор видео не обманывает — действительно, про эту прикольную фичу гита либо мало, либо никто не знает даже из разработчиков со многими годами опыта. Спросите у своих и дайте знать, сколько человек знало об этом :) В чем суть: вы работаете над какой-то фичей, у вас уже кучка изменений, и в какой-то момент вам нужно срочно сделать что-то другое: пофиксить срочный баг, помочь коллеге в его ветке, в общем случае переключить контекст и как-то сохранить текущую работу и потом вернуться к ней позже. Кто-то просто клонирует репозиторий несколько раз, но есть способ лучше, и это Worktrees. Почитайте документацию или лучше посмотрите видео с примерами.

Уроки по автоматизации на Cypress По мере их прохождения группой, буду выкладывать ссылки на итоговые инструкции с картинками и пояснениями, чтобы другие смогли попробовать в своем ритме, если будет желание. Для начала вот три гайда 1. Минимальный JavaScript 2. Настройка окружения 3. Git и установка Cypress

По-крайней мере в Северной Америке IT в целом переживает не лучшие времена. Постоянные сокращения и погоня за малыми и большими издержками. Но Гугл бежит впереди паровоза — имея 69 миллиардов ревеню за первый квартал, они убрали из офисов сушеные манго и M&M’s!! https://www.businessinsider.com/google-removed-office-snacks-perks-cut-costs-report-2023-4

Пока группа учит азы JavaScript, пора расчехлять мемасы, чтобы правильно их мотивировать

Минимальный минимум Javascript Всем советую бесплатный базовый курс от Hexlet по JS: https://code-basics.com/ru/languages/javascript. Самая полезная штука там это автотесты, которые проверяют написанный код. В бейсике, разумеется, все просто. Кто не программировал совсем или люди с каким-то опытом в других языках и наличием времени - пройдите весь курс, это достаточно быстро, весьма информативно, и материал написан простым языком. Если же опыт есть, но времени нет, то вот список самого необходимого: - Переменные - Константы - undefined - Типы данных - 1 + '7' = 17 (чтобы понимать мемасы) - Свойства - Методы - Функции - Создание функций и Упрощенный синтаксис - Возврат значений - Параметры функций - If и else - Цикл For

Апдейт по урокам автоматизации Я пообщался со всеми, кто откликнулся, и вот какая картина: - почти у всех есть какой-то хотя бы начальный опыт - это Java/Python + Selenium - есть неуверенность в силах, так как кажется, что текущий уровень слишком далек от коммерческой разработки тестов Моя изначальная задумка была про пошаговый вход для начинающих, и я планировал сделать инструкции по Cypress (Javascript) и Playwright (Python), но на второй просто не хватит сил, поэтому план такой: - c самого нуля показать, как писать тесты на Cypress - что минимально нужно из знаний программирования, чтобы сфокусироваться на действительно нужных вещах, не пугаясь неизвестности - базово настроить GitHub и CI на GitHub Actions, чтобы тесты сами запускались по нужным триггерам - дать материалы, которые помогут с фокусом на практики написания хороших тестов У некоторых цели отличались от вышеописанного, поэтому, пожалуйста, ❗️обязательно напишите сюда или в личку, если вы хотите участвовать в предложенном. [Sinon] Если нет, предлагаю обратиться за помощью к менторам из https://t.me/qa_mentors, там есть джависты и питонисты, которые смогут лучше помочь с конкретными вопросами. Вот их общая база менторов, там почти 60 участников, и нередко люди могут помочь и бесплатно с базовыми вопросами.

Кто хочет в автоматизацию тестирования? Я поразмышлял, чего мне самому не хватало в свое время, чтобы нырнуть в автотесты, и это: — Боязнь перед программированием. Казалось, что нужно сразу знать всё — Разрозненность информации: куча туториалов, включая друзей из Индии, которая охватывала какую-то часть айсберга, но не давала понимания, куда двигаться — Selenium как таковой: на тот момент разработка и отладка тестов была мучением в сравнении с актуальными фреймворками — Но главное — отсутствие знающего человека, которому можно было задать конкретные вопросы, и который бы направил своей менторской рукой в правильную сторону Поэтому я хочу отдать дань Богу Тестирования и через какое-то время подготовлю стартовый мини-курс для тех, у кого вышеописанное срезанировало. Бесплатно. Цель — помочь именно с этим первым шагом и попутно с первыми же затыками, которые всегда неизбежны. Как я это вижу Сами инструкции буду постить для всех, но так же планирую набрать 10 человек, кого буду точечно поддерживать и направлять. 10 потому что, как ни прискорбно, никто не ценит бесплатную помощь и: 5 отвалятся сразу, 3 попозже, 2 заболеет, 1 передумает, и если вы заметили, что уже получилось -1, то вы молодец и на верном пути. Портрет участника Человек с неким опытом в ручном тестировании. Возможно, слегка попробовавший и бросивший вхождение в программирование/автотесты. Кто морально готов, но кому нужно дружеское плечо, чтобы начать, но всё либо за деньги, либо непонятно, кому довериться. Английский на каком-то среднем уровне понимания речи из видео и чтения. Если вам интересно и хотите поучаствовать, напишите о своей ситуации в комментариях или в личку. ℹ️ Напоследок небольшое отступление для контекста. Мы разговаривали с Кириллом Мокевниным, основателем Hexlet, насчет идей курса по ручному тестированию для самых начинающих, и я почерпнул то, что для входящих людей самое главное — не груз классов эквивалентности сразу, как говорится, in your face, а просто понять совсем простые вещи: вот они тыкают на кнопочку, и что-то вызывающее их сомнения происходит. И если внутреннее шило начинает давать о себе знать, то эта отрасль может быть правильным направлением. Что-то подобное я и хочу сделать для автотестов. Пусть это и будет для начала больше похоже на карго-культ.

Что такое #SDET и как им становятся Software Development Engineer in Test, он же QA Automation, Dev QA, Automated test developer. Из всех этих вариантов SDET мне кажется наиболее подходящим — эта роль для зрелых ребят, кто может и в разработку, и в тестирование, и в обеспечение качества. Не зря подробно писал предыдущие посты про качество, теперь, наконец, могу на них ссылаться. Термин «QA Automation» это какое-то, прошу прощения, bullshit bingo, так как можно автоматизировать конкретные проверки и мониторинг, но ни нормальное тестирование, ни уж тем более обеспечение качества автоматизировать на данный момент нельзя. Поэтому больше к этому термину не возвращаемся 🙂 Тогда что же может и должен делать SDET? Если QA это всё, что может эффективно помочь стремлению сделать счастливыми бизнес и пользователей. То SDET, на мой взгляд, это опять же всё, что помогает движению к идеалу, но еще и с большим фокусом на разумной автоматизации рутины. Да, включая автотесты, но далеко не только их, и это, возможно, не самая очевидная для некоторых часть. SDET помогает команде разработки ставить процессы тестирования, то же ручное и автоматизированное + нагрузка, работает над CI/CD, мониторингом и алертами. И да, условный exploratory testing он тоже может делать без зазрения совести, если это помогает команде выпускать лучший продукт. В зрелых командах SDET становится больше ментором, он создает фреймворки, обучает разработчиков приемам всяческого тестирования, парно программирует, скидывает мемасы про разрабов, занимается метриками, помогает с болевыми точками суппорта и в целом следит за качеством продукта с разных сторон. Как стать SDET Я писал, что эта роль — микс разработчика и QA, поэтому в идеале человек должен быть одинаково хорош в обеих областях, но, по моему опыту, чаще либо тестеры выучиваются в разработку, либо разрабы прокачивают насколько-то тестирование, и «родная» область нередко может превалировать над доученной, но есть и 🥷. Нужно понимать, что не все тестировщики могут стать SDET — кому-то разработка оказывается не по силам или просто не по душе, и это нормально. Необходимо пробовать и смотреть, заходит или нет. Через какое-то время пробовать еще раз. Главный посыл, что в один день ты не можешь волшебным образом знать всё выше перечисленное. Это наживное, нужно не бояться и начать работать только с автотестами, плавно изучая те же GitHub Actions в качестве CI для своих же тестов. Это в целом всё — непрерывный процесс, как и сама разработка. Если позволяет компания, то нужно активно учиться, используя их ресурсы, если нет, то дома в свободное время читать, смотреть, изучать, делать pet-projects и прокачивать скиллы. Вдвойне усердно, если вы техногуманитарий. Это ваша инвестиция в карьеру, зарплата матерого SDET может быть сопоставима оной у разработчика, поэтому если вы настроены серьёзно, то платные курсы и материалы могут серьёзно ускорить ROI (возврат инвестиций). Но если вы идете исключительно за заплатой, не факт, что это нужный первичный драйвер, решайте сами. Далее я буду стараться описывать то, с чего можно начинать ручному тестеру в следующих постах, stay tuned.

Качество ПО и его эфемерность. Часть 5.3: Баги эксплуатации Aka «Семь бед — Один ресет». И в этой поговорке вся соль. Все те ошибки, с которыми сталкиваются пользователи при их обычном использовании вашего творения. И это — самая коварная штука, которая по факту является квинтэссенцией всех моих предыдущих постов про качество и его эфемерность. В том числе потому, что вы никогда точно не знаете, сколько и как часто такие ошибки происходят, и сколько пользователей это затрагивает. Коварная — потому что тот фидбек, который вы получаете через мониторинг прода, суппорт, социальные сети, выставки и прочие каналы не показывает полную картину. Это вариация ошибки выжившего — вы видите только то, что вам сообщили. А, как я уже писал выше, мы как пользователи привыкли к некачественному софту. Кто-то считает, что раз не жалуются, то и не беспокоит, это не всегда так. Есть проблемы, о которых не сообщают вовсе или массово вне зависимости от критичности. В том числе потому, что возможно это плавающий (hard to reproduce) баг, который встречается, когда звезды сойдутся или наступает растущая 🌒. Также в процессе эксплуатации бывает стечение разных обстоятельств (к вопросу о сложности современного софта) на конкретном устройстве или аккаунте. И если это лечится: перезапуском, перелогином, стиранием кук и прочими гениальными советами от суппорта, то даже когда пользователь тратит свое время и сообщает о беспокоящей лично его ошибке, приоритет таких кейсов падает драматично. Сообщить об этом могут 5 человек, а встречать и поминать лихом 500. Поэтому так важен регулярный dogfooding — когда вы командой используете свой собственный продукт. Особенно это важно для разработчиков, так как у них гораздо более фрагментарные представления о том, как именно всё работает, и насколько это вообще удобно. И когда вы вместе используете GET (guided exploratory testing), вы можете (частично) открыть для себя дивный мир пользовательских переживаний. Отдельно про мониторинг. К примеру, когда ваш сервер на как бы короткое время отдавал ошибки как бы небольшому проценту пользователей, а потом всё само починилось, те точно не считали ваш продукт качественным в тот момент. Для вас это 0.1% на дашборде в Grafana, для них — 💩сервис. Поэтому если клиенты могут найти более стабильную альтернативу, вполне себе молча уходят после кумулятивного накопления усталости от ошибок. Если же почитать почти любой change log, там постоянно «исправлены ошибки, улучшена производительность». Еще бы при этом не добавлялись новые ошибки и не ухудшалась производительность в других местах, эх… По всем этим причинам некоторые компании стали вешать планку Beta, чтобы уже окончательно сдаться и признаться, что тестируют прямо на пользователях, ну а баги — бета же, зато не ждете еще год. Как итоговый итог всему, скажу так: все сегодня обмазались кубернетесами-шмубернетесами, модными фреймворками и best practices, а багов всё равно полно у всех. Так и живем, во всех смыслах — не жалуемся.

Качество ПО и его эфемерность. Часть 5.2: Невозможно протестировать всё Проверить записанные в задаче условия — только часть айсберга. Да и вообще, если они есть — в некоторых компаниях принято писать 1-2 предложения, и, как говорится, «без ТЗ получается ХЗ», поэтому как оно должно работать — еще надо добыть, проанализировать и записать. Но помимо самой фичи, нужно (далее читайте как рэп): написать и/или изменить ручные и автотесты, сделать анализ затронутых областей, провести регресс, UX, исследовательское и релизное тестирование, не забываем проверить разные языки, регионы, валюты, браузеры, операционные системы, размеры экрана, скорость интернета, accessibility, compliance, аналитику, поиграть в настольный теннис, базовую безопасность, нагрузку, добавить что-то в мониторинг, обновить Confluence — список не конечный, нормально пока идем 🤨 Да, это всё делается не одновременно и не для каждого таска, но это то, что тестеры держат в голове и применяют при необходимости. Мы используем техники, опыт и чутье, чтобы протестировать как можно больше за отведенное время, но реальность такова, что все взаимосвязи изменений в сложных системах, помноженные на конфигурации, иногда невозможно найти и протестировать даже после глубокого совместного с девелопером анализа, а часики-то тикают, бизнес хочет фичу вчера. Поэтому то, что в теории могло бы быть нами найдено до релиза, в жестких ограничениях по времени легко может быть пропущено. «Вас, разрабов, много, а я одна» Обычная ситуация, когда пропорция 1 тестер и, к примеру, 5-10 девов. Тестер может не иметь физической возможности проверять все таски. Если каждый разраб делает, к примеру, 3 фичи, а тестер должен проверить 3*количество разрабов ➕ что-то из вышеописанного списка. Поэтому нормально, когда девелоперы сами 💯 ответственны за тесты. Это у них нередко получается хуже, в том числе потому, что свой код (моя прелесть) тестировать сложнее, я могу подтвердить. Ну и их квалификация обычно ниже, так как тестированию учат (и учатся) слабо или вообще не. Спросите у своих, применяют ли они классы эквивалентности и граничные значения хоть где-то, скорее всего ответ будет: «Что это?». Поэтому они пропускают больше багов, чем если бы это мог проверить опытный тестер. Зависимости Могут быть внутренними и внешними: фреймворки, библиотеки, плагины, сервисы других команд или сторонние системы. Зависимости могут быть как вниз, так и вверх (upstream и downstream), то есть те, что используете вы, и те, что вас. К последним, например, относится команда с экспериментами — они вешают свой код прямо в проде поверх вашего, и, разумеется, тоже косячат. Если продолжить про прод, то могут быть интеграции, которые доступны только там, соответственно, проверки на тестовых окружениях ничего не дадут. Повторюсь, баги есть у всех, и обычно покрывают какие-то базовые взаимоотношения, ведь если не доверять никому и полноценно тестировать еще и весь сторонний код, можно сойти с ума. Поэтому рано или поздно штука, которую вы не контролируете и от которой зависите, даст прикурить. Но вы же помните, кто виноват у конечного пользователя?

Качество ПО и его эфемерность. Часть 5.1: Человеческий фактор Это наше нутро пролезает через самые лучшие процессы, стандарты и автоматизацию. Но по порядку. Самый понятный случай, когда баг в фиче, условие было явно описано в требованиях, но: программист его не сделал + ревьювер кода не увидел + тестер не нашел + заказчики поленились потыкать демо = 🪲 Хочу отдельно отметить, в описанном случае это общая ответственность, а не исключительно тестера, хотя и я лично делю ее в равной степени между разрабом и тестером, остальные в меньшей мере. Если говорить о частных случаях, то это всё в ту степь, что: кто-то кого-то или что-то не так понял, не перепроверил, не уточнил, не знал и забыл, не посмотрел и не предупредил и прочее. Недостаточная компетенция кого-то из членов команды это тоже фактор — так как из-за нее вышеперечисленные случаи происходят чаще. Это частично лечится автоматизацией, мониторингом и процессами, но конца неискоренимо. К сожалению, автотесты тоже не панацея. К примеру, тест есть, ручками сценарий уже не проверяют, но он плохо написан и проходит даже когда случается баг. Или, например, проверяет функционал, а баг в UI, который простой e2e не «видит». Еще забавный случай был на днях, когда разработчик по незнанию подумал, что новая мелкая фича, сделанная коллегой, это баг(!) и без лишнего шума «пофиксил» её в своей текущей ветке. Merge conflicts Частный случай фактора и недооцененная штука. Пока не ушел в SDET, не понимал, как программисты так плодят регрессы из-за конфликтов при слиянии своих веток. Но теперь я всё понял — это жестяная жесть. Даже при скурпулезном анализе изменений в сложных конфликтах могут приниматься неверные решения, что приводит к ошибкам, которые бывает непросто найти.

Качество ПО и его эфемерность. Часть 5: почему у всех баги Пост будет особенно полезен тем, кто думает, что во всем виноват тестер. Я уже 4 части исписал про ошибки, но надо бы оставить и формальное определение. Википедия говорит так: “A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways”. То есть, ошибка на каком-то этапе разработки, приводящая к нежелательным результатам. Нужно добавить, что у каждого человека восприятие бага отличается. Вечное — что тестеру баг, то разрабу фича, но еще ведь и разные тестеры параллельно найдут разные баги, однако, об этом как-нибудь потом. [Глобальные причины] На мой взгляд: — Софт на каком-то этапе развития стал слишком сложным — Это не приносит денег, а бизнес хочет быстро доставлять фичи, и поэтому, бурча, фиксит те, на которых явно теряет прибыль — Осознание, что ошибки есть у всех — А мы как множество из пользователей в свою очередь привыкли к некачественному софту, поэтому редко жалуемся, и бизнес продолжает еще быстрее выпускать полуфабрикаты [Почему баги в проде] В недостижимом идеале разработчик отдает (уже) безбажный код, а тестер (лишь) подтверждает, что всё работает, как надо. Этого никогда не происходит — утрирую, но «нет качественных приложений, есть недотестированные». Анализируя весь прошлый опыт разбора факапов, я постарался сгруппировать самые важные для меня причины так: 0. Баг найден и описан, но бизнес решает его не фиксить сейчас/никогда 1. Человеческий фактор 2. Невозможность протестировать и мониторить всё 3. Баги эксплуатации Нужно понимать, что вне зависимости от конкретной причины обычный пользователь, оставшись с багом один на один, думает, что именно вы — команда ладно, ладно, напишу мягко: некомпетентных и криворуких, не способных найти очевидные ошибки. Причин, конечно, больше, но эти три весьма показательные, на них и остановимся подробнее.

Качество ПО и его эфемерность. Часть 4: баги, они повсюду… Это моя любимая часть, позвольте оторваться 🙃 Сначала повторю тезис — конечное восприятие качества вашей программы не обезличенным в статистике и отчетах «юзером», а каждым живым человеком с эмоциями — это субъективная характеристика, которая не поддается четким подсчетам. И эта штука, в моем представлении, сильно зависит, как минимум, от: — толерантности этого человека к ошибкам в ПО — суммы встреченных конкретно им косяков и их критичности для него за период пользования На основании этих (и наверняка каких-то еще) критериев каждый пользователь подсознательно ставит свою оценку вашей работе. Надеюсь, пока мысль ясна. Теперь поговорим про современный софт. Никого не удивлю — баги есть у всех, они встречаются и у компаний с бесконечными деньгами (i.e. FAANG и прочие), не говоря про смертных. Вот часть отмеченного мною бажинного фона в бытовом использовании. Apple Начну с компании, которая, наверное, за свой кэш могла бы скупить всех лучших тестеров мира. — Screen time молча сбрасывает настройки лимитов для детей (чему они очень рады) или не аппрувит запросы (чему они не вообще не рады) — Косяки с синхронизацией у встроенных приложух — Сын 7 (СЕМЬ) раз менял свои AirPods Pro после проблем с шумодавом и прочим — Airdrop работает через раз — в упор не видит членов семьи Авто Я беру новые машины в лиз примерно раз в 2 года, поэтому, просматривая рынок, вижу, что и в бюджетных, и в люксовых, с мультимедийным (но не только) софтом не все в порядке. — UX спустя непродолжительное (для меня) время скатывается к дешевому китайскому андройдофону — начинает тупить и подвисать — Еще я был любителем не брать ключи, а закрывать-открывать со штатного приложения Mercedes, и иногда нужно было долго ждать срабатывания — запрос просто зависал, но в один важный момент машина вообще не открыла двери, и пришлось ждать Road assistance — В текущей в один момент водительское стало абсолютно каждый раз полностью откидываться в лежачее положение при смене водителя. А при глюке с багажником камеры 360 могут показывать только черноту — CarPlay (привет 🍎) это бестия. Иногда не может законнектиться к нужному девайсу, рестарт машины и телефона не помогает. При подключении с нуля, он может появиться через пару дней, и ехать нужно, глядя на лежащий телефон, потому что встроенные карты в свою же очередь не могут найти адрес. На закуску: по факту именно неподключившийся CarPlay стоил жене 500$ штрафа. Играете в игры? Про современные большие релизы можно просто сказать мемом «S.T.A.L.K.E.R. 2 не повторит ошибок Cyberpunk 2077. Игра не выйдет». ❕Обязательно посмотрите вот этот ролик: «Я ТОНУ НА ЗЕМЛЕ» (чуть экспрессивная лексика может говорить о качестве, убавьте звук). Google YouTube music — Как-то после обновления удалил все скаченные треки — В экстазе с CarPlay регулярно теряет возможность переключать песни — Проигрывает начало 2 раза Facebook — Год не мог загружать видео через веб-версию в iOS Safari — В мессенджере уведомление не пропадает после прочтения чата — минор, но постоянно зудит Ну и, пожалуй, самый любимый, про который знают все — FB и Ко тотально прилегли на несколько часов в 2021. А восстановить все стало возможным после аж физического визита в дата-центр. Это лишь часть того, что я отметил, больше не помещается в пост, поэтому переходим к центральному тезису. [Качество Шредингера] Да, это всё происходит не всегда, и в этом главный момент — сегодня этот софт мне кажется good enough, а завтра случается очередной косяк. Не забываем, на той стороне эти сценарии наверняка покрыты всяческими тестами и мониторингами, люди могут даже веровать в ISO и best practices, а я в это время час стою с закрытой машиной как идиот, потому что надо брать ключи емае их софт не сработал именно сейчас. Каждый может составить такой список. Поэтому риторический вопрос — можно ли считать подобный (с одной стороны спорадический, с другой перманентно в жизни присутствующий) опыт качественным?

Качество ПО и его эфемерность. Часть 3: что делать Идеальный идеал в коммерческом подходе: в центре всего стоят (в меру) счастливые пользователи, которые всё больше приносят бизнесу 💴, благодаря вашему софту. Далее дам свое определение и разверну мысль: обеспечение качества ПО, особенно web, в современных реалиях — это всё эффективно работающее для конкретной команды и позволяющее максимально быстро доставлять заказанный продукт, который при этом good enough. Теперь разделаем это по частям. Всё эффективно работающее Я прохладно отношусь к бездумно-баззвордным “best practices”, так как считаю, что слепое следование даже лучшим стандартам или же модным идеям далеко не всегда дает лучший же результат. Поэтому моя формулировка — всё, что эффективно влияет на баланс коллективного счастья пользователей и бизнеса в случае конкретной команды. Стандартами и практиками описываются лишь общие принципы. Вещей (в том числе нестандартно-неожиданных), которые могут приблизить к результату, множество. Команда Кто-то считает, раз у тебя в тайтле есть “QA”, то ты и отвечаешь за всё, и если нашли баг в прод, клади голову на плаху, но это не так. Баги возникают по целой куче причин, и об этом подробно позже. Люди не в теме обычно считают, что просто тестер плохо поработал, но это далеко не всегда верно. Немалая часть ошибок возникает из-за более глобальных проблем в процессах. Любой человек изнутри или извне может указать на проблемы, и любой человек из данной команды, знающий при этом текущие ограничения, способен предложить улучшение этих процессов за счет предыдущего и, я бы здесь добавил, вариативного опыта и обратной связи. Я не пишу должен, это достаточно категорично, способен — более точное определение. Retro ➡️ Feedback ➡️ Action items ➡️ Assessment ➡️ Retro Это цикл, который никогда не прекращается, какими бы сеньорными все участники не были. То есть, в основе процессного менеджмента лежит практический опыт, поэтому я считаю, что не может в дикой природе быть «джунов QA», так как невозможно с (около)нулевым бэкграундом влиять на процессы — обеспечение качества это не тестирование. Отдельно отмечу: почему-то считается, что за счет эдакого таргетированного прошлого опыта с ошибками, тестировщики и QA лучше других членов команды могут помочь ей двигаться к вышеописанному идеальному идеалу, но это зависит от проекта и матерости девелоперов. В Unity я нередко вижу команды, хорошо хреначащие в соло без добавления выделенных тестеров/QA. Стремление к идеалу — наша общая командная цель вне зависимости от должностей. Быстро доставлять В случае коммерческого web, который, пожалуй, проще других доставить пользователю, скорость релизов имеет значение. Миллион экспериментов на конверсию, data-driven решения, feature flags и preview. Это все не будет ждать неделю на ручной регресс. Другие категории софта тоже в той или иной степени подверженны этой тенденции. Так как если мы медленно бежим свои спринты, бизнес плавно проигрывает свой марафон конкурентам. Good enough Этот пункт точно описать сложнее всего, так как мы вступаем в субъективщину. И это же понятие сложно воспринимать входящим в тестирование перфекционистам. Как пользователи воспринимают ваш и наш софт, я с примерами расскажу в следующей части, пока же хочу сделать акцент на поиске баланса между скоростью релизов и ошибками. Не ошибается тот, кто ничего не релизит. Инциденты или менее критичные ошибки неизбежно были и будут всегда. У всех. Поэтому мы (изо всех сил) do our best, чтобы на выходе получилось (всего лишь) good enough, а вот сколько нужно тратить усилий на снижение количества критичных багов — решает команда совместно с бизнесом.

Качество ПО и его эфемерность. Часть 2: что ты такое Тестерам палец в рот не клади, поэтому сначала официальная нуднятина про термины. Казалось бы, ожидаемый результат обеспечения качества разработки в логическом понимании пользователя — это чтоб условный сайтик был всегда доступен и без багов, но вот вам реальность. «Обеспечение качества ПО — процесс, который должен обеспечить гарантию того, что рабочие продукты, действия и процессы разработки соответствуют требованиям ISO». “Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards… ISO/IEC 9126 (now superseded by ISO 25010), SPICE or CMMI“. То есть — вот тут есть у нас есть методики, следуйте им, и у вас получится… качественный результат следовать ISO. Но давайте пока начнем с качества чего-то элементарного. С простыми физическими продуктами правила и процессы изготовления и контроля работают. К примеру, условный молоток должен как минимум в течение энного заданного производителем времени сохранять главные характеристики: забивать гвоздеобразные предметы и не деформироваться/разваливаться. Бить посуду, машину бывшего или использоваться в самообороне тоже может, но на ваш риск. Поэтому тут с качеством намного проще. Если всё еще забивает Х (много) лет подряд — хороший молоток в сознании всех пользователей. И то, этот Х у каждого субъективно разный. Вернёмся к ISO. Если перевести стандарты на человеческий, то это что-то вроде «делайте всё-всё, как надо, и не делайте, как не надо». На мой взгляд, это не работает в той же мере в мире софта, потому что (и сейчас максимально персональное мнение) — в целом качество современного ПО для пользователей это что-то нечеткое, математически до конца не высчитываемое, и в целом весьма субъективная характеристика. И даже если вся компания идеально следует соответствующим стандартам, софт на выходе не получается качественным для конечных пользователей просто по факту применения этих методик, он будет сделан по общим методологиям, которые в теории позволяют в числе прочего снизить количество важных для продукта ошибок. Но это лишь часть айсберга, которую хоть как-то можно контролировать. А то, с чем в итоге сталкивается отдельно взятый человек или группа людей, может быть далеко от ISOшного понятия качества, и об этом позже.

Качество ПО и его эфемерность Pre-conditions: о чем речь и дисклеймеры В 4 постах (в один не влезло вообще никак) я хочу прояснить нюансы про качество современного софта тем, кто: — не в QA, но с этим взаимодействует — только стремится в сферу — начинающий идеалист-перфекционист тестировщик — кто «не понимает, что происходит», i.e. почему столько бажин везде и у всех Хочу отдельно отметить, что этот материал — мое субъективнейшее понимание происходящего, и у других ребят в теме видение может быть другим. Причем, на мой взгляд, 100% правильного ответа нет у кого, потому что эфемерность сложно калькулируется. Так же я в Канаде, поэтому часто ссылаюсь именно на североамериканские компании, и вот эти ребята, как по мне, откровенно грешат клише по типу: “Налетай-торопись, release bug-free user experiences”. Как при найме на работу в поиске «идеального QA», который своей качественной рукой наведет порядок, а баги исчезнут, едва замаячив. Не отстают и подручные инструменты, обещающие светлое и безбажное существование. Это, на мой взгляд, порождает у причастных к выпуску ПО людей искаженные ожидания и от процесса, и от нас, поэтому такой подход я лично и отношу к современной эфемерности качества ПО. И вот на эту по факту центральную, скрепообразующую и в то же время бесконечную тему поговорим, насколько это возможно в данных рамках, подробно.

QA ≠ Тестирование Этот пост логично должен был бы быть первым, но лучше поздно. Пишу его не для опытных, а для начинающих и не-тестеров, чтобы потом ссылаться при случае. Итак, центральный тезис — QA (обеспечение качества) не есть тестирование. Тестирование (в качестве лишь одного из этапов) входит в комплексное обеспечение, но не наоборот. Об этом ниже. Но сейчас, и особенно сужу по западным компаниям, что-то всё (ВСЁ) стало QA, прокликать ручками — QA, автотесты почему-то тоже QA, даже вакансии манкитестеров (когда просто прогоняют тесты, написанные лидом) вдруг превратились в Junior QA Engineer. Понятно, что двумя буками банально проще обозначить какую-то там происходящую магию, и отчасти из-за того, что остальные люди не понимают, что мы делаем, и поэтому считают, что QA это и есть видимая им часть айсберга про тестирование тестовых тестов. Мое беспокойство вызывает неосознанное обесценивание и нивелирование самого термина QA и неизбежно следующих за этим искажений представления людей, коллаборирующих с этим, но не понимающим ценности комплекса скиллов. Ультимативный гротеск для разрабов: опытный техлид в таком представлении — кодер в изначальном смысле этого слова, когда вся работа уже сделана кем-то еще, осталось только перевести готовый алгоритм в код. Мое убеждение основывается на следующем: без реального, достаточно долгосрочного и максимально желательно коммерческого опыта невозможно с порога «обеспечивать качество», просто почитав/посмотрев материалы об этом или отучившись даже на лучших специализированных курсах. Тестировать на каком-то уровне можно, быть сразу «джуном QA» — нет. Приведу более приземленный пример. Хотя в большинстве случаев использование аллегории «ПО ~ Здоровье человека» является натяжкой, принципиальных сходств всё же немало. Поэтому «Взять кровь (пусть будет кровь) на анализы ≠ комплексно поддерживать здоровье человека во времени», и это особенно видно, когда даже после вашего ухода построенные и отточенные опытом и кровью (пусть будет кровь) процессы позволяют команде релизить с приемлемыми скоростью и уровнем качества. И отсюда же следует добавка для рекрутеров: «Лаборант это не джун Доктор». Главная засада, что нет некоего правильного способа достичь такого же правильного уровня «качества», поэтому это всё еще больше усложняет понимание вопроса, но об этом — в будущих постах.