Home

Мы запускаем новый курс по тестированию API — “Тестирование GraphQL API”.

Автор курса: Ольга Назина.
Первый запуск: 19 сентября.
Скидка 15% тем, кто прошел курс Ольги Назиной по тестированию REST API!

GraphQL приходит на смену REST API, исправляя его недостатки. Эта технология набирает обороты и уже активно используется в крупных системах, о ней говорят на конференциях, её активно внедряют в свои продукты.

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

Подробная программа и условия участия по ссылке.

Реклама: Индивидуальный предприниматель Назина Ольга Евгеньевна, ИНН 772791965180, erid 2SDnje8p2cA

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

QA, QE и специалисты-тестировщики часто слышат одни и те же вопросы, особенно находясь на руководящей позиции. Например, это «сколько кейсов еще осталось», «сколько времени еще нужно тестированию», и «какой процент тестирования завершен».

Как руководители, мы часто должны отвечать прямо, линейно, исчислимо. Именно это, как правило, и нужно задающим вопросы – простой, удобоваримый кусок информации, на основе которого принимаются сложные бизнес-решения. Бизнес ожидает ответов вроде «Нам осталось выполнить 500 кейсов из 10000», «в среднем мы выполняем 50 кейсов в день, то есть дней 10», и «мы на 95% готовы».

Опытные люди, однако, знают, что эти ответы не всегда дают нужную информацию. Минусы соблазна «просто сказать им число»:

• Числа легко истолковать неверно.
• Числа не показывают всей картины.
• Они одномерны.
• Они отражают устаревшие данные.

Эффективный способ решить эту проблему – воспользоваться метрикой, разработанной одним из нас (это был Мас Коно). Он называет ее тест-пойнтами. По сути это взвешенный замер запуска планируемых кейсов.

Опубликован выпуск рассылки за лето.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Автор: Герасимов Сергей Сергеевич, Петрович-Тех, блог компании

Всем привет! Меня зовут Сергей, я – Senior Manual QA Engineer в "Петрович-Тех", и в этой статье я предлагаю разобрать граничные значения на практических кейсах.

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

Несмотря на то, что техника простая – она решает много проблем. Это не попарное тестирование, о котором я писал здесь, где есть куча инструментов на выбор, надо правильно составить входные данные, потом анализировать их и выдавать результат. Тут всё проще: мы руководствуемся чистой логикой. 

Разберем в статье конкретные примеры использования этой техники. Поехали!

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Мы дошли до L в SOLID! Принцип замещения Лисков назван в честь Барбары Лисков, специалистки по информатике, которая ввела эту концепцию в 1987 году. Принцип гласит, что вы должны иметь возможность заменять объекты суперкласса объектами подкласса, не изменяя программу.

Автор: Наталья Руколь

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

 11 марта 2024 года. Вентиляторный завод, село Крюково, Московская область: 
- Сергей Петрович, здравствуйте. Я сегодня не смогу выйти на работу, потому что я не в ресурсе. 
- Жека, да ты чего? А что с тобой? 
- Сергей Петрович, мне совсем не хочется работать, не могу войти в поток, у меня упадок сил. 
- Женя, ну ты чё, надо заботиться о себе. Совсем упахался. Ты давно с друзьями на рыбалку ездил? А ванну с бомбочками принимаешь? 
- Блин, Сергей Петрович, у меня на такое не было времени. Вот видите, до чего я себя довёл. 
- Понятно, Жека. Отдохни обязательно пару дней и возвращайся. 

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор: Ekaterina Egorova

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

Прогресс, как всегда, не остановить, но что сейчас представляют собой интеграции с AI и насколько это рабочие решения?