В этой заметке я поделюсь опытом автоматизации тестирования специфичных сквозных (E2E) сценариев, с которыми мне пришлось столкнуться.
Для успешного решения этой задачи, я нарушил один из важных принципов тестирования - делай тесты независимыми. Далее я покажу, почему я так поступил, и что из этого вышло. Быть может, этот опыт будет полезен моим коллегам.
Я новичок в работе с базами данных и для их изучения (а заодно для изучения Питона) начал небольшой пет-проект. В процессе оказалось, что в моей многопользовательской системе запросы к БД всегда касаются только одного пользователя. «Отлично!» подумал я, «раздам каждому пользователю по табличке и сэкономлю ресурсы сервера на индексации!». Конечно сначала я почитал литературу и подобных решений в ней не нашел. Потом сходил на один из популярных ресурсов и там мне объяснили, что так делать нельзя. Но почему – никто объяснить не смог (или возможно не захотел). Поэтому я решил сделать небольшой тест на самых популярных БД – проверить что будет на самом деле.
Вокруг профессии тестировщика до сих пор много спекуляций. Одни, желая продать свои услуги, говорят, что это направление — идеальное для старта своего пути в IT, другие — что профессия тестировщика крайне сложна, незаурядна и вообще сюда не стоит идти, если у вас нет технического бэкграунда.
Почему об этом пишу я? Меня зовут Никита, и у меня есть опыт работы в «Мегафоне», Rambler&Co и Okko. Я имею представление о том, как устроены процессы внутри крупных компаний — как в маленьких, так и в больших командах. Помимо прочего, работаю наставником на курсе «Инженер по тестированию» и помогаю студентам разобраться в том, как это ваше тестирование устроено.
Эта статья призвана показать, какими же задачами занимается тестировщик, какие у него обязанности, и почему искать баги — это далеко не главная его задача. Будет полезно тем, кто рассматривает себя в роли QA. Или, быть может, вы разработчик, для которого работа тестировщика покрыта завесой тайны? В общем, этот лонгрид для тех, кто вообще не понимает, чем мы занимаемся, но ему очень интересно.
В марте мы с ИТ-лидером системы Alfa ID и её архитекторами генерировали идеи по повышению стабильности и устойчивости системы, потому что в течение года планировался кратный рост нагрузки. Одной из мыслей, которая потом успешно воплотилась в реальность, была «А давай хаос инжиниринг попробуем? А то мало у нас проблем на проде как-то пока»
Тестирование является важным элементом процесса разработки программного обеспечения. При этом работа с тестами может занимать достаточно большое количество времени в сравнении с самой разработкой, в связи с этим возникает необходимость оптимизировать этот процесс. В этой статье рассказывается про плагин Sprinter для IntelliJ IDEA, который может помочь значительно сократить время на локальный запуск тестов.
Команда EFSOL Oblako продолжает серию тестов производительности 1С. Подобные тесты мы проводим уже несколько лет и на этот раз решили сравнить актуальные СУБД для работы с 1С:Предприятие 8.3, включая продукт российского разработчика - Tantor СУБД.
В данном исследовании для проведения нагрузочных тестов в связке с 1С использовались не только разные СУБД, но и разные операционные системы, подробнее о тестовом стенде ниже.
На одном из моих уроков я бросил вызов студентам: «Сделайте диаграмму тестирования». Одни начали рисовать сложные изображения, другие – простые. Одни буквальные, другие метафорические. Но многие испытывали трудности, пытаясь сосредоточиться на самом процессе тестирования. Если вы действительно хотите стать мастером в этой области, вам нужно научиться заглядывать в себя, вызывать образы и слова, а затем создавать практические и концептуальные артефакты из них.
Все мы привыкли к общепринятым инструментам для тестирования. Думаю, список есть у каждого и он постоянно пополняется. Лично мой: Postman, IntelliJ IDEA и DataGrip от JetBrains, ShareX для скриншотов и его величество DevTools.
В этой статье я хотел бы отдать дань самоделкам нашего ремесла. Мелкие скрипты и утилиты или целые приложения, написанные для того, чтобы помочь в нелёгком деле создания продукта. На первый взгляд незначительные штуки, которые делают процесс работы таким удобным.
Мир информационных технологий переживает явные изменения, и вопрос о будущем тестирования становится еще более щепетильным. Автоматизация и искусственный интеллект меняют ландшафт тестирования, поэтому следует разобраться, кто и что будет тестировать в будущем.
Хотите узнать, как тестируют продукты в ЮMoney? Тогда ждём вас на митапе для QA-специалистов уже в этот четверг, в Санкт-Петербурге и онлайн!
От коллег-тестировщиков я не раз слышал: «В ручном тестировании упёрся в потолок, хочется перейти в автоматизацию, но боюсь, что не потяну» или «…не знаю, с чего начать». Меня зовут Михаил, в тестировании 7 лет, из них около 4 занимаюсь автоматизацией. В последние пару лет мануальщики нужны всё реже, некоторые компании их уже не нанимают. Бизнесу интересны fullstack-специалисты, умеющие и вручную тестировать, и автоматизировать. Мой опыт подсказывает, что перейти из ручников в автотестеры по силам каждому. Так что я протёр клавиатуру и написал для вас эти мемуары. Заходите под кат, возможно, статья будет волшебным пенделем стимулом для тех, кто ещё сомневается и тянет с переходом.
Ещё на этапе собеседования в текущую команду передо мной поставили вопрос:
Применима ли автоматизация тестирования при проверке функционала чат‑ботов?
Я ответил "Да по-любому", и пошел изучать вопрос.
Не так давно (13 Сентября 2023) на Хабре опубликовали статью "Подборка выдающихся статей по тестированию". В приведенном списке есть и статья "Фетиш юнит-тестов" Мартина Сустрика.
Я считаю эту статью вредной, и постараюсь показать – чем именно. Кто-то из читателей согласен с утверждениями Мартина. Возможно, кто-то из них не смотрел с позиции QA на эти утверждения. Именно для них я изложил свою точку зрения.
Говорят, молчание — золото, но чтобы стать хорошим тестировщиком, нужно уметь договариваться (с разработчиками, дизайнерами, продукт-менеджерами), убеждать, лавировать между оппонентами и примирять конфликтующие стороны. Словно я описываю посредника в переговорах, но сегодня не о нем речь.
Из каждого утюга сегодня звучит призыв двигаться в сторону IT. Информационные технологии — это уже не только про математику, но и про дизайн, менеджмент, аналитику и тестирование. Причём о тестировании говорят как о чём-то очень лёгком для начала карьеры. Мол, стать тестировщиком может каждый. Но стать — это одно, а стать профессионалом — совсем другое.
Эту статью я хочу посвятить непростой работе QA-инженера, которую так легко обесценивает реклама курсов по «входу в IT». При этом все хотят работать только с профессионалами, но хорошего тестировщика днём с огнём не найдёшь. Потому что тестировщик — это командный игрок, который создаёт синергию для выпуска хорошего продукта. В слаженной команде QA-инженер становится T-shaped специалистом: умеет погружаться в код, может дать дизайнеру идеи по UX и т. д. То есть социальные навыки у QA должны быть развиты не хуже технических.
QA-инженер — это не волк-одиночка, который только ищет баги. Задача тестирования — проверка работы продукта в соответствии с требованиями заказчика. Есть даже поговорка, что разработчики радуются, когда работает, а тестировщики радуются, когда не работает. Потому что тестировщики проверяют работу программы согласно требованиям к ПО и удостоверяются, что нет багов. Но поиск багов — не цель тестировщика, а следствие его кропотливой работы.
Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.
Всем привет! Решили рассказать вам, уважаемые читатели Хабра, историю процесса внедрения E2E-автотестов в бизнес-процессы Московской Биржи.
Для начала вкратце разберемся, что такое E2E-автотест. Это вид тестов, который проверяет бизнес функционал от момента его начала до завершения.
Похожие тесты уже, безусловно, существовали в нашей компании, но они, как правило, покрывали функционал, который не выходил за пределы одного департамента (подразделения). У нас же была задача покрыть автотестами функционал, проходящий через несколько департаментов. Теперь поговорим, откуда взялась такая потребность.
Хабр, привет! Это Just AI, и мы создали JustGPT – третью большую языковую модель, сопоставимую по качеству ответов с известными LLM для русского языка (GigaChat, YandexGPT). Наша история – про работу над моделью, ее обучение и тестирование по своей методике. Но в конечном итоге она о том, как получить свою LLM на русском языке без космических мощностей и огромных команд.
Привет, Хабр! Меня зовут Денис Мурунов, я руководитель практики построения ИТ-инфраструктуры К2Тех. Cегодня хотел бы поговорить о базовом ПО для инфраструктуры каждой компании — службе каталогов. Мы видим, что все больше компаний сталкиваются с трудностями при закупке лицензий и продлении поддержки на продукты Microsoft. В такой ситуации задача импортозамещения распространенной MS Active Directory стоит сегодня перед многими организациями.
Конечно, на рынке уже есть альтернативы российского производства, которые мы с командой К2Тех активно внедряем заказчикам — это ALD Pro и Альт Домен. Но найти полезные материалы об этих продуктах вам не составит труда, поэтому сегодня я хочу рассказать вам о новых решениях на рынке — РЕД АДМ Промышленная редакция и Атом.Домен.
Автор: Роман Горбунов, руководитель проектов в сфере обеспечения качества ИТ‑компании «Точка качества».
При взаимодействии с директорами, владельцами бизнеса и некоторыми руководителями команд разработки специалисты компании по тестированию программного обеспечения «Точка качества» периодически сталкиваются с мнением, что тестировать ИТ‑решение — это легко и быстро. Нужно просто нажать несколько кнопок и готово, запустить пару программ, и можно делать релиз.
В связи с этим некоторые думают, что нет необходимости создавать или привлекать отдельную команду инженеров по тестированию, так как с задачей справятся разработчики, менеджеры проекта, аналитики, специалисты техподдержки или представители бизнеса.
Чтобы выпустить на рынок востребованное ПО, которое будет работать быстро и корректно, будет соответствовать критериям безопасности и дизайна, необходимо провести тестирование. Тестирование ПО — это многогранный и сложный процесс, который делится на виды, этапы, методы и инструменты и требует особых компетенций, которыми не всегда обладают другие ИТ‑специалисты.
В текущих проектах я применяю подход Behavior Driven Development (BDD) для написания end‑to‑end тестов. Хотя раньше я скептически относился к Given‑When‑Then синтаксису, теперь часто его использую. Главная причина — я больше не пишу BDD‑сценарии вручную, а генерирую их с помощью ChatGPT.
В статье расскажу, как вы можете генерировать AI‑тесты в своем проекте и запускать их в реальном браузере с помощью Playwright.
