Автор: Эди Стоукс (Ady Stokes)
Оригинал статьи
Перевод: Ольга Алифанова

Почему я написал эту статью

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

Быть «работником умственного труда» непросто. Требуются усилия, дисциплина и практика, чтобы думать за деньги. Но именно на это подписывались тестировщики, и именно это нам и предстоит делать.

Давайте поговорим о «затыках» на работе. Что это такое на самом деле, почему это происходит и что мы можем сделать, чтобы продвинуться дальше?

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Для сокращения усилий тестирования или полного прекращения тестирования какой-то области может быть множество причин.

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

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

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

Недавно я посмотрела сериал AppleTV Silo. Шоу рассказывает о жизни 10 000 человек, обитающих в подземном бункере. Они знают, что их предки жили там сотни лет, но не знают, зачем, и почему выходить наружу опасно.

Бункер работает от генератора, который обслуживает команда Механиков. В третьем эпизоде показано, что генератор не работает правильно уже 30 лет и быстро приближается к критическому состоянию. Конечно, это сразу напомнило мне о техническом долге в программном обеспечении! В этой статье я рассмотрю восемь шагов, которые команда должна предпринять для работы с техническим долгом, с примерами из Silo и из проекта, над которым я работала несколько лет назад.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В мире разработки программного обеспечения популярна идея, что за тестирование отвечает вся команда.

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

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

Обе эти крайности — непродуманные и наивные. Это примеры того, что я называю «тирания слова всегда».

Глупо утверждать, что разработчики не умеют тестировать. В процессе написания продукта они постоянно что-то тестируют: пишут код, проверяют, работает ли он; если нет — чинят; если да — двигаются дальше. Разработчик не может стабильно писать полезный код, не проверяя хоть что-нибудь хотя бы время от времени. И всё же было бы опрометчиво полагаться на то, что у разработчиков всегда есть время, мотивация, стимул и нужный взгляд на вещи, чтобы полностью взять на себя весь объём тестирования.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В предыдущей статье этой серии подробно описывалось тестирование через призму Намерения, Дисциплины, Тестируемости и Реализации:

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В прошлый раз мы рассмотрели, чего бизнес хочет от разработки. А чего бизнес хочет от той части разработки, которую мы называем тестированием?

Иногда говорят, что бизнесу от тестирования нужна уверенность — подтверждение того, что всё в порядке. Это понятно: уверенность — приятное чувство для дизайнеров, разработчиков, менеджеров и всех остальных. Но уверенность и спокойствие — это не цель бизнеса. Цель бизнеса — ценный, беспроблемный продукт.

Автор: Рависурия Ишвара (Ravisuriya Eswara)
Оригинал статьи
Перевод: Ольга Алифанова

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

А вместе с техническим долгом неизбежно появляется и тестовый долг. Определение и понимание объема и значимости тестового долга — часть моей работы.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

Задача любого тестировщика — проверять продукт на соответствие установленным требованиям и своевременно отлавливать любые баги и ошибки. В идеальных условиях или небольших проектах эта схема работает безотказно. Но в ситуациях, когда над продуктом работает несколько команд разработки, в релизы попадает по 30–70 задач, а обновления выкатываются каждую неделю, фокуса тестировщиков может просто не хватить. В таких условиях не обойтись без Quality Gates.

Меня зовут Юлия Садовникова. Я старший специалист по тестированию в команде Core Android компании ОК. В этой статье я расскажу о Quality Gates в ОК и о том, как QA может не просто тестировать, а реально влиять на проект и процессы.