#Ролевыеигры
Под этим хэштегом буду рассказывать о взаимодействии тестировщиков с другими членами IT-команды. Начну серию постов с разработчиков - все-таки именно они пишут код, делают его ревью и еще они тоже немного тестировщики - чаще всего именно они пишут Unit-тесты.
Для не очень посвященных вкратце объясню терминологию.
Ревью кода - это проверка одним из разработчиков кода своего коллеги - это позволяет оптимизировать код и улучшить его читаемость, а знания о новых фичах (особенностях) реализации продукта распространяются среди других коллег. Наличие код-ревью на проекте или в компании - это хороший тон, а для тестировщиков, собирающихся устроиться в такую компанию - отличный сигнал.
Unit-тесты - проверки кода на уровне функций, классов, процедур. Выявление ошибок самим разработчиком на самом раннем этапе обходится гораздо дешевле для компании, чем те, которые вылавливают тестировщики или, что еще хуже, обычные пользователи продукта.
И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂
Естественно, это происходит неосознанно и не специально. Более того, хороший разработчик не только тщательно покроет свой код юнит-тестами, но и напишет комментарии к коду, подготовит краткую документацию или статью для других, но и это не спасет его от наличия багов. Именно поэтому большинство задач разработчиков после ревью кода (рецензирования) переходит на следующий этап - тестирование. Здесь подключаются тестеры, которые получают новую версию приложения от разработчика, устанавливают его на тестовый стенд (сервер) и начинают делать самое интересное: пытаются его всячески сломать самыми изощренными способами.
Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.
А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.
Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷♂️. Как думаете, почему?
Под этим хэштегом буду рассказывать о взаимодействии тестировщиков с другими членами IT-команды. Начну серию постов с разработчиков - все-таки именно они пишут код, делают его ревью и еще они тоже немного тестировщики - чаще всего именно они пишут Unit-тесты.
Для не очень посвященных вкратце объясню терминологию.
Ревью кода - это проверка одним из разработчиков кода своего коллеги - это позволяет оптимизировать код и улучшить его читаемость, а знания о новых фичах (особенностях) реализации продукта распространяются среди других коллег. Наличие код-ревью на проекте или в компании - это хороший тон, а для тестировщиков, собирающихся устроиться в такую компанию - отличный сигнал.
Unit-тесты - проверки кода на уровне функций, классов, процедур. Выявление ошибок самим разработчиком на самом раннем этапе обходится гораздо дешевле для компании, чем те, которые вылавливают тестировщики или, что еще хуже, обычные пользователи продукта.
И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂
Естественно, это происходит неосознанно и не специально. Более того, хороший разработчик не только тщательно покроет свой код юнит-тестами, но и напишет комментарии к коду, подготовит краткую документацию или статью для других, но и это не спасет его от наличия багов. Именно поэтому большинство задач разработчиков после ревью кода (рецензирования) переходит на следующий этап - тестирование. Здесь подключаются тестеры, которые получают новую версию приложения от разработчика, устанавливают его на тестовый стенд (сервер) и начинают делать самое интересное: пытаются его всячески сломать самыми изощренными способами.
Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.
А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.
Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷♂️. Как думаете, почему?
Регрессионное тестирование (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, взаимодействие с разработчиками и не только. Новые подходы и внутренняя кухня тестеров в других компаниях - это всегда интересно. А тем, кому было скучно, дали ссылку на сайтик, который можно было попытаться поломать и набрать за это баллы.
Чуть позже выложу ссылки на материалы, а пока ловите немного фоток с митапа.