Курс «Инженер по тестированию программного обеспечения» (сокращенно ПОТ) переходит в индивидуальный формат!

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

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

Но и поставить 1 лекцию в неделю для всех мы не можем, ведь тогда обучение получится слишком растянутым по времени — шутка ли, 8 месяцев! Цена, опять же, возрастет… А дать шанс сдать раньше надо!

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

Поэтому теперь ПОТ будет запускаться в любой день недели — начинайте обучение, когда захотите. Оплатили месяц обучения? Приступайте к работе. Через месяц можно взять неделю-две на отдых и доработку хвостов, а потом снова оплатили месяц, и снова есть проверки ДЗ и ответы на вопросы!

Темы открываются автоматически — сдали одну? Открылась новая. А вот в каком темпе вы будете сдавать, решайте сами. Исходно открыто 3 темы, чтобы не простаивать в ожидании фидбека от тренера.

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

Итого!

Теперь вы можете:

• стартовать в любой день;
• общаться с тренером в личке (в групповом чате иногда смущаются вопросы задавать);
• проходить темы в своем темпе;
• устраивать себе отдых от курса хоть каждый месяц — просто повремените с оплатой, выдохните, и возвращайтесь с новыми силами!

А если я уже проходил ШНАТ, могу я получить диплом о проф. переподготовке?

Когда мы только запустили ПОТ, выпускники ШНАТ спрашивали, есть ли возможность им пройти курс со скидкой, ведь часть тем они уже изучили. Так вот, теперь такая возможность есть!

Покажите сертификат пройденного ШНАТ, и вас подключат к отдельной индивидуальной группе ПОТ, где уже открыты все темы из ШНАТ. Их всё равно нужно будет пересдать, так как курс меняется — возможно, вы проходили курс, когда там были другие задания.

Если же задание то же самое, то прекрасно! Значит, сможете сдать свою старую работу, а тренер посмотрит на неё свежим взглядом и посоветует, как можно ещё немного улучшить!

Но в любом случае вам сразу будут доступны 16 тем - темы из ШНАТ + 3 новые (клиент-серверная архитектура, логи на клиенте, логи на сервере). И их все можно сразу сдавать. Так что есть шанс пройти курс за месяц, максимум два.

Приходите! Подробная программа и условия участия по ссылке: https://www.software-testing.ru/edu/3-online/331-qa-engineer

Реклама: ООО "ТЕСТБЕЙЗ", ИНН 9727006330, erid 2SDnjdG912W

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

Привет, меня зовут Андрей и я автоматизатор (остальные в кругу хлопают в знак сочувствия) в hh.ru. В статье расскажу, как мы ввели карантин автотестов, повысив стабильность релизов и скорость доставки.

Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Вы — начинающий тестировщик? Работать над приложением в команде из пяти и более разработчиков может показаться надёжным способом создать продукт без багов. Но правда в том, что количество разработчиков в проекте никоим образом не влияет на итоговое число ошибок.
Как бы ни был опытен разработчик — баги всё равно случаются. Не существует такого понятия, как «идеальный продукт».

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

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

Вот несколько таких техник, которые, по моему опыту, приносят хорошие результаты.

Автор: Никита Филонов
Оригинальная публикация

Вступление

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

Правильный профиль нагрузки — это не просто цифра в настройках. Это ответ сразу на три вопроса:

• Что мы нагружаем (какие сервисы или сценарии),

• Как мы нагружаем (параметры, последовательность, интенсивность),

• Почему именно так (данные, прогнозы или требования).

Цель этой статьи — дать практические рекомендации, которые помогут правильно выбрать профиль нагрузки и сделать тестирование осмысленным и полезным, а не просто «запуском ради отчётности».

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

Автор: Эди Стоукс, Рабай’а Браун (Ady Stokes, Rabi'a Brown)
Оригинал статьи
Перевод: Ольга Алифанова

Синие экраны — это только начало

Пока большая часть мира восстанавливалась от «чёрного лебедя» — масштабного сбоя, связанного с CrowdStrike и Azure, — команда Ministry of Testing решила поделиться несколькими лёгкими и забавными историями о том, как любимые устройства (и маломощные рабочие ноутбуки) умирали или просто притворялись мёртвыми.

Примечание: некоторые из вас, возможно, никогда не видели печально известный "синий экран смерти" Windows, который мы здесь будем иногда называть BSoD (Blue Screen of Death). Читайте дальше, чтобы узнать подробности.

Задача любого тестировщика — проверять продукт на соответствие установленным требованиям и своевременно отлавливать любые баги и ошибки. В идеальных условиях или небольших проектах эта схема работает безотказно. Но в ситуациях, когда над продуктом работает несколько команд разработки, в релизы попадает по 30–70 задач, а обновления выкатываются каждую неделю, фокуса тестировщиков может просто не хватить. В таких условиях не обойтись без Quality Gates.

Меня зовут Юлия Садовникова. Я старший специалист по тестированию в команде Core Android компании ОК. В этой статье я расскажу о Quality Gates в ОК и о том, как QA может не просто тестировать, а реально влиять на проект и процессы.

Автор: Хосе Каррера (Jose Carrera)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое тестирование, управляемое через страх?

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

Такое поведение может быть вызвано разными причинами: давлением со стороны бизнеса, нехваткой знаний в предметной области, жёсткими сроками и т.д. Ещё один важный аспект — это восприятие качества внутри команды и бизнеса:

• Разделяется ли ответственность за качество между всеми участниками команды?
• Где находятся контрольные точки качества (quality gates)?

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