Внутренние платформы разработки (Internal Development Platform, IDP), как один из артефактовпримеров реализации платформенного подхода (Platform Engineering) становятся важной точкой роста для многих компаний, занимающихся разработкой: помогают унифицировать стек, снизить не целевую нагрузку на команды, увеличить ускорить time-to-market. Поэтому многие компании начинают двигаться в сторону создания развертывания своих IDP. 

Мы продолжаем серию статей о Platform Engineering и Internal Development Platform (IDP). В первом и втором материалах цикла мы уже рассмотрели базовую теорию, познакомились с типовой архитектурой IDP и вариантами реализации. А в этой статье остановимся на обзоре Dev Platform, разрабатываемой командой VK Cloud.

Колесо крутится, но хомячок подписки помер. Оно просто крутится.

В начале я хотел бы сказать, что описанные в статье практики очень плохи и неправильны (с тех пор мы добавили надёжные юнит-тесты и интеграционные тесты, а также систему алертов/логирования), что их следует избегать и в первую очередь это человеческие ошибки, которые задним умом кажутся очевидными.

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

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

Проснувшись утром, мы увидели больше сорока уведомлений Gmail с жалобами пользователей. Похоже было, что за ночь поломалось всё. Никто из пользователей не мог подписаться. И мы понятия не имели, почему.

Возможно, вы скажете, что в команде нет место слову "я", тем не менее у каждой серьезной команды есть лидер - он же тимлид. Тимлиды отвечают за все, начиная от повседневной работы и заканчивая оказанием своевременной поддержки команды для достижения поставленных целей. 

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

Привет, Хабр! Меня зовут Евгений Токарев, я руководитель группы автоматизированного тестирования в Innostage. Хочу поделиться нашим опытом выбора новой TMS и миграции достаточно большого количества тест-кейсов практически одной кнопкой.

Поехали!

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

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

В последние полгода появилась четкая тенденция: крупные корпорации загоняют сотрудников обратно в офис. Они обязуют 60% рабочего времени проводить в офисе, что примерно равно трем дням в неделю.

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

Сам работаю программистом в Амазоне уже больше двух лет. Начинал в команде в Ванкувере, Канада. Мне не понравилось и я переехал в Испанию, поменяв команду.

Хотим поделиться опытом в области развития QA-инженеров и получения продуктивной обратной связи. В этой статье разберемся, как оценить уровень навыков QA-специалиста. 

Приветствую вас, друзья! Меня зовут Иван Сидоренко и последние несколько лет я занимаюсь автоматизацией тестирования. Меня, как и многих моих коллег, заинтересовала возможность использования нейросетей в своих рабочих задачах. В последнее время вышло множество материалов, посвященных использованию нейросетей, и я хотел бы поделиться своим опытом работы с ними. В частности, я хотел бы рассказать о своем опыте работы с Chat GPT — инструментом, который я выбрал для своих экспериментов.

Всем привет! В статье расскажем про внутреннюю программу обучения для QA. В наших продуктовых командах все QA-инженеры пишут автотесты, для этого мы используем связку Java+Selenium. У всех разный уровень владения инструментами и опыт программирования. Чтобы выровнять уровень владения Java в командах и помочь новым сотрудникам быстрее влиться в нашу среду автотестов, в 2022 году мы решили сделать внутреннюю программу обучения, определив минимально необходимый уровень владения технологическим стеком. В статье поговорим о том, как мы создавали нашу программу, расскажем, из чего она состоит и разберем нюансы. 

Сейчас, наверно, из каждого утюга звучат призывы про «войти в IT». Среди этих призывов часто звучит: «Стань тестировщиком, это самый простой способ сделать карьеру в IT». Я с этим не согласен, но это лишь мое сугубо личное мнение, основанное на личном опыте. На опыте, который по факту занимает… страшно сказать… 10 лет. Более 10 лет жизни и карьеры я посвятил миру тестирования. И я бы хотел поделиться некоторыми вещами.

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

Независимо от того, какую платформу для автоматизации тестирования вы используете, Cypress, Playwright, Selenium or WebDriver.IO, важным фактором является время выполнения тестов. 

В рамках подхода ”Shift left“ тестированию отводится большая роль в получении более раннего фидбэка. Если более классический подход предусматривает достаточно длительные периоды тестирования, то при быстрых feedback loops для тестирования остается не так и много времени.

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

Вопросы профессионального развития — штука сложная. Иногда кажется, что ты немного подзастрял на своей должности (в своей сфере, своей компании — нужное подчеркнуть), и хочется сделать какой-то шаг вперед. Но куда именно и как — дилемма.

В этом посте мы при помощи наших коллег, Антона Масленникова и Антона Горбунова, попробуем наметить возможные векторы развития для QA-специалиста. Под катом — путь тестировщика, вертикальный и горизонтальный рост, переходы из тестирования в разработку или менеджмент и многое другое.

В январе пять международных QA-менторов с суммарным опытом 100+ лет опубликовали первую часть бесплатного интерактивного QA-учебника на английском языке, состоящего из 500+ страниц, 42 модулей, 42+ наборов тестов с 150+ вопросами. Про этот релиз 0.0.5 мы писали в Хабр-статье "Зачем появился бесплатный интерактивный «100-years QA-textbook» на 500+ страниц для обучающихся тестированию".

С тех пор вышел полный англоязычный релиз 0.0.9 всего учебника и выяснилось, что в результате его объем - 700 страниц (без учета изображений и тестов).

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

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

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

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

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

Высокая уверенность — выполняется только самое необходимое количество тестов, гарантирующих, что программное обеспечение может быть принято. (Примечание: это не относится к критически важным программным системам.)

Низкая уверенность — на основе предыдущего опыта тестировщики могут проводить дополнительные проверки, даже если нынешнее качество кода хорошее.

Я считаю, что уровень уверенности очень влияет на скорость, с которой программное обеспечение может быть разработано. Часто можно услышать, что «QA — это узкое место процесса разработки», но это потенциально связано с исторически низким качеством кода, заставляющим тестировщиков перетестировать, даже когда проверяется код хорошего качества. Чтобы проиллюстрировать этот момент, я привожу ниже подход, который я придумал для тестирования и проверки исправлений ошибок.

В этой статье, хочу поделиться интересным опытом работы с ChatGPT, в рамках которого был написан телеграм-бот на языке Python, использующий API OpenAI для получения ответов на запросы.

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

Я потратил следующий час на чтение документации по API OpenAI, но моя лень оказалась более находчивой, и я решил дать ChatGPT задание написать бота самостоятельно.

Что из этого вышло?

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

TeamCity — пожалуй, один из самых популярных CI/CD-серверов, который используют разработчики по всему миру. В этой статье я расскажу про базовые концепции, на которых он построен, и на примерах покажу, как можно настроить CI/CD в вашей команде.

Привет! Меня зовут Сергей, я в тестировании уже 11 лет и сейчас развиваю качество в компании QIWI. В этом посте я хочу рассказать вам, как сейчас выглядят наши продуктовые команды, куда подевалась роль тестировщика и поделиться некоторыми выводами.

Проблематика прошлого

Когда‑то у QIWI была довольно популярная структура. У нас были отделы разработки, аналитики, тестирования и прочее. Ребята из этих отделов объединялись в проектные команды и занимались проектом.

При этом одной из целей нашей компании — «Поставлять всё возрастающее количество качественных инкрементов, способствующих развитию приоритетных продуктов, не забывая при этом о людях в командах«.

И в рамках этой цели у нас в фокусе всегда было две вещи: