Тестирование веб-сервисов *

С развитием веба сайты превратились в сложные приложения, которыми ежедневно пользуются десятки и сотни миллионов людей: почта, облачные хранилища, соцсети, маркетплейсы, стриминговые платформы и т. д. И каждое из них должно работать корректно. Как это сделать? Конечно писать хороший код, а потом и тестировать его. Хотя кто‑то обходится без тестов, тем не менее тестирование — важная часть инженерных практик наравне с мониторингом. Оно помогает нам заблаговременно находить и исправлять баги (или незапланированные фичи) в приложениях. Основная цель тестирования — получить гарантию корректной работы любого ПО .

При этом тестировать современный фронтенд сложно: неуправляемая асинхронность (событийная модель браузера), различие браузеров, тяжелое окружение — это лишь малая часть сложностей. Можно ли все возложить на ручных тестировщиков или исправлять баги после жалоб пользователей? Однозначно нет. В большинстве случаев такой подход в скором времени приведет к оттоку пользователей: не все пишут о багах, просто уходят к конкурентам. Безусловно, ручное тестирование остается важным элементом разработки, но тестировщики не могут держать сотни или тысячи сценариев, которые нужно пройти перед релизом или запуском новой фичи. Так где нам получить гарантии, что ключевые сценарии приложения работают корректно? Автоматическое тестирование.

Всем привет! Меня зовут Миша, работаю фронтэнд‑разработчиком в VK в команде Облака Mail.ru, и я хочу разобрать различные виды тестов, дать их сравнительный анализ и применимость. Сразу скажу, тут не будет практики написания тестов. Потому что это нереально сделать внутри одной статьи, необходимо разобрать: теорию тестирования, классов эквивалентности, различие подходов/методов к тестированию, комбинаторику состояний, правильное использование моков и стабов, понимание чистых функций, знание архитектуры приложения. Поэтому предлагаю сконцентрироваться на видах тестирования и начать с «идеального теста».

Одним из важнейших аспектов тестирования наряду с поиском ошибок в приложении является время, необходимое для его проведения. Если тестирование приложения занимает от нескольких минут до нескольких часов, то оно не подходит для разработки с использованием быстрого цикла обратной связи (fast feedback loop), и разработчики могут проводить его не так часто, как следовало бы.

Привет! Меня зовут Юлия Андреева, я QA-специалист в AGIMA. Мы пилим и тестируем много Flutter-приложений. И недавно я заметила, что не все коллеги понимают специфику их тестирования. В этой статье расскажу про основные инструменты и подходы, которые мы используем. Сосредоточусь только на тех технологиях, которые уникальны для Flutter.

Гуд ньюз эвриван! У нас с друзьями есть традиция — каждый год мы пишем хотя бы один большой IT-учебник. 

В 2023 году мы выпустили бесплатный 100-Year QA-Textbook - интерактивный учебник по тестированию на английском и русском языках. 700+ страниц (без учета картинок!), 40 наборов встроенных тестов. По нему начали заниматься более 10’000 студентов, а хабр-статью про него прочитали более 90’000 раз. 

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

А кроме учебников для новичков, в 2024 году мы выпустим два бесплатных учебника для QA-джунов/мидлов.

Устали от нестабильных тестов?

Автоматизированные тесты часто ведут себя нестабильно. Логичное решение в такой ситуации — немедленно исправить такие тесты или избавиться от них. Но что, если тестов — тысячи, инженеров, которые могут их исправить, не так много, а избавление от большого количества тестов слишком рискованно? В таком случае нужно сначала найти самые плохие тесты и начать работу с ними. Мы в Wrike набили много шишек в попытке решить эту проблему, но в конце концов справились. В этой статье я хочу поделиться нашей историей и показать схему, с помощью которой и вы сможете контролировать стабильность тестов.

Анализ системы защиты сайта от ботов на примере letu.ru с использованием javascript reverse engineering.

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

Привет, меня зовут Коля, занимаюсь тестированием 7 лет, автоматизацией — 6 лет. Так уж сложилось, что не особо люблю WebUI-тесты, но почему-то именно они у меня получаются лучше всего.

В один день мне позвонил мой друг Рома и сказал: «Коля, помнишь ты у нас автотесты делал с селениумом? Помоги мне сделать так же красиво».

Отправив Роме ссылку на свой гитхаб и устроив пару созвонов с объяснениями, что и как работает, я добился от него заветного «Я понял». 

Спустя два дня Рома позвонил снова: «Коля, я всё понял, а вот ребята в моей команде — нет. Помоги мне объяснить им».

Внутри я расскажу от том, как:

• ускорить написание тестов;

• снизить затраты на их поддержку;

• прокачаться в написании фреймворков;

• сэкономить деньги компании;

• сохранить нервы сотрудников.

В 2022 году с приложениями Netflix для iOS и Android произошли серьезные изменения. Мы перевели мобильные приложения Netflix на GraphQL с нулевым временем простоя, что повлекло за собой полное перепроектирование от клиента до уровня API.

