Home

Автор: Кинга Витко (Kinga Witko)
Оригинал статьи
Перевод: Ольга Алифанова

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

Отличный способ попробовать что-то новое – это превратить ваши тест-сценарии в настоящих мутантов.

Автор: Рыжова Татьяна, руководитель отдела тестирования, компания InfoWatch, www.infowatch.ru/resources/blogs

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

Автор: Дэн Эшби (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. В этом посте я расскажу почему тестирование на проде может существенно помочь вашему проекту.