Home

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я разговаривала с коллективом и предположила, что тестирование – не всегда решение вопроса. Они были озадачены.

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

У тестирования и автоматизации два основных принципа, и если вы меня знаете, то, возможно, уже про них слышали:

1. Тестирование – это про верный баланс.

2. Автоматизация – это про экономию времени.

Оба связаны с издержками: в первом случае, если тестировать дороже, чем продолжать без тестирования, то лучше пропустить этот тест (или тесты).

Во втором случае, если автоматизация займет больше времени, чем общее время на ручное тестирование, автоматизировать не нужно.

Принципы, возможно, звучат очевидно, но в реальности не так-то просто принять решение не тестировать или не автоматизировать. Это контринтуитивно, и в голове звучат панические «А что, если».

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

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

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

Привет! Я Екатерина Васильева, инженер-тестировщик ГК «Солар». В нашей работе есть извечный вопрос, как сделать тестирование быстрым, качественным и эффективным. И знаете, что помогает? Правильная организация процесса. В «Соларе», например, мы активно используем концепции DoR (Definition of Ready) и DoD (Definition of Done) при тестировании продуктов. Эти критерии, хоть и встречаются чаще в разработке, оказались невероятно полезны и для нас, тестировщиков. Они помогают четко понимать, когда задача готова к тестированию, а когда уже можно выдохнуть и сказать: «Готово!». В итоге — никаких срывов сроков и релизы день в день. В этой статье я расскажу на примере Solar webProxy, как DoD и DoR помогают нам повысить качество тестирования и с какими трудностями мы столкнулись, внедряя эти критерии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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