До недавнего времени наши мобильные приложения работали на внутреннем API-фреймворке Falcor. Теперь они поддерживаются Federated GraphQL — распределенным подходом к API, при котором доменные команды могут независимо управлять и владеть определенными разделами API.

Сделать это безопасно и без сбоев для 100 миллионов клиентов — чрезвычайно сложная задача, особенно учитывая множество аспектов изменений. В этой статье мы расскажем о широко применяемых методах (помимо GraphQL), которые мы использовали для осуществления этой миграции. Мы обсудим три стратегии — A/B-тестирование, Replay Testing и Sticky Canaries.

Привет, Хабр! Меня зовут Иван, я в тестировании более 2-х лет. Начинал свой путь с курса Яндекс Практикума (подробнее в тг канале). Продолжаем разбирать вопросы и технические задания на собеседовании QA manual. Перед прочтением этой статьи рекомендую ознакомиться с моей предыдущей работой Какие вопросы я задаю на собеседовании QA Junior+

3. Протестировать карандаш для различных видов тестирования.

Для начала необходимо спросить "Есть ли требования к карандашу?" Если вы пропустите этот вопрос и приступите к тестированию, то считай вы провалили задание.

- Требований нет.

1 шаг. Исследовательское тестирование на основе косвенных требований.

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

✏️ Форма влияет на функционал и на удобство использования. Круглый скатится со стола, с гранями не должен "резать" руку, три грани слишком крупно и подойдет не для всех пользователей. Есть ли ластик на карандаше и выполняет он свою прямую функцию?

✏️ Цвет не влияет на функционал (говорим не про цвет графита, а про визуальную часть). Цвет не должен нести лишнюю информацию, кроме как визуального акцента или бренда компании;

✏️ Запах не должен быть специфичным;

Ежедневно я читаю тонны документации, готовлю окружение, заглушки, скрипты, сценарии, методики, анализы и отчёты о производительности. Меня зовут Андрей, и я сеньор-аналитик производительности ПО. В профессии я около 10 лет и, как и многие нагрузочники, пришёл сюда из администрирования.

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

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

Далее можно узнать чуть больше обо всех ужасах.

Привет Хабр! Меня зовут Иван, сегодня поговорим о вопросах на собеседованиях Джуну+ (от 6 месяцев работы) и узнаем как ответить на них не как ChatGPT. Я как инженер по ручному и автоматизированному тестированию провожу собеседования на роль Junior+ QA (с дальнейшим ростом в автоматизаторы). Делюсь своим списком вопросов и ответов, которые я ожидаю услышать.

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

База для Junior QA

1. Что такое тестирование?

Сравнение ожидаемого результата с фактическим результатом ПО. Тестирование это не поиск багов!

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

Привет, меня зовут Кристина Климовских, я — Python Developer в команде DataMining. Главная задача моей команды — поддерживать бесперебойный флоу добычи данных для обогащения и актуализации справочника 2ГИС.

Ежедневно наши парсеры собирают разношёрстные данные из более 700 источников — это поставщики адресов магазинов, отзывов к заведениям, расписания общественного транспорта, ссылок на запись в салоны красоты и всё остальное, что можно впоследствии найти в 2ГИС. Поддерживать этот «зоопарк» парсеров нам помогают тесты — в каждом из проектов добычи мы стараемся покрывать новый функционал тестами и использовать их при раскатке в CI.

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

Привет! Меня зовут Даниил Савин. Летом я участвовал в программе стажировки для безопасников от Бастион и в процессе глубоко исследовал тему безопасности приложений, использующих GraphQL. Так появилась статья, из которой вы узнаете:

• какие встроенные функции есть у GraphQL;

• как тестировать GraphQL API;

• какие инструменты использовать;

• и как обходить различные защитные механизмы.

Хорошее название бага понятно любому:

- менеджеру, плохо знающему техническую часть проекта;

- джуниору, который только пришел в проект;

- разработчику (зачем мне это чинить?)

Для этого оно должно отвечать на 3 главные вопроса: Что? Где? Когда?

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

Привет! Меня зовут Таня, я куратор в SM Lab. В этом посте я расскажу вам о нашем пути оптимизации тестирования — узнаете, какие на нашем продукте были проблемы в процессах тестирования, как мы их решали, почему не надо отвлекать тестировщиков и в чём польза интуитивного тестирования.

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

Итак, основа. 

У нас есть две доски в Jira. Первая отвечает непосредственно за релизные задачи и хотфиксы, вторая — за задачи сопровождения и инциденты. Рассмотрим подробнее первую доску с задачами и хотфиксами.

На ней есть три колонки, с которыми и работают тестировщики:

Чтобы быстро продвигаться в рабочих задачах, необходимо иметь уверенность в том, что можно вносить изменения. А уверенность в изменениях зависит от тестового покрытия.

С тех пор как мы это поняли, автоматические тесты стали просто необходимы. Это привело к массовому внедрению шаблонов для старта работы. Однако просто начать работу недостаточно.