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

Шесть месяцев назад на Habr была написана первая статья по этой теме. В ней описаны процессы, позволившие запустить автотестирование имеющегося web-приложения. Текущая статья описывает доработанный подход к тестированию того же web-приложения.

В прошлой статье “QA-обучение без границ” мы поговорили про возможное превращение карьерной лестницы начинающего тестировщика “обучение → получение первого опыта на русскоязычном проекте → получение опыта на англоязычном проекте” в более стремительное “обучение → получение опыта на англоязычном проекте”.
И про то, как с задачей обучить специалиста, на выходе способного работать QA-джуном сразу в международной компании справляются самообразовательная, массовая и менторская модель обучения.
Сегодня мне как специалисту, который более 15 лет занимается подготовкой QA с нуля, хочется продолжить эту тему и поговорить собственно про обучение тестировщиков английскому. Сначала рассмотрим существующие на рынке решения, а потом обрисуем нечто идеальное.

Итак, наша задача - максимально короткое вхождение в QA-английский для обучающегося тестированию или трейни/джуна.

Привет, я Таня, и наша команда занимается разработкой инфраструктуры для нагрузочного тестирования (НТ) в Ozon. Наша цель — предоставить разработчикам простой и понятный инструмент для подготовки и самостоятельного запуска нагрузочных тестов — можно сказать, нагрузочное тестирование as a service. У нас НТ широко распространено и поставлено на поток — большинство продуктовых сервисов регулярно тестируется по расписанию, в автоматическом режиме. Кстати, подавляющая часть тестов проводится не на тестовых стендах, а прямо в продакшене. Это связано с определёнными рисками, ведь есть ещё и реальный пользовательский трафик. Обложившись алертами и автостопами (критериями для автоматической остановки тестов), мы сводим эти риски к минимуму.  

Компания растёт, увеличивается число пользователей и сервисов. В один прекрасный день нам стало тесно в рамках одного дата-центра — началось масштабное расширение на три ЦОДа. Каждый сервис обзавёлся дополнительными инстансами — и новыми требованиями к нагрузке. У НТ-разработчиков появилась задача тестировать сервисы, разбросанные по разным ЦОДам, и при этом ничего не уронить (мы ребята высоконагруженные). Кроме того, для уменьшения объёмов трафика между ЦОДами и сетевых задержек сервисы при взаимодействии перешли с серверной на клиентскую балансировку. Так как при НТ требуется максимально точно воспроизводить клиентский трафик, от генераторов нагрузки ожидалось такое же поведение. О том, какие перед нами стояли задачи и как мы с ними справились, читайте под катом. 

Бывает, что комментарии интереснее самой статьи, верно? Нет, не потому что автор плох. Зачастую как раз наоборот - глубокое зачерпывание темы мотивирует и других дать раскрывающие, ценные замечания, поделиться опытом. Интересный текст интересно комментировать.

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

Правда, как обычно, имеются некоторые нюансы.

На большей части проектов сейчас востребованы знания по тест-дизайну и тестированию API.

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

Привет! Меня зовут Елена Поплоухина, я руководитель группы тестирования в компании Usetech. Ранее я рассказывала о практике обучения в QA отделе: квартальных целях и профиле тестировщика. Сегодня я хочу поговорить об ошибках, с которыми я сталкивалась на собеседованиях, поделиться историями и дать несколько советов.

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

Хочу уточнить, что материал основан на моём личном опыте и может отличаться от вашего. Надеюсь, он поможет новичкам понять, как делать не нужно, а опытные специалисты могут рассказать свою историю в комментариях. Итак, начнём.

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

В этой статье я решил сделать краткий обзор функциональности Visualize, Mock Servers и Flow.

Говоря о разработке сайтов с использованием CMS 1C Bitrix вопрос покрытия тестами поднимается редко. Главная причина в том, что большинство проектов обходится штатным функционалом, который предоставляется системой - его сложно (да и, в общем-то, незачем) тестировать.

Но со временем проект разрастается, появляется необходимость интеграции со сторонними сервисами и службами (платежные системы, API служб доставки и другие), либо же разрабатывается все более и более специализированный функционал. И чем дальше, тем больше объем кода, контроль за которым лежит уже на разработчике.

Это и является предпосылкой для внедрения в CMS механизма тестирования.

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

Думаю, по ощущениям это похоже на пилотаж болида Формулы-1 без подготовки.

Коллеги, доброе утро. На этой неделе заканчиваем работу по доработкам swift-rur. На следующей готовим отчётность по нерезидентам. Также нас ждут изменения по санкционным спискам. И еще по дороге мы решили взять под крыло один банк — мигрировать базу будем на новогодние. Нужно обеспечить контроль.

