Управление релизами охватывает все этапы продукта — от разработки и тестирования до продакшена. Это самая ответственная роль, которую может взять на себя IT-специалист. Вместе с коллегами из направления QA SimbirSoft рассказали, на что стоит обратить внимание IT-специалисту, стартующему в роли релиз-менеджера или решившему проанализировать процесс релизов на проекте.
Компетенции релиз-менеджера можно разделить на две части с точки зрения инструментов: техническую и работу с документами.
Зачастую перед QA-инженером стоит задача покрытия функциональности автотестами, при этом без избыточных проверок, по правильной пирамиде. Но, прежде чем начать покрывать бизнес-логику, стоит понять, а что, вообще, можно покрыть на unit-тестах.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
С большим волнением представляю вам довольно новую для вас и нашей отрасли идею: Открытое тестирование: что, если мы откроем наши тесты так же, как наш исходный код? Я говорю не просто о тест-фреймворках с открытым исходным кодом. Я говорю об открытии самих тестов. Что, если делиться тест-кейсами и процедурами автотестов станет нормой? Что, если для компаний будет нормальным открыто публиковать результаты тестов? И каков уровень открытости тестирования, к которому наша отрасль должна стремиться?
Всем привет, меня зовут Софья Бреева, я Team Lead QA. Моя статья для тех, кто только входит в эту профессию — поговорим о необходимых инструментах для начинающего тестировщика и литературе, которая поможет вам разобраться со многими практическими моментами. Если вы из тех, кто задается вопросом: «Ага, а есть книга, в которой я могу почитать об этом?» — этот материал будет вам полезен.
Наставничество — неотъемлемая часть моей рабочей жизни. Каждый день я взаимодействую со своими коллегами и часто им рекомендую что-то по профессии. Особенно это интересно джунам из QA, которые впитывают новую информацию как губки. Они только окунулись в сферу IT и чувствуют себя как ежики в тумане, при этом жаждут узнать как можно больше и поскорее. Поэтому цель моей статьи — помочь им рассеять этот туман, чтобы жизнь стала проще, и развитие пошло быстрее.
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Ранее я писал о концепции мягких ассертов. Процитирую себя: "Мягкий ассерт – это ассерт, результат которого записывается, но не останавливает выполнение тестового сценария на этой точке. Результаты всех мягких ассертов оцениваются в указанный автором тест-сценария момент, как правило, в конце; если какое-либо условие мягкого ассерта валидируется как ложь, мягкий ассерт сообщает о провале в результате, и тест-сценарий, как правило, отмечается как проваленный". Если вы пропустили предыдущую статью, прочитайте про концепцию мягких ассертов.
При разработке крупного и длительного проекта зачастую используют Jira, так как с ее помощью легко формировать списки задач, отслеживать прогресс и решать разные проблемы, которые могут возникнуть.
Многие скажут, что она сейчас не актуальна в связи с уходом Atlassian из России. На это мы можем возразить, что Jira является одной из самых популярных систем. Специалисты привыкли работать с ней, и многие компании продолжают ей пользоваться. Более того, она может помочь реализовать полный цикл обеспечения качества и часто используется в саппорте, поддержке системы в проде. Бизнес-требования одного из наших зарубежных клиентов заставили нас сильно углубиться в устройство Jira.
Теперь мы знаем, как можно обратиться к БД Jira без использования плагинов и зачем это может понадобиться. Готовы поделиться этой информацией и с вами. Также расскажем, как работать с данными Jira напрямую (без плагинов) и минимизировать расходы на обслуживание. И все это при соблюдении GDPR (General Data Protection Regulation - общий регламент по защите персональных данных).
В одной из своих статей (Автотесты на Android. Картина целиком) я описывал, что вообще в себя включают Автотесты под Android. Если кратко, то я выделял 4 большие области: Процесс написания автотестов, Runner, Инфраструктура и Остальное, которое включало в себя отчеты, интеграцию с CI/CD и тд. В свое время (2019-2020) когда мы делали Kaspresso, мы закрывали боль с написанием автотестов. Теперь разработчики и тестировщики могут писать красивый и понятный DSL и не думать про проблемы с флаканием, логами, скоростью и тд. По другим же областям были некоторые решения, но команды, выстраивающие весь процесс, должны были сами со всем этим разбираться и все это стыковать. Особенно больно было с Инфраструктурой, где приходится нырять в дивный мир DevOps и частично даже Highload.
Недавно мне стало интересно, а как сейчас обстоят дела у разных команд с автотестами. Для этого мы с Сергеем провели ряд интервью с более, чем 30 разными командами. Да, это далеко не вся выборка, и данное исследование точно не претендует на абсолютную истину. Но 30 больше, чем 1 или 2 или 5, и поэтому исследование точно может наводить на кое-какие мысли.
Автор: Джефф Найман (Jeff Nyman) Оригинал статьи Перевод: Ольга Алифанова
Тестировщики много спорят о том, может ли "кто угодно" тестировать. Ответ – да, если вы человек, вы автоматически тестировщик. Но не каждый будет специалистом тестирования. Я немного говорил об этом в статье, что значит быть тест-специалистом, и надо ли нам нанимать тест-специалистов. Тут я просто хочу подкрепить позицию, что живой человек – тестировщик по умолчанию, рассмотрев родословную этой концепции.
