Я Software Engineer in Test (SET). Многие не совсем понимают, что это значит. Разработчики часто называют меня «тестировщиком» или «QA», а бывший директор однажды подумал, что я занимаюсь DevOps. Хотя моя работа и охватывает данные области, они не являются моим основным направлением занятости. Давайте я постараюсь прояснить, что значит быть SET.
В этом материале будет кратко рассказано, почему Shift-Left – это не всегда хорошо и почему не стоит забывать о традиционной модели тестирования. Рассмотрим паттерны поведения QA при тестировании обычных задач и как постепенно стать продуктивным тестировщиком, не утопая в регрессах и бесконечных проверках одного и того же.
Тесты написаны, тимлид рад, а что дальше-то делать? А дальше - автоматизация и отправка отчёта по тестам. Именно об этом мы и поговорим в данной статье, попутно затронув полезный инструмент TestExplorer и декоратор tag.
Selenium – один из самых популярных фреймворков автоматизации тестирования. Несмотря на то, что Selenium поддерживает шесть популярных языков программирования, его можно использовать для волшебной реализации с наименьшим количеством кода в связке с Python.
Сколько раз мы видели инфраструктуру и методологию тестирования, когда команда не может получить своевременную обратную связь о производительности разрабатываемой системы? Как правило, к тестированию производительности принято относиться как к "проекту по методу водопада", когда мы, тестировщики, готовим тест и запускаем его в продакшн непосредственно перед деплоем. Однако есть лучший способ сделать это, и он заключается в непрерывном тестировании производительности. При правильной имплементации оно (непрерывное тестирование) придает уверенность разработчикам и предупреждает их о любом существенном снижении производительности системы.
Миру требуется все больше и больше софта: любой магазин или автосервис хочет сайт или мобильное приложение. Но забагованный софт не хочет никто. Нам нравится, когда все работает красиво и корректно. Эффективно искать баги помогает тестирование, иногда даже автоматическое. Вот про этот случай мы и поговорим.
В своем докладе на конференции TestDriven Conf 2022 Станислав Васенков предлагает за минуту создать из ручного теста проект с автотестами в боевой инфраструктуре. О том, как разрабатывался генератор, можно узнать из интервью.
Кроме того, мы обсудили актуальные проблемы современного тестирования и поговорили о том, почему искать тестировщиков для компании должен не HR, а инженер, говорящий с кандидатом на его языке.
Андрей Лушников выступил у нас на Heisenbug с докладом о Playwright ещё в 2020-м. Но похоже, что с тех пор тема доклада стала только актуальнее: 34 000 звёзд проекта на GitHub ясно показывают, что он пришёл к популярности. А Андрей по-прежнему остаётся одним из главных контрибьюторов Playwright. Поэтому мы решили сделать для Хабра текстовую версию его доклада.
Конечно, за два года проект успел уйти вперёд (обзавёлся своим тестраннером и локаторами), но база осталась прежней, так что информация по-прежнему может быть полезной. Если вы ощущаете, что и вам пора приобщиться к этому инструменту — вот материал от того, кто точно глубоко разбирается в теме.
Видео и расшифровка — под катом. Далее повествование будет вестись от лица спикера.
Привет! Меня зовут Антон, я ведущий инженер по тестированию в Ozon: занимаюсь созданием и поддержкой end-to-end Go-тестов бэкенда для QA.
Мы довольно долго писали тесты в основном на Python. Go – молодой язык, и популярных устоявшихся инструментов у него пока немного. В Python есть pytest, в Java – JUnit и TestNG, в Go – пока что весьма свободно.
Однажды, в очередной раз переписав группу старых Python-тестов, я решил, что надо что-то менять. Эта мысль в итоге привела меня к созданию нашей собственной опенсорс-библиотеки – с поддержкой Allure без перегрузки интерфейса, инфраструктурой для хранения тестов как в одних репозиториях с сервисами, так и в отдельных, репортами в Slack и разными другими штуками.
Почему мы всё-таки решили создать своё решение, с какими сложностями пришлось разбираться в процессе и как это может пригодиться вам для тестов на Go, я расскажу в этой и следующих статьях. Сегодня – об интеграции с Allure.
В прошлой статье мы познакомились с тестами для Django и создали личного пользователя-тестировщика. Самое время продолжить изучать тестирование сайта, написав проверку русских символов на английских страницах и разобрав тесты для JavaScript.
Привет, Хабр!
Меня зовут Николай, и я тестировщик («Привет, Николай!»,- кричат участники собрания анонимных тестировщиков). Как и многие другие обитатели Хабра состою в нескольких тематических чатах и группах по QA, в которые время от времени приходят желающие «войти в IT» люди с вопросами «как найти работу, начинающему тестировщику?» или «с сего начать поиск вакансий?» и т.д.
Этот текст в первую очередь для них.
На сегодняшний день это один из, или же самый известный способ автоматического анализа кода и его ревью. Популярностью он обязан тому, что этот сервис бесплатен и доступен, а так же для его установки не требуется много усилий. Интерфейс выглядит современно и понятно. Sonarqube, хоть и написан на java, не ест много ресурсов :)
Короткая инструкция о том, как наладить создание и запуск python автотестов для web-приложения. При этом не потребуется целый штат DevOps специалистов и огромного бюджета. Интересная статья для тестировщиков из стартапов.
Как прямая автоматизация тест кейсов приводит к громоздким и раздутым наборам автотестов, которые практически не приносят пользы.
Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.
К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.
В этой статье мы продемонстрируем, почему «фабрики автоматизации» неэффективны и опишем более правильный подход к автоматизации, который гарантирует, что автоматизация тестирования поддерживает и ускоряет скорость разработки.
Издержки и преимущества автоматизации тестирования
Чтобы понять, почему автоматизация существующих тест кейсов настолько проблематична, нам нужно вернуться назад и немного проанализировать теорию автоматизации. В частности, нам нужно изучить издержки и преимущества автоматизации, посмотреть на ожидаемую ценность автоматизированных тестов во времени, а затем оценить, как ожидаемая ценность меняется в различных типах тестов. Затем мы сможем увидеть, как автоматизация тест кейсов с использованием простого подхода «фабрики автоматизации» повлияет на тестирование в целом.
Недавно на проекте, на котором я работал, мы столкнулись с проблемой рефакторинга одной из самых больших форм нашего UI. Сама форма принадлежит более сложной форме, включающей пару шагов с входными данными, зависящими друг от друга, некоторые другие извлекают данные из нашего API GraphQL, что в сумме дает несколько путей, которые может выбрать пользователь.
QA-эксперт с опытом под 20 лет анализирует наполненность программ девяти QA-курсов, их сроки и еженедельное число часов загрузки. Она поможет абитуриентам выявить как не слишком амбициозные курсы, пропускающие важные части теории, так и наоборот - курсы, где в относительно небольшое число часов впихнуто невпихуемое. И обучение из-за этого стремительно несется мимо мозгов.
12 студентов с этих же курсов дают обратную связь о том, как это все происходит внутри на самом деле.
Aloha всем хабравчанам! Я Влад, системный администратор Cloud4Y. В этой статье расскажу, как мы выбирали продукт сканирования на уязвимости, почему важно контролировать, какие сервисы доступны извне и зачем необходимо проводить постоянный аудит состояния сети. Чай, кофе, па-а-а-аехали!
Привет, Хабр! Меня зовут Александр, я разработчик в юните, который является центром экспертизы по качеству в Авито. Мы помогаем командам с внедрением эффективных и современных подходов тестирования, а также разрабатываем инструменты для тестирования и управления качеством.
В этой статье я расскажу про мутационное тестирование: почему мы внедрили его в компании, что это вообще такое и как проходило внедрение по шагам.
...Что, если бы мы могли сделать наш код полностью пригодным для тестирования таким образом, чтобы от нас не требовалось вводить какие-либо новые протоколы, всевозможные моки или сложные абстракции? Давайте же разберемся, как мы могли бы реализовать это, используя новые возможности async/await Swift.
Сомнительные подходы к тестированию в Agile-разработке.
У Agile-разработки программного обеспечения много разновидностей, потому дать полноценное определение данному понятию крайне сложно. Недобросовестные Agile-мастера зачастую этим пользуются. Ведь можно продать собственный продукт или обучить клиента, как быть «более agile (гибким)», заработав при этом.
