Home

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

В профессиональных кругах есть расхожая шутка, что консультанта легко опознать – он всегда отвечает на любые вопросы одинаково:

«Зависит от ситуации».

(иногда за этим следует «а если вы хотите более полезный ответ, то карточка к номеру привязана»).

Отставим шутки – в этой конкретной есть доля истины. В тестировании и разработке ПО крайне, крайне мало абсолютных истин.

Однако это не так легко понять, просматривая, скажем, мою ленту LinkedIn. Я где-то даже понимаю. Люди любят мыслить абсолютными категориями и говорить о них. Это простейший способ найти ответ на вопрос или сформулировать его.

Оригинальная публикация
Автор: Андрей Шушаков

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

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

Статья написана в рамках стажировки июль-август 2024 в компанию "Бастион". Выражаю благодарность куратору от Бастиона, Тимофею Брылеву, а также моему знакомому, Евгению Чикачёву, за совет

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

Что делает тестировщика великим?

Недавно я видела ряд дискуссий, побудивших меня задуматься:

• Что делают тестировщики?
• Чем ISTQB-тестировщик отличается от «гибкого» или «современного»?
• Отвечает ли тестировщик за определение влияния и/или приоритета бага?
• Почему люди используют термин «ручной тестировщик» (а также споры о терминологии, сопутствующие этому вопросу)?
• Насколько широка пропасть между великим и ужасным тестировщиком; кто из них чаще встречается?

Отвечая на один из этих вопросов, я упомянула три вещи, которыми заняты хорошие тестировщики, начиная с буквы “I”. Я вновь и вновь возвращалась к этой мысли, и думаю, что на самом деле великое тестирование состоит из пяти “I”. Если вы тестировщик, не занятый ни одной из “I”, то самое время начать.

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

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

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

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

Оригинальная публикация

Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-компания Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования.

Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA.

Регрессионное тестирование (от латинского regressio — движение назад) — это совокупность проверок ранее протестированной программы с целью убедиться в том, что внесенные в программу изменения и доработки не привели к появлению дефектов и несоответствий во всех остальных частях программы.

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

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

Привет! Меня зовут Ольга Инеева, я ведущий инженер по обеспечению качества в Т-Банке. Расскажу о проблемах тестирования интеграции и об инструменте для мокирования Mockingbird. Мы решили проблему сложных связанных сценариев и хотим поделиться этим знанием. Добро пожаловать под кат!

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

Для начала внедрения тестирования контрактов существует множество хороших ресурсов, которые помогут вам с практической стороной ваших проблем. Скажем, если вы работаете с Pact, у него есть документация и отличное сообщество в Slack – они помогут вам найти ответы на многие вопросы.

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

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