Примечание: согласно моим наблюдениям, скриптованное выполнение тестов и тип регрессионных скриптов, о котором я говорю в статье, медленно отходят на второй план, однако многие организации все еще их используют. Не у всякой организации есть банда тестировщиков, работающих исследовательским методом с учетом контекста, и применяющих CI/CD, с релизами несколько раз в день. Если вы работаете в таком коллективе – отлично, эта статья, вероятно, не для вас. Но держите в уме, что многие компании все еще применяют традиционный подход к тестированию.
Последнее время я часто рассказывал о своих (неоднократных!) провалах на моем карьерном пути. К примеру, мой доклад на румынской тест-конференции начался с моего признания, что ретроспективно очень много проделанной мной до недавнего времени работы было в лучшем случае неэффективно – а в прочих случаях бессмысленно. Сейчас я медленно начинаю осознавать, что же такое автоматизация на самом деле, и как применять ее с большей пользой и эффективностью, не просто бросая в ее топку все больше и больше инструментов – эту точку зрения я поддерживал довольно долго.
Сегодня я хочу рассказать об еще одном примере деятельности, которую мне стоило бы осуществлять куда лучше.
Многие считают тестирование на production окружении вредной практикой: оно не помогает предотвратить попадание проблем к конечным пользователям, а больше констатирует их наличие. Кроме этого, тестировщик отрывается от стандартного рабочего процесса и методик, применяемых на тестовом окружении. Меня зовут Оля Михальчук, я QA-инженер в финтех-компании ID Finance. В этом посте я расскажу почему тестирование на проде может существенно помочь вашему проекту.
В современном мире Agile с его двухнедельными спринтами и частыми релизами тестированию сложно поспевать за всем. Зачастую мы полностью заняты тестированием юзер-стори текущего спринта и полагаемся на то, что автоматизация возьмет на себя регрессионное тестирование. Однако в тестировании есть ключевой компонент, про который часто забывают – это кросс-браузерное тестирование.
В прошлый раз я описывал процесс изучения факторов проектного окружения, которые влияют на мою стратегию, когда я занимаюсь тестированием API. Теперь я нырну глубже, узнаю больше, и начну взаимодействовать с продуктом. То, что я узнаю в процессе взаимодействия с ним, даст мне информацию для новых действий и базу для новых знаний.
В ходе тестирования я буду генерировать идеи, отраженные в эвристической модели тест-стратегии. Я буду думать о возможных проблемах и рисках, связанных с критериями качества, а также о том, что этим критериям угрожает. Я идентифицирую продуктовые факторы и пойму, как лучше покрыть продукт тестами. А затем я применю эти идеи на практике, используя техники тестирования.
Заметьте, что хоть я и помечаю идеи ссылками, они не берутся напрямую из модели тест-стратегии. Идеи приходят ко мне, когда я сталкиваюсь с какими-то элементами продукта и его контекста. Каждое взаимодействие с продуктом, каждое наблюдение провоцирует развитие идей о рисках и способах тестирования. Некоторые из них вытекают из моего личного опыта в разработке и тестировании, а другие – из рассказов коллег или новостей, самого продукта и его документации, и все это приводит к образованию совершенно новых идей.
Возможно, вы посчитаете, что это очень длинная статья. Ее длина отражает объем идей, посещающих тестировщика в процессе исследования.
После неожиданного успеха цикла статей о ретроспективных уроках автоматизации мне показалось, что нужно уделить больше времени областям, в которых у меня достаточно опыта, и к которым я неравнодушен. Это исследовательское тестирование – или, как я буду называть это далее, просто исследование.
Зачем это нужно? Мне кажется, что я посылаю некоторым людям смешанные сигналы – мне пришлось отклонить ряд запросов на консультации по автоматизации, потому что люди решили, что я эксперт в этой сфере. Мне очень льстит быть так высоко оцененным, но положа руку на сердце, я не могу претендовать на эту честь. Я любитель-самоучка, у которого достаточно смелости на то, чтобы иметь мнение, и есть блог, где этим мнением можно поделиться. Что касается уровня моих навыков, я считаю, что они находятся на необходимом минимуме. В любом случае, я не разделяю взгляд на автоматизацию, сконцентрированный на инструментарии, и полагаю, что большая часть проблем, связанных с автотестами, в том, что люди недостаточно хорошо понимают тестирование. Ретроспективные уроки автоматизации отклонились от моей первоначальной цели – создания отсутствующего звена между тестированием и автоматизацией, слишком отойдя к технической стороне автотестов. Если основной задачей цикла была демонстрация, что имеет смысл автоматизировать для помощи тестированию, необходим еще один цикл, показывающий, что наиболее важно с точки зрения тестировщика, и что автоматизаторы должны знать о целях и сути экспертного тестирования.
Я решил, что этот цикл будет называться "Ретроспективные уроки исследовательского тестирования". Он также будет полезен тем, кого интересует исследовательская часть тестирования, и кто устал от просьб строго следовать сценариям, хотя толка от этого немного.
Девушки рассказали о парном тестировании, о задачах, которые оно помогает решить, и привели пример неудачного использования практики.
В методологии XP есть практика — парное программирование. Во многих источниках написано о массе его преимуществ: высоком качестве кода, взаимозаменяемости разработчиков и т. д.
Если парное программирование настолько эффективно, то почему бы не применить аналогичные принципы в тестировании? Да, это можно сделать, парное тестирование существует давно и хорошо себя зарекомендовало. Но не стоит забывать, что любая практика является всего лишь инструментом для решения каких-либо задач.
В Википедии нет термина «парное тестирование», но есть определение для парного программирования, которое можно взять за основу. Тогда, на наш взгляд, мы получаем следующее.
Парное тестирование — это техника, при которой тестирование одной функциональности производится парой людей за одним рабочим местом. Один тестировщик («ведущий») управляет компьютером, второй («штурман») непрерывно следит за работой первого. При этом на всем протяжении работы над задачей они обмениваются идеями и обсуждают их.
Любая практика — всего лишь инструмент. Мы не хотим забивать гвозди микроскопом, поэтому всегда отталкиваемся от задачи. Давайте рассмотрим те задачи, для которых релевантно использование практики «парное тестирование».
Публикуем запись доклада Максима Бакирова "Фаззинг или тестирование мусорными данными" с прошедшего в Новосибирске QA DevDay.
Стоит отметить, что Макс пишет на С++ и его доклад очень близок к unit-тестированию. Однако, даже если тема вам не близка, посмотрите видео для развлечения. Наши гости единогласно заметили, что за фаззингом будущее.
Регрессионное тестирование– это набор тестов, направленных на обнаружение дефектов в уже протестированных частях приложения.
Не секрет, что скорость регресса является важным элементом общего процесса:
Во-первых, от нее зависит, как быстро мы пофиксим найденные баги;
Во-вторых, она влияет на общую скорость релиза;
В-третьих, высокая скорость уменьшает общий бюджет проекта.
Именно поэтому на своих проектах мы непрерывно работаем над сокращением срока проведения регрессионного тестирования. Например, в мае мы проводили очередную итерацию ускорения на проекте по тестированию страхового ПО и теперь можем гордиться достигнутым результатом.
