Home

Автор: Дэн Эшби (Dan Ashby)
Оригинал статьи
Перевод: Ольга Алифанова

Часть 1

Часть 2

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

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

Автор: Дэн Эшби (Dan Ashby)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

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

Поразмышляв и поэкспериментировав, я сформулировала пять идей для начала тестирования даже в условиях отсутствия инструментария.

Автор: Дэн Эшби (Dan Ashby)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы регулярно следите за моим блогом – хотя я нерегулярно пишу – или слышали мои выступления, то, возможно, слышали, как я говорю нечто вроде "Тестирование похоже на науку" или "Наука тестирования". Это звучит веско и броско, но я пока что видел немного хороших объяснений, почему это так. Я этого тоже не объяснял, поэтому в том есть и моя вина.

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

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

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

Итак,…

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

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

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

Автор: Баз Дийкстра (Bas Dijkstra)
Оригинал статьи: https://www.ontestautomation.com/on-ending-the-regression-automation-fixation/
Перевод: Ольга Алифанова

Примечание: согласно моим наблюдениям, скриптованное выполнение тестов и тип регрессионных скриптов, о котором я говорю в статье, медленно отходят на второй план, однако многие организации все еще их используют. Не у всякой организации есть банда тестировщиков, работающих исследовательским методом с учетом контекста, и применяющих CI/CD, с релизами несколько раз в день. Если вы работаете в таком коллективе – отлично, эта статья, вероятно, не для вас. Но держите в уме, что многие компании все еще применяют традиционный подход к тестированию.

Последнее время я часто рассказывал о своих (неоднократных!) провалах на моем карьерном пути. К примеру, мой доклад на румынской тест-конференции начался с моего признания, что ретроспективно очень много проделанной мной до недавнего времени работы было в лучшем случае неэффективно – а в прочих случаях бессмысленно. Сейчас я медленно начинаю осознавать, что же такое автоматизация на самом деле, и как применять ее с большей пользой и эффективностью, не просто бросая в ее топку все больше и больше инструментов – эту точку зрения я поддерживал довольно долго.

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

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

Автор: Ольга Михальчук, QA инженер ID Finance

Многие считают тестирование на production окружении вредной практикой: оно не помогает предотвратить попадание проблем к конечным пользователям, а больше констатирует их наличие. Кроме этого, тестировщик отрывается от стандартного рабочего процесса и методик, применяемых на тестовом окружении. Меня зовут Оля Михальчук, я QA-инженер в финтех-компании ID Finance. В этом посте я расскажу почему тестирование на проде может существенно помочь вашему проекту. 

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи: http://thethinkingtester.blogspot.com/2018/07/cross-browser-testing.html
Перевод: Ольга Алифанова

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи: http://www.developsense.com/blog/2018/07/exploratory-testing-on-an-api-part-3/
Перевод: Ольга Алифанова

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

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

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

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