Автор: Маарет Пюхяярве (Maaret Pyhäjärvi) Оригинал статьи Перевод: Ольга Алифанова
В ходе летней конференции Agile 2021 я занималась тем, что до этой поры никогда не удавалось закончить. Я организовывала группы, пробующие заниматься совместным программированием, и наблюдала за их деятельностью. В результате у меня получился материал, на который я сегодня наткнулась – я назвала его "Задачи для Рук, Мозгов и Голосов".
Если вы недоумевали, что нужно делать в ходе совместного программирования, то этот список может быть вам полезен.
Десять релизов в день. Десять. Релизов. В день. Реальность индустрии разработки стала такой не сегодня, и даже не вчера — скорость выкатывания новых фич стала главным требованием современной разработки, стремящейся оставаться конкурентоспособной.
А ведь десять лет назад релизы происходили раз в месяц, если не реже. Ускорение релизного цикла в сотни раз стало возможным благодаря десяткам новых инструментов и подходов в разработке и эксплуатации. Ломающий барьеры DevOps с облаками, CI/CD системами, контейнерами и мониторингами и рассчитанный на максимальный фокус и скорость Agile применяют (с переменным успехом) порядка 80% IT-компаний.
Это неизбежно приводит к смещению фокуса тестирования с ручного на автоматизацию — вручную протестировать десять релизов в день по сути невозможно. Однако переход к автоматизации для большинства компаний состоит из найма автоматизатора, выбора языка с фреймворком и последующее покрытие продукта автотестами. Однако все это — только вершина айсберга.
Баги на продакшене
2022-04-06 14:19
Как лучше и правильнее исправлять некритические баги с продакшена? Через тестовый стенд или сразу на проде?
Например, если на проде(сборка1.1) есть баги А и B и их исправили на проде(сборка1.1), а в новой версии теста(сборка1.2) есть баги А и C (и их НЕ исправили до релиза), то при релизе на продакшен(сборка1.2) перенесутся баги A и C или только C?
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
В третьей части этой серии статей мы разобрались, как создавать тесты контрактов, ориентированных на потребителя, для наших потребителей Customer и Order и провайдера Address, с целью выявить потенциальные проблемы интеграции. Процесс генерации и распределения контрактов на стороне потребителя, а также получения и верификации их на стороне провайдера, все еще содержит приличное количество шагов, выполняемых вручную. Что еще хуже, у нас нет способа закрыть петлю обратной связи – мы никак не можем сообщить всем заинтересованным сторонам результаты верификации контракта провайдером.
В этой статье вы узнаете, как автоматизировать различные шаги в потоке тестирования контрактов, ориентированных на потребителя, и сможете добавить эти тесты в свои автоматизированные наборы.
Всем доброго дня!
У меня с разработчиками дилемма, как надо править баги на проде.
Процесс фиксов багов с продакшена, по мнению разработчиков, должен происходит следующим образом:
Найденные баги на проде - исправляются только на проде. Если эти баги замечены в последующем обновлении на тестовом стенде, то их править не нужно.
Мое мнение такого: баги с продакшена нужно пропускать через последующее обновление на тестовом стенде. А затем релизить стабильную версию.
Ведь причины возникновения одного бага могут быть разными - поэтому считаю, что надежнее исправлять баги во всех сборках, пропуская через тестовый стенд.
Хотелось бы услышать ваше мнение на этот счет.
Как лучше и правильнее их править (через тестовый стенд или сразу на проде).
Хотелось бы узнать о вашем опыте!
Конкретное и разжеванное конкретное мнение только приветствуется
Если вы хотите понять,чем живетиндустрия тестирования, посетите конференциюHeisenbug 2022 Spring.Она пройдет с 30 мая по 1 июня.
Программа еще формируется, но в ней уже есть:
«Собственный нагрузчик для MongoDB. Ошибки, успехи, опыт». Доклад про нетривиальные проблемы нагрузочного тестирования и работу с replay-логами.
«Воркшоп: CI/СD глазами тестировщика». Воркшоп, на котором вы узнаете,почему CI/CD — это не только автоматический запуск тестов, какие метрики нужно включить в пайплайн и как контролировать качество с помощью Quality Gates.
«Уберите из своего резюме "разработка QA-фреймворка"». Выясним, почему «идеальный» фреймворк должен иметь около 4 публичных классов и почему иногда разработка собственного фреймворка скорее вредит.
Кроме того, 21 июня в Петербурге пройдет offline-день конференции. А этоэто дополнительная порция Q&A-сессий соспикерамии экспертами, тематических дискуссий и, конечно,докладов.
Для тех, ктопокупаетбилет за свой счет, действует скидка по промокоду: softwaretesting2022JRGpc. Она распространяется на online, online+offline и абонемент Full Pass, который открывает доступ ко всем конференциям JUG Ru Group весны и лета 2022. Помимо Heisenbug, этоDotNext, HolyJS, JPoint, Mobius, Hydra, C++ Russia.