Тестирование IT-систем *

Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в 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.

Всем привет.

Сегодня я хотел бы поговорить немного про тестирование в 1С.

Так уж сложилось, что мне посчастливилось довольно основательно погрузиться в эту тему и я хотел бы немного поделиться с вами своим опытом и вообще своими мыслями на тему тестирования в программах 1С:Предприятие.

Playwright рекомендует использовать пакет @playwright/test и загружать браузеры с помощью команды npx playwright. Если вы следуете этой рекомендации, для вас ничего не изменилось. Однако вплоть до версии 1.38 при установке пакета playwright вместо @playwright/test браузеры загружались автоматически. Это уже не так, и рекомендуется явно загружать браузеры с помощью команды установки npx playwright.

Привет! Меня зовут Станислав Беленов, я работаю старшим специалистом по тестированию в AWG. 

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

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

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

Одним из таких ключевых ожиданий со стороны работодателей является знание JSON, REST и типов запросов HTTP. В этой статье мы рассмотрим, почему это важно и какие преимущества это приносит как для специалистов, так и для компаний.

Привет, меня зовут Дима, я руководитель группы разработки инструментов тестирования. Миссия нашей команды предоставить инструменты которые позволяют тестировщикам измерить качество своего продукта и улучшить его. Мы хотим, чтобы тестировщики релизили быстро и без багов.

У нас есть интересные задачи и классные решения для них, которыми мы хотим поделиться.Приглашаю вас на открытый Ozon Tech Community QA Meetup, в Москве, 21 сентября в 19:00

На митапе подробно обсудим, как устроено тестирование в Ozon, поговорим про тестовое покрытие и узнаем, как работает QA в блоке по продукту и технологиям товарных операций, а именно в разработке склада.

О том, как ДИТ отечественную ос разрабатывал и к чему это привело

3 февраля в CNews появилась статья о начале внедрения в российские школы новый OC «М ОС», собранной на базе ОС «Альт». Я считаю, что эта система сырая, недоделанная, тот же "Астра" линкс лучше, чем это.

В итоге, проект забросили и моська появилась только в некоторых школах Москвы, это о многом говорит.

Привет! Меня зовут Оля, я работаю в сфере обеспечения качества ПО уже более 15 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха и агротеха. Пробовала себя и в ручном, и в  автоматизированном тестировании. В итоге ушла с головой в менеджмент. 

Больше всего мне нравится работать над процессами: выстраивать с нуля, встраивать практики обеспечения качества в существующие процессы, калибровать их в зависимости от результатов и прочее.

Сейчас я курирую QA в нескольких командах в Спортмастер Лаб, и в том числе помогаю им выстраивать те самые хорошие процессы.

На одной из прошлых SQA days я сделала доклад на тему анализа дефектов в командах, и решила написать статью по его мотивам.

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

Один из моих коллег-автоматизаторов упомянул, что к нему обращаются разработчики с вопросом: "А как написать unit-тест?". Не конкретный тест, а "в принципе". Это послужило для меня поводом подготовить эту статью, и адресована она молодым программистам. Они смогут ознакомиться с рекомендациями, которым стоит следовать при разработке unit-тестов. Но также может быть любопытна и QA-инженерам - ведь полезно получить представление об аспектах тестирования, выполняемого разработчиками.

Привет, Хабр!

Вместе с нижегородским сообществом PythoNN и инженерами компании-разработчика вычислительной техники YADRO мы обсудим правила, которые помогут сделать тесты понятнее, поговорим, как поддерживать одновременно автотесты в коммерческой и опенсорсной версиях ПО, и как использовать pytest plugins. 

На митапе вас ждет общение с опытными спикерами из разных городов и возможность встретиться с коллегами в центре Нижнего Новгорода, в КУПНО на Почаинской. 

Как всегда, для для онлайн-зрителей мы проведем трансляцию, где вы сможете задать вопросы спикерам!

Внутри поста — подробные описания докладов, ссылки на регистрацию и трансляцию.

Привет! В этом посте мы хотим поздравить всех причастных с Днём тестировщика, а также рассказать о том, как мы в МКБ построили тестирование. 

Про наши процессы, путь новичка, технологии, планы и про то, почему скрам-команду на самом деле можно собрать не из 8-10, а из 20-40 человек — под катом.

В каскадной модели разработки ПО тестирование стоит на последнем месте. Бизнес-аналитики и продакт менеджеры часто не понимают, зачем привлекать команду тестирования на ранних стадиях, — продукт ещё даже не готов, стало быть и тестировать нечего. Однако если какой-то из этапов занимает больше времени, чем планировалось изначально, все сроки сдвигаются «вправо» — и расплачиваются за это обычно именно тестировщики. Если вам знакома ситуация, когда за два дня до релиза продакт менеджер в панике просит что-нибудь протестировать, вам следует попробовать методологию shift-left.

Многие, кто приходил в любую новую сферу, задавались вопросами: «какими инструментами необходимо владеть, чтобы…», «а точно ли это весь перечень?», «а какие навыки необходимы, чтобы пройти собеседование?». Таких вопросов больше у новичков, которые уже начали обучение или только в поисках обучения, пытаются понять минимум необходимый для старта.

Давайте разберёмся с вопросами по ручному и автоматизированному тестированию, которые задают в том числе и студенты курса «Инженер по тестированию».
В статье мы пройдём по нужным навыкам, инструментам. Дадим полезные ссылки для углубления в темы и составим карту компетенций.

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

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