Home

Автор: Боков Максим
Оригинальная публикация

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

Автор: Грегори Пачига (Gregory Paciga)
Оригинал статьи
Перевод: Ольга Алифанова

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

Что же с этим делать?

Недавно я задал этот вопрос в Slack-группе тестировщиков и на форуме Министерства Тестирования. Вот основные идеи, рожденные в этих обсуждениях. Я расположил их по степени полезности, от наименее полезных к наиболее. Спускаясь ниже, мы подберемся ближе к тому, что я считаю первопричиной. Буду рад услышать другие мысли на этот счет.

Автор: Ольга Назина (Киселёва)

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

Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.

Heisenbug 2021 Moscow состоится уже 5 октября. Пора решать, идете ли вы на конференцию. А чтобы доказать вам, что оно того стоит, в этом посте мы собрали самый сок программы.

Прежде всего, гвоздь программы: на конференции выступит Кент Бек — легенда IT-мира, один из создателей Agile-манифеста, методологии экстремального программирования и идеи фреймворка для юнит-тестов (на ней основаны smalltalk и JUnit), популяризатор TDD.

Его доклад “Test Run Latency” будет посвящен альтернативному workflow в TDD: Test && Commit || Revert aka TCR. Кент Бек в нем расскажет, зачем измерять время до первого отказа в тестах и чем это лучше традиционного измерения пропускной способности тест-кейсов.

В программе  не только доклады, но и воркшопы, на которых можно будет освоить новые инструменты и методики:

• Максим Забунков, "Пересмотр подхода к тестам на примере React Web App". Максим проведет воркшоп, посвященный Shift-left на примере Web-тестов и покажет, как избавиться от издержек с помощью компонентных тестов.
• Олег Ненашев, "Без протечек и засоров: Тестируем Jenkins Pipeline". Олег предложит поговорить о статическом анализе Jenkins Pipeline, unit- и интеграционном тестировании, и о CI/CD для Pipeline… с помощью Jenkins Pipeline.
• Роман Давлятшин, "Воркшоп: как оценить качество тестов на Cypress и сделать их быстрее при помощи Drill4J". Когда приложение обрастает миллионом тест-кейсов, бывает трудно уследить за всем. Легаси-тесты «крутятся» впустую, ручное тестирование становится мучительно долгим... В этом воркшопе вы узнаете, как Drill4J поможет выкарабкаться из пучины этих проблем.
• Артем Ерошенко, "Fullstack QA: Разбираемся в зоопарке тестов". Артем поднимет простое приложение на Java+TS и покроет его набором разнообразных тестов. После воркшопа вы будете намного лучше понимать, как устроены продукты, которые вы тестируете, какие тесты и когда лучше применять вместо старых добрых E2E.
• Яков Крамаренко, "Selenide на Python за 2 часа". Яков расскажет, почему функций Selenium WebDriver недостаточно для эффективных UI-тестов. А затем покажет, как написать с нуля ядро враппера с API в стиле Selenide/Selene на Python.
• Bas Dijkstra, "Improving your integration testing efforts with consumer-driven contract testing". Микросервисы хороши для разработки, но в их тестировании есть некоторые сложности. На воркшопе вы узнаете, как контрактное тестирование помогает с ними справляться.

Все это — лишь малая часть программы. Узнать больше можно на сайте конференции.

И не забудьте воспользоваться промокодом softwaretesting2021JRGpc. Он поможет приобрести вам Personal Standard билет со скидкой.

До встречи на Heisenbug!

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

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

Меня зовут Руслан, я — автотестировщик в QA-агентстве «Кавычки». Из этого можно понять, что мы в агентстве занимаемся только тестированием во всех его проявлениях, а меня зовут Руслан. Отлично, идем дальше. Когда какая-то проблема начинает сильно докучать, то даже тестировщики могут что-то создать (ну или сломать это к черту, чтобы не мешало). Это статья как раз про тот случай, когда наша проблема перешла совместимый с жизнью болевой порог, и нам пришлось решить ее с помощью собственной разработки.

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

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Вступление

Сегодня я расскажу вам про Record-and-Replay подход к тестированию т. к. я его понимаю. Оговорка про мое понимание не случайна. Про этот подход не так много общедоступных материалов, чтобы иметь некий common agreement относительно значения этого термина. Многое из того, что я опишу, является моими личными оригинальными находками, но, тем не менее, фраза record-and-replay, на мой взгляд, наилучшим образом описывает применяемые мной решения. Так что я буду использовать именно ее.

Чтобы было проще понять, какие проблемы решает RnR, в ходе этого разговора мы сначала обсудим некоторые другие подходы к написанию тестов (юнит-тестирование, интеграционное тестирование и т. д.). И отталкиваясь от их недостатков перейдем к варианту с RnR, я расскажу, что же это собственно такое, как это работает, и каким образом решает озвученные ранее проблемы. Поговорим про подводные камни, которые могут свести пользу от внедрения всего этого дела к нулю. Ну и, конечно, обсудим недостатки или границы применимости этого подхода.

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