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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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