Автор: Ольга Назина (Киселёва), автор курса Школа для начинающих тестировщиков

Про типы границ я впервые услышала на тренинге Алексея Баранцева. Зачем они нужны? Да просто чтобы не забыть всё проверить. Написал чек-лист, потом проверяешь себя:

— Все учел? Вот эти классы эквивалентности, какие границы логические? А какие технологические? ...

Так можно вспомнить о проверке, про которую забыл или просто не подумал! Полезная штука.

Алексей дал нам тогда про такую типизацию границ:

• Физическая — которую физически нельзя преодолеть.

• Логическая — ограничение, накладываемое логикой, не программой.

• Технологическая — ограничение, накладываемое используемой технологией.

• Произвольная — ограничение, наложенное аналитиком или заказчиком.

Автор: Арун Вишванатан (Arun Vishwanathan)
Оригинал статьи
Перевод: Ольга Алифанова

Проблема: отладка билдов в быстро меняющемся мире

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

Представим, что команда обнаружила баг в недавней версии продукта. Где-то по пути что-то пошло не так. Но как понять, когда именно всё начало ломаться?

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

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

Автор: Александр Заплавный

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

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

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

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

Автор: Ольга Назина (Киселёва)

Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов.

И в автотестах Postman он особенно хорош! Давайте разберемся на примерах, почему лучше писать небольшие автотестики, «один тест, одна проверка», чем «много проверок в одном тесте».

Автор: Маниш Саини (Manish Saini)
Оригинал статьи
Перевод: Ольга Алифанова

Введение в тестирование «shift-вниз»

Исследуя тестирование программного обеспечения, часто слышишь про два подхода: shift left (сдвиг тестирования на более ранние этапы разработки) и shift right (расширение тестирования до прода). Оба подхода полезны, как проверка дома во время строительства и после него. Однако существует ещё одно измерение, которое заслуживает внимания — сдвиг вниз, ближе к фундаменту кода.

Представьте, что вы строите дом. Разве вы начнёте украшать стены до того, как убедитесь, что фундамент прочен? Схожим образом в тестировании ПО (хоть мы зачастую сосредотачиваемся на проверке того, что видят конечные пользователи, на стенах и декоре) тщательное тестирование фундамента приносит огромную пользу. Здесь и приходит на помощь сдвиг тестирования вниз.

Автор: Павлович Евгений

Введение

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

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

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

Привет! Я Наталья, QA в команде инкассации. Моя система умеет планировать маршруты для инкассаторов T-Банка. Поделюсь докладом моего коллеги — архитектора Boxy SDK Дмитрия Кузнецова, — который услышала на конференции Heisenbug. 

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

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

Тестирование — это наука не о том, чтобы доказать, что программа работает корректно, а о том, чтобы доказать, что она работает НЕкорректно. И если доказать это не удалось, то с какой-то вероятностью программа работает корректно. Остается некоторый пробел. Давайте рассмотрим, что за это за пробелы, откуда берутся и как можно их минимизировать.

Автор: Анна Север (Литвинова), Ведущий инженер по качеству, Рексофт

Любите ли вы чек-листы так, как люблю их я?

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

В этом процессе осознали, что каждый обращает внимание на что‑то своё, и пора бы это стандартизировать и расшарить на команду (обмен опытом, наш любимый). Так был создан чек‑лист проверок для ревьюера тест‑кейсов.

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

Автор: Венкат Рамакришнан (Venkat Ramakrishnan)
Оригинал статьи
Перевод: Ольга Алифанова

Тестирование персональных предложений критически важно для приложений, применяющих ИИ и предлагающих такую возможность. Эти предложения важны как для Apple Intelligence в iPhone 16.0, так и для других областей, так как применяются для:

• Предложения часто используемых приложений
• Уведомлений на основании времени, локации или деятельности
• Рекомендаций при поиске (приложений и виджетов)
• Интеллектуального ввода текста.

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

Автор: Саймон Томс (Simon Tomes)
Оригинал статьи
Перевод: Ольга Алифанова

Сообщество тестировщиков – собрание умных людей с богатым опытом и множеством идей. Мы собрали ряд идей для тестирования ПО – возможно, они помогут вам при регрессионном тестировании, тестировании API, исследовательском тестировании, мобильном тестировании, тестировании миграции данных, релизном тестировании, следующем bug bash и многом другом!

Как этим пользоваться:

1. Проматывайте список вверх-вниз, остановитесь на случайном месте страницы.
2. Выберите любого тестировщика и станьте им (некоторые тестировщики предложили более одной идеи).
3. Посмотрите на эвристику тест-идеи.
4. Примените ее при следующей сессии тестирования.

БОНУС: скомбинируйте несколько идей.

ДВОЙНОЙ БОНУС: свяжитесь с автором и поблагодарите его. Дайте ему знать, что он вам помог.

ТРОЙНОЙ БОНУС: поделитесь своим успехом в клубе.