Home

Меня зовут Юрий Заковряшин. Я занимаюсь разработкой ПО более 40 лет, преподаю курсы по технологиям разработки программного обеспечения и программированию на платформе Java в СПбПУ Петра Великого.

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

Привет, меня зовут Нина Полторакова, я ведущий тестировщик в ГК Юзтех. 

На данный момент мы с командой занимаемся разработкой и поддержкой ИТ-решений по направлению Life — страхование жизни.

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

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

Ни шагу дальше! Тот, кто хочет пересечь Мост Смерти, должен ответить мне на три вопроса, и если ответит неправильно, Мост оправдает своё название.

Большинство из нас, ботаников (и не ботаников) видели фильм «Монти Пайтон и Священный Грааль». Сцена на Мосту Смерти чаще всего цитируется и парафразируется. Концепция трех вопросов (не путать с тремя раковинами) заставила меня задуматься о тест-автоматизации.

Мой хороший друг и коллега Джо Колантонио, создатель Test Guilds и соответствующих конференций, запустил новую рассылку «Автоматизированы ли вы?» - название вдохновлено альбомом Джимми Хендрикса «Опытны ли вы?» Это напомнило мне, что я размышлял о бинарной природе автоматизации. Я уже писал о том, автоматизировано что-то или нет, но рассылка Джо заставила меня задуматься серьезнее.

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

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

Мой опыт говорит, что тому есть девять основных причин. Читайте дальше, чтобы проверить, применимы ли они к вашей команде!

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

Меня зовут Антон Морозов, я инженер по тестированию в Яндекс 360. Я работаю над мобильным Яндекс Диском — это проект с тысячами тест-кейсов, который развивается уже тринадцатый год. 

Погружение в продукт и новую команду — непростая задача для новичка, но нам удалось выстроить безболезненную адаптацию (отток за 4 года составил 0%). В статье поделюсь практиками в команде QA, которые помогли нам за последние четыре года успешно адаптировать новичков.

Небольшие дисклеймеры перед прочтением статьи

1. Статья — наш личный опыт, который сработал конкретно в нашей команде. Эти практики не волшебная таблетка, а то, что работает конкретно у нас.

2. У нас есть общекорпоративный процесс адаптации, погружение в культуру компании, отдельные курсы для новичков. Команда Яндекс 360 делает собственные мероприятия для знакомства новичков, а руководитель готовит план адаптации. В статье речь пойдёт о более прикладных советах, которые помогут быстрее погрузиться в продукт.

Автор: Яник Диксон (Yanique Dickson)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Рауль Парваль (Rahul Parwal)
Оригинал статьи
Перевод: Ольга Алифанова

Сколько мы уже покрыли, сколько еще находится в очереди?

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

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

Всем привет! Меня зовут Александр Наумов, я работаю в SM Lab на позиции куратора тестирования. Сегодня я хотел бы поговорить о такой интересной вещи как CJM на продукте и о том, чем она может быть полезна тестировщику.

Начнем с определения — что такое CJM.

CJM (от англ. customer journey map) воспроизводит путь, который проходит клиент от осознания потребности в продукте до его покупки, а иногда и после неё. Всё это время он взаимодействует с продуктом и компанией и принимает решение на основе полученного опыта. Другими словами, это визуализация путешествия клиента по продукту

Автор: Блейк Норриш (Blake Norrish)
Оригинал статьи: Tea-Time With Testers, #03/2021
Перевод: Ольга Алифанова

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