Home

Автор: Сумиа Мухерджи (Soumya Mukherjee)
Оригинал статьи: Tea-Time With Testers, #02/2021
Перевод: Ольга Алифанова

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

Оригинал статьи размещен в блоге компании "Россельхозбанк"
Автор: Демидова Наталия

Привет! Мы тестировщики платформы «Свое Родное» от Россельхозбанка. В статье расскажем о нашем проекте, как проводят релизы и регрессы, а также затронем актуальную тему работы приложений — обработку ошибок, а именно ошибку «Что-то пошло не так», которая встречается повсеместно.

Авторы: Алексей Чичук, Владислав Литвинов, Анастасия Стрижеченко
Оригинал статьи размещен в блоге компании «Точка» на сайте Хабр

Привет, мы Алексей Чичук, Анастасия Стрижеченко и Владислав Литвинов — тестировщики из банка Точка.

И сегодня мы расскажем, как и почему мы используем JMeter для функционального тестирования.

Автор: Никола Линдгрен (Nicola Lindgren)
Оригинал статьи
Перевод: Ольга Алифанова

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

Ниже – ряд идей, как быть с плавающими багами.

Публикуем подборку докладов с конференции SQA Days 24, посвященную функциональному тестированию.

1. Интеграционное тестирование: основано на реальных событиях – Любовь Копылова, Lamoda (Москва).
2. Testing in production – Гойко Адзич (Gojko Adzic), Neuri Consulting LLP (Лондон).
3. Техника ABCD: от создания модели до проектирования тестов – Евгений Клименко, TDNA (Запорожье).
4. Анализ использования ресурсов приложениями в ОС Windows – Василий Буров, Quest Software (Санкт-Петербург).

Автор: Андрей Петров

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

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

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

Аддоны к браузерам вряд ли пригодятся в автоматизации тестирования web-систем, но при ручном тестировании они могут оказаться полезны. К примеру, можно заполнять элементы на выбранной странице, исходя из своих условий и входных данных. Ниже рассмотрено создание такого аддона для Firefox и Chrome без претензий на красоту кода.

Задача: разработать аддон для Firefox и расширение для Chrome со следующей функциональностью:

1. В тулбаре появляется кнопка (иконка).
2. При нажатии на эту кнопку анализируется URL активной страницы (вкладки). Если URL – один из заранее заданных URLs, то при нажатии на кнопку тулбара скрипт берет пару “пользователь-пароль” из опций в зависимости от URL и заполняет поля ввода логина и пароля на странице. Далее скрипт нажимает кнопку логина.

Автор: Ольга Панина

Оригинальная публикация: http://quality-lab.ru/key-principles-of-black-box-testing/

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

Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию). Хочу обратить внимание на то, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.

Что такое «черный ящик» согласно терминологии ISTQB?

Автор: Джо Колантонио (Joe Colantonio)

Оригинал статьи: https://techbeacon.com/5-top-open-source-api-testing-tools-how-choose

https://www.joecolantonio.com/2017/05/16/12-open-source-api-testing-tools-rest-soap-services/

Перевод: Ольга Алифанова

Сдвиг влево, происходящий благодаря таким процессам, как непрерывная интеграция и непрерывные релизы, приводит к растущей необходимости быстрой обратной связи от тестировщиков.

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

Прежде чем рассматривать инструменты тестирования API, давайте убедимся, что мы одинаково понимаем, что это вообще такое.

Автор: Джорис Меерц (Joris Meerts), Testing References

Оригинал статьи: http://www.testingreferences.com/docs/Functional_Testing_Heuristics.pdf

Перевод: Ольга Алифанова

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

Список основан на моем личном опыте тестирования программных продуктов. Я также благодарен Джеймсу Баху за эвристику SFDPOT, и Элизабет Хендриксон, Джеймсу Линдси и Дейлу Эмери, как создателям чит-листа эвристик тестирования.