Кстати, сегодня к нам пришел тестировщик...

Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.

Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:

Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).

Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно, например, здесь)

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

Безусловно, всё больше компаний стараются выращивать специалистов у себя под крылом, осыпая счастливчиков новыми знаниями и навыками, заодно повышая лояльность к компании. Однако и в этом случае перед компаниями и их специалистами встают животрепещущие и острые вопросы…
Как не потеряться в многообразии информации, которой наполнен интернет и мир вокруг?

Что учить самим или чему учить своих бойцов?

В этом сезоне Heisenbug пройдёт хитрее обычного, совместив онлайн и офлайн. На рубеже весны–лета мы проведём онлайн-часть конференции. А когда станет еще теплее — можно будет встретиться в Питере и закрепить успех мероприятия живым общением, вопросами и личными знакомствами. 

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

Под проведением функционального тестирования чаще всего мы понимаем деятельность в оценке качества бизнес-алгоритмов работы программы, которые изначально в общем виде были сформулированы заказчиком. Затем их переработали в техническое задание аналитики, по которому было реализовано ПО  программистами в программном коде приложения. Да, к функциональному тестированию также можно отнести и тестирование безопасности использования программного продукта.

Но в мире контроля качества программного обеспечения есть и другие интересные грани, о которых многие даже и не слышали — не только джуны, но и даже тестировщики со стажем. Среди таких популярных видов тестирования, как проведение нагрузки на систему, оценки надёжности работы программы, проверки локализации на разные языки внутренней лингвистики, в рамках которой у пользователя есть возможность использования программного продукта, и даже исследование юзабилити интерфейсов, есть не такой популярный вид тестирования как доступность.  Да-да, есть и такое в мире контроля качества программного обеспечения. И хотя в большинстве требований к ПО вы их не увидите, но доступность тоже бывает очень важной и полезной.

Это история о том, как я тестировал одно мобильное приложение для которого важным было то, что установка и работа приложения происходит заграницей. Казалось бы, все должно быть просто, поменял регион в телефоне/эмуляторе или включил VPN и вот тебе счастье. Но это не всегда так, и настройка окружения может затянуться на сутки!

Это не туториал, но в общих чертах вы узнаете, как приложения могут вычислять местоположение, какие приложения часто помогают легко поменять геопозицию, и как все таки сделать эмуляцию региона, когда все способы провалились.

Кстати, если вы знаете еще способ, как можно было всего этого избежать, то напишите, пожалуйста.

Всем привет! Скажу сразу, что это статья человека с большой мечтой о входе в сферу айти в качестве QA, который находится при этом в хардкорных условиях. Сейчас я в поиске своего первого рабочего места после многих месяцев обучения как на курсах, так и самостоятельного. По моей задумке текст должен стать интересной историей для решивших его прочесть. И надеюсь, что у меня получилось. Помимо этого, в ней дополнительно будет немного информации для потенциального работодателя. Я решил начать свои поиски со статьи подобного формата, в связи с невозможностью многих вещей в процессе трудоустройства. И прочитав пост эти нюансы станут вам куда понятнее.

На PHDays 19 мая была представлена платформа The Standoff 365 Bug Bounty, которая объединит компании и исследователей безопасности для поиска уязвимостей и оценки защищенности организаций. За первые два дня на платформе зарегистрировались 366 белых хакеров. Первыми на ней разместили свои программы «Азбука вкуса» и Positive Technologies. Спустя всего 20 минут после запуска был получен первый отчет об уязвимости.

Всем привет! Меня зовут Иван Чечиков, я QA-инженер в МТС Digital, работаю над проектом WASD.TV. В этой статье я моделирую стратегию тестирования для Agile/Scrum-проекта. Она может быть полезна небольшим командам, работающим по такой методологии. Стратегия проста, но не универсальна, вы можете дополнить ее на свое усмотрение.

Подробности – под катом.

Наша команда отвечает в Skyeng за личный кабинет и CJM пользователя до оплаты. Изначально проект был написан на Symfony 4.4 и представлял собой набор слабо связанных компонентов, которые были ответственны за правила работы для фронтенда.

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

У нас были лишь юнит-тесты: каждый покрывал логику одного класса. Все тесты вместе давали покрытие основной логики кода и гарантию, что все работает правильно. Но 100% покрытие кода тесты не обеспечивали. И сейчас не обеспечивают.

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

И мы обратились к функциональным.

Техника тест-дизайна «Таблица решений» - одна из самых сложных для применения, но одна из самых удобных для тестирования сложных бизнес-фич, когда есть более одного условия и одно/несколько действий системы как результат выполнения или не выполнения этих условий.

В этой статье речь пойдет о составлении таблицы решений для тестирования фильтрации с зависимыми фильтрами.

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