28.11.2024 00:00 |
Оригинальная публикация
Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-компания Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования. Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA. Регрессионное тестирование (от латинского regressio — движение назад) — это совокупность проверок ранее протестированной программы с целью убедиться в том, что внесенные в программу изменения и доработки не привели к появлению дефектов и несоответствий во всех остальных частях программы. А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете. |
Подробнее...
|
20.11.2024 00:00 |
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова Для начала внедрения тестирования контрактов существует множество хороших ресурсов, которые помогут вам с практической стороной ваших проблем. Скажем, если вы работаете с Pact, у него есть документация и отличное сообщество в Slack – они помогут вам найти ответы на многие вопросы.
Однако просто заставить инструменты делать то, что вам надо – не все, что нужно для внедрения тестирования контрактов, однако прочие аспекты обсуждаются куда реже. Недавно коллега-тестировщик спросил меня, нет ли у меня статьи или иного ресурса, который поможет разобраться, как начать внедрение тестирования контрактов в компании – и сходу я ничего не нашел.
Поэтому я решил написать эту статью, которая содержит ряд вопросов, на которые стоит найти ответ перед тем, как вы начнете кидаться в свои интеграционные проблемы инструментами вроде Pact. Это неполное руководство по внедрению тестирования контрактов, но это (с моей точки зрения) важные вопросы, и отвечать на них нужно до того, как вы начали писать тесты. |
Подробнее...
|
12.11.2024 00:00 |
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова Недавно я начал работать над новым консалтинговым проектом с клиентом из Великобритании. Я помогаю ему внедрить тестирование контрактов, чтобы лучше понимать, как изменения, вносимые отдельными командами в отдельные сервисы, влияют на ситуацию выше и ниже по течению в распределенном окружении.
Большинство людей, думая или говоря о тестировании контрактов, думают об ориентированном на потребителя варианте, который часто сокращают, как CDCT. Однако тестирование контрактов куда шире «только» CDCT. Одним из первых вопросов, на которые надо найти ответ, и про который часто забывают, будет вопрос «Какой тип тестирования контрактов лучше всего подойдет нашей ситуации?»
В этой статье я расскажу о трех различных подходах к тестированию контрактов, а также об их плюсах и минусах. Я не буду обсуждать тут преимущества тестирования контрактов как такового. Если вам интересно узнать больше, рекомендую эту серию статей. |
Подробнее...
|
30.10.2024 00:00 |
Автор: Кассандра Ланг (Cassandra H. Leung) Оригинал статьи Перевод: Ольга Алифанова Давным-давно я обещала рассказать о документации, которую я создаю и использую в ходе тестирования. С тех пор я перешла в другую компанию, что, конечно, повлекло риск, что создаваемая и используемая мной документация изменится, адаптируясь под нужды нового руководства, его клиентов и их подходов к работе. Однако я сейчас много читаю о сессионном тест-менеджменте (намереваясь попробовать свои силы в более структурированном исследовательском тестировании и связанных с этим сессионных отчетах), и я снова вернулась к этой теме.
Если конкретнее, я читала статью Пола Карвальо, где он упоминал про тест-руководства; эта идея, как мне кажется, схожа с документами, с которыми я постоянно работаю.
Так как я долго собиралась написать эту статью, не буду тратить на нее много времени. Однако мне хочется поделиться информацией, потому что я никогда не видела похожих шаблонов (помимо описанного Полом), и мне хочется не забыть, откуда все пошло, пока я пишу. Эта статья – мой способ поразмышлять, узнать что-то новое и вырасти над собой, поэтому хотелось бы вернуться к ней в будущем и посмотреть, что и как изменилось. |
Подробнее...
|
23.10.2024 00:00 |
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Загляните в свежий Интернет, и вы, скорее всего, найдете Еще Одну Статью про Регрессионное Тестирование, утверждающую, что регрессионное тестирование нужно автоматизировать, потому что это механическая повторяющаяся деятельность.
То, что механистическая проверка результата работы функций снова и снова – это механическая повторяющаяся деятельность, абсолютно верно, но это тавтология, чересчур упрощающая регрессионное тестирование. Что еще хуже, она может заставить нас чересчур упрощать наши представления о том, что должно произойти, и какие навыки нужно применить. Посмотрим, сможем ли мы улучшить эти представления. |
Подробнее...
|
15.04.2024 00:00 |
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Test Replay приходит в Cypress
Возможно, вы слышали новости о Cypress. Версия 13, их крупнейший релиз, демонстрирует функцию Test Replay, позволяющую пройтись по прогону своих тестов. В ходе прогона все снимки DOM, сетевые вызовы и логи консоли будут записаны, позволяя глубоко анализировать прогон.
Cypress – решение с открытым исходным кодом, но за ним стоит компания. Премиум-сервис, который эта компания предлагает – это сервис Cypress Cloud, облегчающий параллелизацию тестов, тест-аналитика, а теперь еще и Test Replay. |
Подробнее...
|
27.03.2024 00:00 |
Автор: Рауль Парваль (Rahul Parwal) Оригинал статьи Перевод: Ольга Алифанова
Исследовательское тестирование – популярный стиль тестирования ПО, который заключается в одновременном изучении продукта, проектировании тестов и их выполнении. В отличие от сценарного тестирования, исследовательское делает упор на открытия, обучение и гибкость.
Несмотря на то, что этот подход к тестированию – крайне креативный и эффективный способ поиска багов, его часто путают с несистемной, неструктурированной работой. В этой статье мы рассмотрим YATTIE, инструмент с открытым исходным кодом, позволяющий тестировщикам структурировать исследовательское тестирование, систематизировать его. |
Подробнее...
|
21.03.2024 00:00 |
Автор: Элизарян Виктория, должность: SDET/Senior QA Automation, https://www.linkedin.com/in/victoriya-elizaryan-a860a4149/ Добрый день, меня зовут Виктория и я много лет занимаюсь автоматизацией. В этой статье я хотела бы рассказать о паттернах автоматизации, которые использую, а также о такой штуке, как архитектура проекта. Я разворачивала проекты на разных языках программирования и для различных типов проектов (мобильные, веб, как чистый фронтенд, так и бэкенд). Для себя я выделила 6 паттернов программирования: |
Подробнее...
|
04.03.2024 00:00 |
Автор: ООО «Программный Продукт»
С развитием и усложнением ИТ- продуктов, стоимость регрессионного тестирования увеличивается, а требования к качеству и надежности программного обеспечения становятся всё более высокими. Мы обнаружили, что традиционные методы тестирования не всегда эффективны для масштабных и многофункциональных систем, поэтому начали применять новые техники. В этой статье мы рассмотрим композиционное тестирование, основанное на комбинаторике и системном анализе, которое значительно помогает в автоматизации процессов регресса. |
Подробнее...
|
24.01.2024 00:00 |
Автор: Роб Мини (Rob Meaney) Оригинал статьи: Tea-Time With Testers, #01/2021 Перевод: Ольга Алифанова В этой статье я расскажу, как последние пятнадцать лет изменили мое понимание тестируемости. Надеюсь, по прочтении вы разделите мой энтузиазм в отношении тестируемости. Я обнаружил, что концентрация всей команды на тестируемости – один из немногих рычагов разработки ПО, способный положительно повлиять на производительность команды. |
Подробнее...
|
|