Регрессионное тестирование (Regression testing)
На нашем проекте сейчас начинается, пожалуй, самый рутинный этап для тестировщиков - регрессионное тестирование, то есть проверка того, что раньше работало, но могло сломаться в новой версии приложения.
Что обычно делают тестировщики в первую очередь?
⁃ Актуализируют тест-кейсы, если этого не было сделано ранее (например, по изменениям, которые появились в новой версии)
⁃ В конце спринта фиксируют версии всех компонентов приложения
⁃ Анализируют результаты прохождения автотестов
⁃ Проводят смоук-тестирование
⁃ Проводят регрессионное тестирование
⁃ В случае отсутствия критичных/блокирующих багов готовят релиз-кандидат к передаче в продуктив
Все перечисленное выше - достаточно гибкая штука и зависит от конкретной компании и проекта, но подход одинаков примерно везде.
Традиционно расшифрую терминологию (объясню простым и даже примитивным языком, более верные и полные с академической точки зрения определения лежат где-то в гугле):
Спринт - период времени, в течение которого запланирован выпуск нового релиза (и, получается, должны быть закрыты задачи на разработку и тестирование)
Автотесты - автоматизированные проверки, выполняемые на тестовом стенде без участия человека (сами автотесты пишутся, разумеется, человеком)
Смоук-тестирование - проверка основных функциональностей приложения на предмет отсутствия блокирующих и критичных багов.
А вот и #тестовое_задание подоспело.
В процессе регресса веб-приложения по доставке еды тестировщиками было выявлено два бага:
1) при попытке входа в личный кабинет у пользователя перестал отображаться баланс бонусных баллов, полученных за уже выполненные заказы, воспользоваться баллами из-за этого не получается
2) ранее на странице ввода адреса доставки для полей Город и Улица при вводе символов пользователю отображался выпадающий список с подсказками, соответствующими его вводу. Теперь выпадающий список перестал отображаться.
Являются ли данные баги критичными/блокирующими для этого релиза? Оценку нужно дать каждому багу. Общаемся здесь @qa_chat
На нашем проекте сейчас начинается, пожалуй, самый рутинный этап для тестировщиков - регрессионное тестирование, то есть проверка того, что раньше работало, но могло сломаться в новой версии приложения.
Что обычно делают тестировщики в первую очередь?
⁃ Актуализируют тест-кейсы, если этого не было сделано ранее (например, по изменениям, которые появились в новой версии)
⁃ В конце спринта фиксируют версии всех компонентов приложения
⁃ Анализируют результаты прохождения автотестов
⁃ Проводят смоук-тестирование
⁃ Проводят регрессионное тестирование
⁃ В случае отсутствия критичных/блокирующих багов готовят релиз-кандидат к передаче в продуктив
Все перечисленное выше - достаточно гибкая штука и зависит от конкретной компании и проекта, но подход одинаков примерно везде.
Традиционно расшифрую терминологию (объясню простым и даже примитивным языком, более верные и полные с академической точки зрения определения лежат где-то в гугле):
Спринт - период времени, в течение которого запланирован выпуск нового релиза (и, получается, должны быть закрыты задачи на разработку и тестирование)
Автотесты - автоматизированные проверки, выполняемые на тестовом стенде без участия человека (сами автотесты пишутся, разумеется, человеком)
Смоук-тестирование - проверка основных функциональностей приложения на предмет отсутствия блокирующих и критичных багов.
А вот и #тестовое_задание подоспело.
В процессе регресса веб-приложения по доставке еды тестировщиками было выявлено два бага:
1) при попытке входа в личный кабинет у пользователя перестал отображаться баланс бонусных баллов, полученных за уже выполненные заказы, воспользоваться баллами из-за этого не получается
2) ранее на странице ввода адреса доставки для полей Город и Улица при вводе символов пользователю отображался выпадающий список с подсказками, соответствующими его вводу. Теперь выпадающий список перестал отображаться.
Являются ли данные баги критичными/блокирующими для этого релиза? Оценку нужно дать каждому багу. Общаемся здесь @qa_chat
Ребята, совсем забыл рассказать про Heisenbug Moscow - мегакрутое событие для тестеров и не только. Конференция проходила 5-6 декабря. Я поприсутствовать не смог, а вот моя хорошая подруга, Мила, там побывала и сделала несколько фоток для вас.
Что понравилось Миле?
- доклад про Appium от индуса
- доклады про Web Accessibility, про iot, про автоматизацию отдела автоматизации.
Полный список докладов смотрите здесь https://heisenbug-moscow.ru/
И не забудьте поучаствовать в следующем году - это того стоит.
Что понравилось Миле?
- доклад про Appium от индуса
- доклады про Web Accessibility, про iot, про автоматизацию отдела автоматизации.
Полный список докладов смотрите здесь https://heisenbug-moscow.ru/
И не забудьте поучаствовать в следующем году - это того стоит.
This media is not supported in your browser
VIEW IN TELEGRAM
Опытный тестировшик решает проблему накопившихся тасок
Бэклог
Картинка с тюленями постом выше - суровая реальность работы разработчика и тестировщика. Проект растёт, ресурсов не хватает, задачи копятся.
Такое скопление задач, по которым уже сформулированы требования и которые поставлены в очередь на исполнение, называются бэклогом.
Чем меньше бэклог, тем ярче твоя жизнь- тебя любят все вокруг, ты можешь заняться своим проектом, поучиться чему-нибудь или просто лечь поспать.
Картинка с тюленями постом выше - суровая реальность работы разработчика и тестировщика. Проект растёт, ресурсов не хватает, задачи копятся.
Такое скопление задач, по которым уже сформулированы требования и которые поставлены в очередь на исполнение, называются бэклогом.
Чем меньше бэклог, тем ярче твоя жизнь- тебя любят все вокруг, ты можешь заняться своим проектом, поучиться чему-нибудь или просто лечь поспать.
Резюме
Недавно помогал подруге с разбором резюме ее ученика - он хочет найти работу в тестировании, но опыта не так много. Некоторые тезисы по разбору оставлю здесь.
1. Электронную почту лучше всего указать с формальным адресом - по типу ivan.ivanov@...
2. Непрофильные образование и опыт работы (не IT) лучше всего не указывать, либо указывать максимально лаконично - эта информация скорее всего не заинтересует IT-рекрутера и будет лишней.
4. Когда совсем мало опыта, остаётся делать акцент на стажировки, тренинги, курсы - в резюме нужно указать не только название, но и приложить ссылку на сертификат.
5. Не нужно указывать курсы, которые вы прошли на пиратских ресурсах, - это очень быстро выявляется и может перекрыть доступ сразу к нескольким крупным компаниям.
5. Hard skills лучше детализировать. Умеете работать в баг-трекинговой системе - в какой именно? Умеете проводить нефункциональное тестирование - какое именно?
6. Подгонять резюме под вакансию не нужно - требования в вакансии нужно учесть при составлении резюме, но не более.
Да, кстати, в этом посте есть небольшой «баг». Нашли?
Недавно помогал подруге с разбором резюме ее ученика - он хочет найти работу в тестировании, но опыта не так много. Некоторые тезисы по разбору оставлю здесь.
1. Электронную почту лучше всего указать с формальным адресом - по типу ivan.ivanov@...
2. Непрофильные образование и опыт работы (не IT) лучше всего не указывать, либо указывать максимально лаконично - эта информация скорее всего не заинтересует IT-рекрутера и будет лишней.
4. Когда совсем мало опыта, остаётся делать акцент на стажировки, тренинги, курсы - в резюме нужно указать не только название, но и приложить ссылку на сертификат.
5. Не нужно указывать курсы, которые вы прошли на пиратских ресурсах, - это очень быстро выявляется и может перекрыть доступ сразу к нескольким крупным компаниям.
5. Hard skills лучше детализировать. Умеете работать в баг-трекинговой системе - в какой именно? Умеете проводить нефункциональное тестирование - какое именно?
6. Подгонять резюме под вакансию не нужно - требования в вакансии нужно учесть при составлении резюме, но не более.
Да, кстати, в этом посте есть небольшой «баг». Нашли?
Новый год
Знаете, какому виду тестирования отводится особая роль в предпраздничные дни? Все верно, нагрузочному (load testing).
Для проведения такого тестирования нужны более узкие специалисты и инструменты (например, Apache JMeter, HP LoadRunner и т.п.).
В пиковые дни (праздники, акции) нагрузка на серверы в несколько раз (бывает, что и в десятки и сотни раз) превышает среднюю нагрузку. Если не оптимизировать приложение и инфраструктуру, то серверы скорее всего перестанут успевать обрабатывать запросы и прилягут на какое-то время.
Для имитации нагрузки тестировщики придумывают различные нагрузочные профили, которые отличаются, в основном, по времени и по количеству потоков.
Знаете, какому виду тестирования отводится особая роль в предпраздничные дни? Все верно, нагрузочному (load testing).
Для проведения такого тестирования нужны более узкие специалисты и инструменты (например, Apache JMeter, HP LoadRunner и т.п.).
В пиковые дни (праздники, акции) нагрузка на серверы в несколько раз (бывает, что и в десятки и сотни раз) превышает среднюю нагрузку. Если не оптимизировать приложение и инфраструктуру, то серверы скорее всего перестанут успевать обрабатывать запросы и прилягут на какое-то время.
Для имитации нагрузки тестировщики придумывают различные нагрузочные профили, которые отличаются, в основном, по времени и по количеству потоков.
#Ролевыеигры
DevOps
Честно, я в восторге от наших девопсеров. Их работа часто невидима и неосязаема, но в этом и фишка - на них держится автоматизация CI/CD-процессов, мониторинг продуктивной среды, поддержка разработчиков и тестировщиков.
Если бы у нас их не было в команде - мы бы погрязли в рутине.
Внедрение автодеплоя (автоматизированной установки приложения на сервер) на моем проекте - во многом результат моей лени и большого желания автоматизировать процесс и двух девопсеров с их желанием помочь - до этого мне приходилось делать всё вручную.
Что значит деплоить вручную, спросите вы. Это значит, что один и тот же набор операций нужно будет монотонно сделать на всех нодах приложения и, разумеется, где-то забыть поменять конфиги, где-то поставить не ту сборку, где-то не прокатить скрипт. А потом полдня разгребать, почему тестовый стенд не работает. Я, конечно, утрирую, но плюс/минус такие ситуации случались.
По моим оценкам после внедрения автодеплоя влияние человеческого фактора на проекте снизилось на 80%, трудозатраты на деплой тоже снизились, процентов на 60%.
В итоге каким бы ленивым я ни был, но автодеплой вынудил прокачать некоторые скиллы - мы стали юзать git, Ansible, научились немного настраивать плейбуки и работать с YAML-форматом. Вот такие дела.
DevOps
Честно, я в восторге от наших девопсеров. Их работа часто невидима и неосязаема, но в этом и фишка - на них держится автоматизация CI/CD-процессов, мониторинг продуктивной среды, поддержка разработчиков и тестировщиков.
Если бы у нас их не было в команде - мы бы погрязли в рутине.
Внедрение автодеплоя (автоматизированной установки приложения на сервер) на моем проекте - во многом результат моей лени и большого желания автоматизировать процесс и двух девопсеров с их желанием помочь - до этого мне приходилось делать всё вручную.
Что значит деплоить вручную, спросите вы. Это значит, что один и тот же набор операций нужно будет монотонно сделать на всех нодах приложения и, разумеется, где-то забыть поменять конфиги, где-то поставить не ту сборку, где-то не прокатить скрипт. А потом полдня разгребать, почему тестовый стенд не работает. Я, конечно, утрирую, но плюс/минус такие ситуации случались.
По моим оценкам после внедрения автодеплоя влияние человеческого фактора на проекте снизилось на 80%, трудозатраты на деплой тоже снизились, процентов на 60%.
В итоге каким бы ленивым я ни был, но автодеплой вынудил прокачать некоторые скиллы - мы стали юзать git, Ansible, научились немного настраивать плейбуки и работать с YAML-форматом. Вот такие дела.
С наступившим Новым годом, ребятки! Пусть бэклог уменьшается, баги своевременно находятся, а собеседования проходятся!
Очень скоро допишу для вас пост про работу в Германии: какие условия, требования к квалификации и к знанию языка.
Подписывайтесь сами и расскажите кому-нибудь из друзей о канале - это будет лучшим подарком мне на Новый год🙃
Очень скоро допишу для вас пост про работу в Германии: какие условия, требования к квалификации и к знанию языка.
Подписывайтесь сами и расскажите кому-нибудь из друзей о канале - это будет лучшим подарком мне на Новый год🙃
Какой будет зарплата, если ты решил переехать в Германию?
В минувшие праздники я побывал в Гамбурге и Берлине и заодно выяснил, что же ждёт тестировщиков там.
Вообще, зарплата у IT-сотрудников в Германии несильно отличается от зарплат специалистов другого профиля - учителей, юристов, аудиторов, финансистов. Многие инженеры и врачи здесь будут получать даже побольше, чем айтишники.
По требованиям все достаточно уютно: из всех вакансий, которые я просмотрел, только в одном месте, к примеру, потребовалась сертификация ISTQB FL. Инструменты для тестирования - фактически те же, что и указаны в большинстве наших вакансий. Заметил, что тестировщики требуются для многих индустриальных компаний, соответственно, требуются знания на стыке технологий - из машиностроения, робототехники.
Основное препятствие - знание языка. Немецкий нужен не менее B2, чаще - C1. Английский - Intermediate, Upper-intermediate. Часто команды интернациональные и рабочий язык английский, даже если большинство сотрудников в команде - немцы.
Зарплата - пожалуй, самая больная тема из-за больших налогов. В Германии существуют налоговые классы, в зависимости от которых меняется налоговая ставка. Например, если ты приехал в Германию один, без семьи и детей - налог будет одной величины, если приехал с семьей - налог уже будет поменьше. В вакансиях поэтому часто указывается годовая(!) зарплата брутто, до вычета налога. Для примерного расчёта налога есть куча онлайн-калькуляторов, которые учитывают налоговые классы.
По моим очень усреднённым подсчетам джун-тестировщик будет получать около 2000-2500€ в месяц на руки. Автотестеры - 3000-3500€ на руки. Понятное дело, везде есть свои исключения.
В минувшие праздники я побывал в Гамбурге и Берлине и заодно выяснил, что же ждёт тестировщиков там.
Вообще, зарплата у IT-сотрудников в Германии несильно отличается от зарплат специалистов другого профиля - учителей, юристов, аудиторов, финансистов. Многие инженеры и врачи здесь будут получать даже побольше, чем айтишники.
По требованиям все достаточно уютно: из всех вакансий, которые я просмотрел, только в одном месте, к примеру, потребовалась сертификация ISTQB FL. Инструменты для тестирования - фактически те же, что и указаны в большинстве наших вакансий. Заметил, что тестировщики требуются для многих индустриальных компаний, соответственно, требуются знания на стыке технологий - из машиностроения, робототехники.
Основное препятствие - знание языка. Немецкий нужен не менее B2, чаще - C1. Английский - Intermediate, Upper-intermediate. Часто команды интернациональные и рабочий язык английский, даже если большинство сотрудников в команде - немцы.
Зарплата - пожалуй, самая больная тема из-за больших налогов. В Германии существуют налоговые классы, в зависимости от которых меняется налоговая ставка. Например, если ты приехал в Германию один, без семьи и детей - налог будет одной величины, если приехал с семьей - налог уже будет поменьше. В вакансиях поэтому часто указывается годовая(!) зарплата брутто, до вычета налога. Для примерного расчёта налога есть куча онлайн-калькуляторов, которые учитывают налоговые классы.
По моим очень усреднённым подсчетам джун-тестировщик будет получать около 2000-2500€ в месяц на руки. Автотестеры - 3000-3500€ на руки. Понятное дело, везде есть свои исключения.
Как улучшить продукт?
Неделя выдалась очень продуктивной: новый релиз, новые баги, а ещё внедрение новеньких Feature requests.
О фича реквестах как раз и поговорим. По сути, это запросы на улучшение приложения. Такие задачи не являются багами, а скорее пожеланиями на доработку продукта. Инициаторами могут быть пользователи, менеджеры, тестировщики, разработчики и т.п. - по сути, все заинтересованные лица. Но кому, как не тестировщикам, знать плюсы и минусы своего продукта? Где-то такие запросы поощряются руководством, где-то воспринимаются в штыки - ведь это дополнительная работа для всех. Задача тестировщика - постараться убедить руководителя, команду, менеджера или иное лицо, принимающее решение, что данная фича действительно необходима (потом она облегчит твою же работу).
Как я продвигаю свои фича реквесты?
1. Есть свободное время - изучаю продукт: анализирую, что было неудобно при последнем регрессе, какие операции оказались слишком рутинными, изучаю как реализовано у других, общаюсь с коллегами
2. Появилась идея - готовлю прототип и набрасываю начальные требования
3. Обсуждение. Общаюсь со своим руководителем, руководителем разработки
4. Если идея зашла и ее реализация существенно не бьет по бюджету проекта, то допиливаю требования
5. Готовлю feature request и жду релиз, в котором фича будет реализована.
Неделя выдалась очень продуктивной: новый релиз, новые баги, а ещё внедрение новеньких Feature requests.
О фича реквестах как раз и поговорим. По сути, это запросы на улучшение приложения. Такие задачи не являются багами, а скорее пожеланиями на доработку продукта. Инициаторами могут быть пользователи, менеджеры, тестировщики, разработчики и т.п. - по сути, все заинтересованные лица. Но кому, как не тестировщикам, знать плюсы и минусы своего продукта? Где-то такие запросы поощряются руководством, где-то воспринимаются в штыки - ведь это дополнительная работа для всех. Задача тестировщика - постараться убедить руководителя, команду, менеджера или иное лицо, принимающее решение, что данная фича действительно необходима (потом она облегчит твою же работу).
Как я продвигаю свои фича реквесты?
1. Есть свободное время - изучаю продукт: анализирую, что было неудобно при последнем регрессе, какие операции оказались слишком рутинными, изучаю как реализовано у других, общаюсь с коллегами
2. Появилась идея - готовлю прототип и набрасываю начальные требования
3. Обсуждение. Общаюсь со своим руководителем, руководителем разработки
4. Если идея зашла и ее реализация существенно не бьет по бюджету проекта, то допиливаю требования
5. Готовлю feature request и жду релиз, в котором фича будет реализована.
Профдеформация и перегорание
У многих тестеров есть одна не очень хорошая особенность: чем дольше они работают в тестировании, тем больше косяков и изъянов замечают вокруг, в том числе и за пределами работы. Это угнетает, удовольствие от самой работы проходит, и иной раз масла в огонь подливают отдельные разработчики (не все), которые в тестерах в первую очередь видят монстров, ломающих тестовые стенды. В общем, налицо выгорание, хроническая усталость и все такое.
Самое главное в такой ситуации - вовремя остыть и успокоиться. Теряешь контроль - бери отпуск. Это самый лучший вариант. Еще можно переключиться на другой продукт и другую команду, если есть такая возможность в компании.
У многих тестеров есть одна не очень хорошая особенность: чем дольше они работают в тестировании, тем больше косяков и изъянов замечают вокруг, в том числе и за пределами работы. Это угнетает, удовольствие от самой работы проходит, и иной раз масла в огонь подливают отдельные разработчики (не все), которые в тестерах в первую очередь видят монстров, ломающих тестовые стенды. В общем, налицо выгорание, хроническая усталость и все такое.
Самое главное в такой ситуации - вовремя остыть и успокоиться. Теряешь контроль - бери отпуск. Это самый лучший вариант. Еще можно переключиться на другой продукт и другую команду, если есть такая возможность в компании.
MosQA #2
Мейлрушечка провела вчера второй митап тестировщиков MosQA. Если коротко - всё было на уровне. Встреча прошла в атриуме их офиса - обычно там сотрудники играют в волейбол/баскетбол, но в этот раз отдали площадку нам - зарегалось больше 600 человек на мероприятие.
Читали хорошие доклады про автоматизацию тестирования, развитие soft skills, взаимодействие с разработчиками и не только. Новые подходы и внутренняя кухня тестеров в других компаниях - это всегда интересно. А тем, кому было скучно, дали ссылку на сайтик, который можно было попытаться поломать и набрать за это баллы.
Чуть позже выложу ссылки на материалы, а пока ловите немного фоток с митапа.
Мейлрушечка провела вчера второй митап тестировщиков MosQA. Если коротко - всё было на уровне. Встреча прошла в атриуме их офиса - обычно там сотрудники играют в волейбол/баскетбол, но в этот раз отдали площадку нам - зарегалось больше 600 человек на мероприятие.
Читали хорошие доклады про автоматизацию тестирования, развитие soft skills, взаимодействие с разработчиками и не только. Новые подходы и внутренняя кухня тестеров в других компаниях - это всегда интересно. А тем, кому было скучно, дали ссылку на сайтик, который можно было попытаться поломать и набрать за это баллы.
Чуть позже выложу ссылки на материалы, а пока ловите немного фоток с митапа.