Всем привет! Меня зовут Иван Чечиков, я QA lead в МТС Digital, работаю над проектом стримингового сервиса WASD.TV. В этой статье я поделюсь опытом о том, как мы внедряли систему управления тестированием (TMS) Allure TestOps в наш проект и что из этого получилось. А еще отмечу подводные камни, с которыми столкнулись и обозначу пути их обхода. Статья может быть полезна тем, кто задумываются о переходе на данную TMS с других готовых решений, таких так Zephyr, TestRail, Test IT.

Подробности – под катом.

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

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

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

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

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

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

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

Тенденцией современности является изучение всё большего количества инструментов для автоматизации, но мышление QA важнее.

Данное руководство позволит оценить требующийся уровень знаний для инженеров по автоматизации и инженер по разработке ПО в тестировании (SDET). Статья содержит конкретные критерии, которые должны стать ориентиром при необходимости перехода на новый уровень.

Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.

Если бы мне задали такой вопрос, то я не смог бы на него правильно ответить. Ведь начинал я с ручного тестирования, а сейчас мы департаментом раскатываем на весь банк гигантский «дашборд», который привязан буквально ко всем данным компании, и позволяет оценить качество работы любой команды. Меня зовут Иван Боклач, я руководитель направления развития экспертизы QA в Центре Координации и Повышении эффективности разработки в Альфа-Банк. Я занимаюсь развитием новых технологий, метриками, стандартизацией и автоматизацией процессов.

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

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

Поговорим о том, что вас ждёт, когда вы станете руководителем.

За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании? 

Привет, Хабр! Меня зовут Ольга Кузнецова, я Senior QA инженер, более 7-ми лет работаю в ИТ-сфере в различных должностях и сегодня хочу поговорить о минимальных необходимых hard skills для тестирования бэкенда. 

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

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

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

Макс Осадчий рассказывает, как за два с половиной года вырос из QA-инженера в руководителя отдела тестирования red_mad_robot, расширил его с четырёх до двадцати человек, и делится уроками, которые усвоил за это время. Будет полезно тем, кто управляет командами или планирует это  делать. 

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

Привет! Меня зовут Миша, я работаю в Ozon Tech — руковожу направлением базовых сервисов в платформе. Ozon сегодня — это порядка 4000 разработчиков и более 3500 сервисов. Разработка постоянно развивается, количество сервисов увеличивается, и одна из сложных задач — это найти удобный для всех способ управлять тем, что происходит под капотом. 

Для этого мы сделали платформу: это внутренние стандарты, сервисы, процессы, инфраструктура для разработки. Можно сказать, что это такой «сервис для продуктовых разработчиков», который предоставляет удобные инструменты во все команды, обеспечивает единообразие подходов в разных командах, помогает внедрять изменения и новые технологии. Для нас платформа теперь — основа для разработки, на ней строятся все информационные системы, и сложно представить Ozon без неё.

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

Как быть тестировщику, если на проекте нет аналитика и спецификации? Маша Кузнецова, младший QA-инженер red_mad_robot, рассказывает о трёх возможных вариантах действия — осторожном, умеренно рискованном и максимально упоротом. Будет особенно полезно QA начального и среднего уровня — чтобы не растеряться, попав в похожую ситуацию.

Привет, я Виктор. Двенадцать лет назад я пришел в веб-студию в Самаре. Так начался мой путь в разработке. У нас не было гита, CI/CD, тестовых стендов и много чего еще. Я видел, как это мешало развитию команды и бизнеса. Приходилось на ощупь собирать грабли, открывать для себя хорошие практики и внедрять их. С тех пор я поработал старшим разработчиком в российском финансовом холдинге и немецком b2b-стартапе. Был тимлидом в фудтех-проекте, СTO в образовательных стартапах для российского и латиноамериканского рынка — и почти везде поначалу натыкался на похожие проблемы. Недавно переехал в Израиль, стал консультировать стартап. И что бы вы думали…

Привет, Хабр! Меня зовут Марина Петрова, я QA Lead в Cloud. В нашей QA-команде уже более 35 человек, а количество тестируемых продуктов превышает десяток. Мы пишем автоматические тесты для повышения качества продуктов и сокращения времени ручного тестирования. Для эффективной организации этого процесса требуются числовые индикаторы — метрики. Нам хотелось иметь инструмент, в котором аккумулируются данные о метриках в простом и понятном всем виде. Тогда мы предложили инициативу по созданию приложения для автоматического сбора и визуализации метрик покрытия автоматическими тестами.

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