Home

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

Мы уже изучили больше половины принципов SOLID! Сегодня настало время узнать про букву I: принцип разделения интерфейсов.

Чтобы понять этот принцип, надо сначала разобраться, что такое интерфейс. Интерфейс – это определение набора методов, который можно реализовать в классе. Каждый класс с реализацией интерфейса должен использовать все включенные в интерфейс методы. Так как интерфейс определяет только подпись метода (имя, параметры и тип возвращаемого значения), методы могут варьировать в разных реализациях.

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

Автор оригинала: Matt Proud

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

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

• Бывают медленные модульные тесты.

• Бывают быстрые функциональные тесты

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

• Доступ к сети;

• База данных;

• Доступ к файловой системе;

• Многопоточность.

Автор: Пол Гриззаффи (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. Все они демонстрационные – в реальной жизни и публичных приложениях они не используются. Следовательно, все обсуждаемые уязвимости абсолютно безвредны, если вообще не внедрены специально.