Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

В противовес моей идее о том, что тестирование программного обеспечения должно быть ролью, а не просто задачей, мне иногда говорят, что «настоящий Agile» этого не допускает. Почему? Потому что в Agile «качество — ответственность каждого». Это утверждение иногда подаётся так, будто это моральная истина, не подлежащая обсуждению, или же как моральное достижение, уникальное для аджайлистов, будто предыдущим поколениям разработчиков программного обеспечения никогда не приходило в голову помогать друг другу создавать хорошие вещи.

В любом случае, для меня это не имеет смысла.

Первая мысль, которая приходит в голову: «Я говорю о тестировании, а не о качестве. Почему сюда притягивается качество?» Тестировщики не обеспечивают качество. Тестировщики НЕ МОГУТ обеспечить качество. Тестировщики сейчас и никогда не «владели качеством» ни в каком смысле.

Но даже если отложить это в сторону, качество не должно считаться «ответственностью каждого». Вот почему меня беспокоит эта формулировка:

На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда».

Мы регулярно сталкиваемся с ситуациями, когда в Jira к задаче вроде есть какое-то описание, стоит статус «готово», но, чтобы понять, в чем была проблема, что было исправлено, как было проверено, приходится «нырять» в мессенджер или звонить коллегам. Все это съедает время, размывает ответственность между командами и мешает выпускать продукт быстро, качественно, в срок.

Вот несколько реальных примеров, когда описание к задаче похоже на квест:   

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

Существует множество способов «ускорить что-то в 10 раз».

• Ехать со скоростью 300 миль в час по оживлённой городской улице.
• Съесть 15 000 калорий за один приём пищи.
• Завести десять собак.
• Родить десять детей.
• Завести сотни друзей.

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

Потому что они говорят и действуют безответственно.

Артём Мотовилов
Оригинальная публикация

Предисловие

Эта статья — не критика Agile или Kanban как подходов и не попытка доказать, что в IT «всё делают неправильно». Я делюсь наблюдениями из собственного опыта работы с качеством в промышленности, энергетике, а затем — в IT‑продуктах.

Речь пойдёт не о терминах и инструментах, а о том, как часто теряется системное мышление, когда сложные управленческие модели упрощаются до ритуалов.

Если у вас уже выстроена работа и всё стабильно — это отлично. Если нет — возможно, некоторые наблюдения покажутся полезными

Автор: Воробьева Юлия

Всем привет! Меня зовут Юлия, и уже 6 лет я занимаюсь тестированием. За свою карьеру я успела принять участие в разных проектах компаний от стартапов до гигантов индустрии, тестировала бэк, фронт, мобилки, веб и даже устройства интернета вещей, успела дорасти до тимлида и начать осваивать автоматизацию.

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

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

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

Я хочу рассказать, как я сделала отчет о дифференциальном тестировании (сравнение двух функций на одних данных) через ИИ. Знаю, что многие уже применяют ИИ и в хвост и в гриву, но также много тех, кто пока не умеет этого делать.

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

Автор: Ужвал Кумар Сингх (Ujjwal Kumar Singh)
Оригинал статьи
Перевод: Ольга Алифанова

Сигнал к пробуждению

Я занимаюсь тестированием программного обеспечения уже три года. Тестировал разные типы приложений, следовал всем профессиональным практикам, выполнял тест-кейсы и отмечал все пункты.

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

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

Тогда ко мне пришло осознание: тестирование велось мной механически. Но программное обеспечение создаётся для людей.

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

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

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

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

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

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

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

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

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

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

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

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