Мой товарищ (и он же Java-разработчик по совместительству), недавно понял, что нет (наверное) в Телеграме каналов с QA-мемчиками и, недолго думая, решил создать такой: /channel/qa_memes
Подписывайтесь и отправляйте свои мемы)
Обещал рассказать, как проходит рабочий день? Рассказываю!
https://telegra.ph/Moj-rabochij-den-10-30
9 сентября тестировщики отмечают свой профессиональный праздник!
Дата была выбрана не случайно: 9 сентября 1947 года ученые Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле. В отчете о неполадках было зафиксировано, что причиной неисправности машины был баг (bug - жучок). Но при этом очень многие ошибочно считают, что тогда впервые и повилось понятие "баг". Однако, этот термин стал использоваться аж с 1870-х годов, задолго до компьютеров. Вот такая история.
Недавно на Хабре вышел перевод неплохой статьи про два метода управления проектами - Scrum и Kanban. В IT оба метода крайне популярны, а на технических собеседованиях достаточно часто спрашивают про преимущества и недостатки того или иного метода.
В компаниях, где я работал, используется симбиоз скрама и канбана - и это действительно мощно.
Не могу не согласиться с автором, что чистый скрам обычно неэффективен и приводит команду в бесполезную гонку по выполнению задач.
Что же касается канбана, то с ним я познакомился задолго до того, как пришёл в IT - когда участвовал в проекте, связанным с авиастроительной и машиностроительной отраслью - недаром этот метод зародился почти 70 лет назад в Toyota.
Ничего не знаете про эти два метода? Тогда перед чтением статьи посмотрите, к примеру, Википедию, а потом уже погрузитесь в статью.
✅- я за Канбан
🔄 - я за Скрам
🎌 - я за смешанный метод управления
https://m.habr.com/ru/company/ruvds/blog/510558/
Гайз, тут для вас подоспели отличные короткие интервью со знакомыми ребятами из самых разных IT-профессий. Как они стали айтишниками и что думают о тестировщиках? Какие инструменты используют и обучались ли на каких-то курсах ранее? Всё это - в течение ближайших двух недель на канале. Начнём с разработчиков: знакомьтесь, Дима, Java Developer ⬇️
https://telegra.ph/5-voprosov-razrabotchiku-07-14
Обратная связь
Как замотивировать себя на проекте? Ответ: получить фидбек от своих пользователей. Да, нередко он бывает негативным. Да, пользователям не всегда заходит фича, которую вы готовили командой в течение спринта. Но ведь это говорит о том, что юзерам интересен ваш продукт, они используют его, находят изъяны, чем-то недовольны, а от чего-то, наоборот, кайфуют. Такая обратная связь - очень ценная вещь.
Недавно у нас прошел интерактив с пользователями - нам припомнили всё, что можно было🙈. Но, самое главное, наши пользователи находились с нами, общались, предлагали свои идеи и задавали вопросы. Напрямую участия к этому интерактиву я не имел, но читал их сообщения и понимал, что мы идем в одном направлении, мыслим похоже, и поднимаем те же вопросы у себя в команде.
Документация на проекте
Нет ничего хуже для QA, если на проекте нет документации и вокруг тотальная agile обстановка с сопутствующим хаосом, изменением требований каждый час и т.п. Столько горя можно схватить - вы даже не представляете.
Но выход есть:
1) Начать писать тестовую документацию прямо сейчас, даже если вы только пришли на проект. Для этого общаемся с разработчиками, аналитиками, саппортом, девопсами, продуктовыми менеджерами - со всей командой. Общаемся и пишем.
2) Выстраивать процессы обмена информацией внутри команды. Хорошо, если есть единомышленники - продавливайте с ними свои идеи, пресекайте любые попытки вам помешать. Документация - это часть обеспечения качества. Нет документации - нет контрактов между интерфейсами, нет API, нет тест-кейсов, нет проекта.
Если первый пункт зависит целиком от вас и вашей QA-команды, то со вторым все намного сложнее. Документация разработчиков может выглядеть лишь поверхностным описанием работы приложения в Confluence, это в первом приближении разумно, так как в случае чего всегда можно посмотреть более точный источник - код. Но могут ли его посмотреть QA, другие коллеги? Далеко не всегда, да и в большинстве случаев не должны. Пусть аналитики напишут требования, а разработчики напишут, как они эти требования реализовали - они и только они владеют этой информацией.
Одновременно с этим, много документации - тоже плохо: протоколы меняются очень часто, нужно все взаимодействия отслеживать и своевременно править. Нужна золотая середина.
В общем, не буду томить: я пришёл к тому, что идеальнее и проще всего описывать процессы схемами, mind maps или UML-диаграммами. Последние - просто очень круты - схематично можно показать не только сам процесс какого-либо взаимодействия, но и хронологическую последовательность, то есть, условно, какой запрос за каким должен следовать - это безумно важно, когда к примеру тестируется бэкенд с кучей интеграций.
Напишите мне в личку - @pavelthai, как у вас построен процесс обмена информацией, какие инструменты используете, все ли делятся информацией? Независимо от того, где вы работаете - это процесс везде плюс/минус одинаковый. Самые интересные и полезные идеи опубликую в одном из ближайших постов.
MosQA #2
Мейлрушечка провела вчера второй митап тестировщиков MosQA. Если коротко - всё было на уровне. Встреча прошла в атриуме их офиса - обычно там сотрудники играют в волейбол/баскетбол, но в этот раз отдали площадку нам - зарегалось больше 600 человек на мероприятие.
Читали хорошие доклады про автоматизацию тестирования, развитие soft skills, взаимодействие с разработчиками и не только. Новые подходы и внутренняя кухня тестеров в других компаниях - это всегда интересно. А тем, кому было скучно, дали ссылку на сайтик, который можно было попытаться поломать и набрать за это баллы.
Чуть позже выложу ссылки на материалы, а пока ловите немного фоток с митапа.
Как улучшить продукт?
Неделя выдалась очень продуктивной: новый релиз, новые баги, а ещё внедрение новеньких Feature requests.
О фича реквестах как раз и поговорим. По сути, это запросы на улучшение приложения. Такие задачи не являются багами, а скорее пожеланиями на доработку продукта. Инициаторами могут быть пользователи, менеджеры, тестировщики, разработчики и т.п. - по сути, все заинтересованные лица. Но кому, как не тестировщикам, знать плюсы и минусы своего продукта? Где-то такие запросы поощряются руководством, где-то воспринимаются в штыки - ведь это дополнительная работа для всех. Задача тестировщика - постараться убедить руководителя, команду, менеджера или иное лицо, принимающее решение, что данная фича действительно необходима (потом она облегчит твою же работу).
Как я продвигаю свои фича реквесты?
1. Есть свободное время - изучаю продукт: анализирую, что было неудобно при последнем регрессе, какие операции оказались слишком рутинными, изучаю как реализовано у других, общаюсь с коллегами
2. Появилась идея - готовлю прототип и набрасываю начальные требования
3. Обсуждение. Общаюсь со своим руководителем, руководителем разработки
4. Если идея зашла и ее реализация существенно не бьет по бюджету проекта, то допиливаю требования
5. Готовлю feature request и жду релиз, в котором фича будет реализована.
С наступившим Новым годом, ребятки! Пусть бэклог уменьшается, баги своевременно находятся, а собеседования проходятся!
Очень скоро допишу для вас пост про работу в Германии: какие условия, требования к квалификации и к знанию языка.
Подписывайтесь сами и расскажите кому-нибудь из друзей о канале - это будет лучшим подарком мне на Новый год🙃
Новый год
Знаете, какому виду тестирования отводится особая роль в предпраздничные дни? Все верно, нагрузочному (load testing).
Для проведения такого тестирования нужны более узкие специалисты и инструменты (например, Apache JMeter, HP LoadRunner и т.п.).
В пиковые дни (праздники, акции) нагрузка на серверы в несколько раз (бывает, что и в десятки и сотни раз) превышает среднюю нагрузку. Если не оптимизировать приложение и инфраструктуру, то серверы скорее всего перестанут успевать обрабатывать запросы и прилягут на какое-то время.
Для имитации нагрузки тестировщики придумывают различные нагрузочные профили, которые отличаются, в основном, по времени и по количеству потоков.
Бэклог
Картинка с тюленями постом выше - суровая реальность работы разработчика и тестировщика. Проект растёт, ресурсов не хватает, задачи копятся.
Такое скопление задач, по которым уже сформулированы требования и которые поставлены в очередь на исполнение, называются бэклогом.
Чем меньше бэклог, тем ярче твоя жизнь- тебя любят все вокруг, ты можешь заняться своим проектом, поучиться чему-нибудь или просто лечь поспать.
Ребята, совсем забыл рассказать про Heisenbug Moscow - мегакрутое событие для тестеров и не только. Конференция проходила 5-6 декабря. Я поприсутствовать не смог, а вот моя хорошая подруга, Мила, там побывала и сделала несколько фоток для вас.
Что понравилось Миле?
- доклад про Appium от индуса
- доклады про Web Accessibility, про iot, про автоматизацию отдела автоматизации.
Полный список докладов смотрите здесь https://heisenbug-moscow.ru/
И не забудьте поучаствовать в следующем году - это того стоит.
#Ролевыеигры
Под этим хэштегом буду рассказывать о взаимодействии тестировщиков с другими членами IT-команды. Начну серию постов с разработчиков - все-таки именно они пишут код, делают его ревью и еще они тоже немного тестировщики - чаще всего именно они пишут Unit-тесты.
Для не очень посвященных вкратце объясню терминологию.
Ревью кода - это проверка одним из разработчиков кода своего коллеги - это позволяет оптимизировать код и улучшить его читаемость, а знания о новых фичах (особенностях) реализации продукта распространяются среди других коллег. Наличие код-ревью на проекте или в компании - это хороший тон, а для тестировщиков, собирающихся устроиться в такую компанию - отличный сигнал.
Unit-тесты - проверки кода на уровне функций, классов, процедур. Выявление ошибок самим разработчиком на самом раннем этапе обходится гораздо дешевле для компании, чем те, которые вылавливают тестировщики или, что еще хуже, обычные пользователи продукта.
И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂
Естественно, это происходит неосознанно и не специально. Более того, хороший разработчик не только тщательно покроет свой код юнит-тестами, но и напишет комментарии к коду, подготовит краткую документацию или статью для других, но и это не спасет его от наличия багов. Именно поэтому большинство задач разработчиков после ревью кода (рецензирования) переходит на следующий этап - тестирование. Здесь подключаются тестеры, которые получают новую версию приложения от разработчика, устанавливают его на тестовый стенд (сервер) и начинают делать самое интересное: пытаются его всячески сломать самыми изощренными способами.
Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.
А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.
Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷♂️. Как думаете, почему?
К слову, о митапах. На днях ходили с коллегами на обед, и разгорелся у нас спор не на шутку: имеет ли смысл ходить на все эти ивенты, митапы, конференции, или же это пустая трата времени?
Доводы ЗА и ПРОТИВ, по-моему, очевидны, но все же приведу их ниже.
Доводы ПРОТИВ:
- гораздо быстрее нужную информацию можно нагуглить
- тратится время/деньги, особенно, если ивент платный
- кейсы, которые разбираются на таких встречах, достаточно специфичны для конкретного проекта
Доводы ЗА:
- можно расширить свой кругозор, узнать о новых инструментах и техниках
- завести новые знакомства и контакты
- пообщаться с лидерами IT-индустрии
- задать вопросы экспертам вживую
Я склоняюсь к тому, что митапы - это мегаклассная штука. Неформальные встречи с коллегами, знакомства - все это помогает отвлечься от рутины.
Кстати, на митапе Redmadrobot, о котором писал выше, я совершенно случайно встретился с Алиной, своей бывшей... коллегой, которая перешла совсем недавно в другую компанию и теперь занимается там автотестами. С Алиной вы ещё познакомитесь в этом канале - она расскажет про автотесты лучше меня.
Ошибка
Я тут призадумался: часто ли я совершаю ошибки? Постоянно. Когда говорю на английском (и даже на русском), купить могу не то, что нужно, или попадаю в какие-то неловкие ситуации. И на работе проскальзывают баги на прод тоже.
Какие эмоции были бы у меня всего пару лет назад? Обида, страх, злость, разочарование, стыд. Мы привыкли бояться ошибок, совершать их, признавать их. И работать с ошибкой в большинстве своем не умеем.
Но если взглянуть на ошибку со стороны - то легко заметить, что в ней огромный смысл:
первое - мы люди и нам свойственно ошибаться
второе - в ошибке есть польза, она сигнализирует, что мы что-то упустили
Ошибка подсвечивает какие-то проблемы в процессах, в работе, в нашем поведении. А это значит, что сделав ошибку, теперь-то мы точно знаем, что нужно сделать, чтобы ее предотвратить и запомним это надолго!
Есть только один тип ошибок, который действительно неприятный - это когда мы знаем, как надо, но продолжаем делать неправильно.
Но какой бы ошибка ни была - отнеситесь к ней положительно, она уже в прошлом, она - иллюзия, а вы уже всё сделали правильно😉
Похоже, вы меня потеряли: постов нет, новостей нет. Но не всё так однозначно, сейчас объясню, почему так получилось.
https://telegra.ph/Pohozhe-vy-menya-poteryali-10-20
Как ищут работу тестировщики?
Многое зависит от опыта и от обстоятельств. В самом начале карьеры я бы посоветовал проанализировать вакансии в hh. Из нескольких вакансий путем нехитрых манипуляций можно выделить ключевые навыки, в которых заинтересовано большинство работодателей.
На каждом шагу говорят, что не нужно бояться собеседований - это действительно так - каждое неудачное собеседование подсвечивает ваши слабые места. По моему опыту, неправильный ответ на некоторые задачи (на логику, алгоритмы и т.п.) - не означает автоматический отказ со стороны будущего работодателя: покажите ход своих мыслей - это зачастую поможет обнаружить ошибку. Будьте откровенны - если каких-то скиллов не хватает - не стоит говорить, что они есть, работодатель достаточно быстро это выяснит, поработаете вы в итоге совсем недолго, а репутацию подпортите.
За опытных QA-инженеров компании готовы бороться - часто таких специалистов могут схантить знакомые HR или бывшие коллеги - в этом плане возможностей становится больше, собеседование сводится как правило только к техническому разговору с будущим руководителем.
Продолжаем разговор с айтишниками: сегодня мои коллеги - Иван, менеджер проектов в крупной телекоммуникационной компании, и Марина, системный аналитик в банковском секторе, расскажут о том, как они пришли в эту сферу, как взаимодействуют с QA-инженерами и что они могут посоветовать будущим тестировщикам (да и действующим тоже:)
Если вдруг у вас тоже появились вопросы к ребятам - смело задавайте их в комментариях к посту, ответим!
https://telegra.ph/5-voprosov-menedzheru-proektov-i-sistemnomu-analitiku-07-18
Lockdown, bye!
Поздравляю, более-менее все выходят из локдауна, это здорово. Для меня удаленка - это плюс 1,5 - 2 часа свободного времени, которое я раньше тратил на дорогу до работы. Знаю, что у многих получилось занять это время под более полезные вещи. Я вот взял курсы английского в Skyeng. Только мы с преподавателем решили, что это я её буду учить, а не она меня. И вот как мы это сделали: я скидываю в наш чат интересные англоязычные статьи про QA, а на ближайшем уроке мы их обсуждаем, анализируем и иногда спорим. Сегодня вот буду рассказывать Татьяне, кто входит в IT-команду, и какие задачи решают эти люди. Посмотрим, поймет ли она мои корявые объяснения на английском😜
Работа в Yandex
Моя подруга Мила (работает QA Automation Engineer в одной зарубежной компании) успела до пандемии коронавируса попасть на экскурсию в Яндекс и поделилась своими впечатлениями.
Далее Мила от первого лица:
«Я сходила на экскурсию в офис Яндекса для технических специалистов (было это 26-го февраля - да, улиточка во мне не дремлет! Или как раз дремлет).
Кто может попасть на эту экскурсию? Любой технический специалист в сфере информационных технологий, который зарегистрируется на сайте https://yandex.ru/promo/on-site. Сейчас, впрочем, надо дождаться окончания периода самоизоляции. Приглашают они не всех. Как выбирают, кого позвать, а кого нет - не знаю. Меня позвали, а коллегу, который прислал мне ссылку с предложением зарегистрироваться - нет.
Что было на экскурсии? Водили по офису и показывали, как у них там хорошо. Есть кабинки, похожие на телефонные будки - в этих кабинках можно уединяться, если вдруг захотелось. Даже кресла для интровертов имеются - с высокими спинками и боковыми стенками - сядешь в такое и никто не достанет. Много разных кухонь с запасами различной еды в виде мюслей, каш, чая, печенек и еще чего-то подобного.
Офис очень зеленый, вся зелень настоящая с автоматическими поливалками.
Кстати, в самом офисе на лестничных площадках есть карты с указанием того места, где вы находитесь и всех помещений, что находятся с вами на этаже.
Приятный парень, работающий в Яндексе бэкенд-разработчиком, рассказал об условиях работы: оплачивают фитнес, занятия английским, участие в конференциях, ДМС со стоматологией с первого дня работы (насколько я помню), даже выдают деньги на покупку квартиры - на 3 года без процентов или на 10 лет под 3% годовых.
Помимо заработной платы каждому сотруднику начисляют 9700 рублей для обедов. Этими деньгами можно оплачивать обед в большинстве кафе и ресторанов, что находятся в шаговой доступности от офиса. А также каждый день на карту падает некоторая сумма до 10 утра, которую можно потратить на завтрак. Если вовремя не потратить, то деньги сгорают, конечно, потому что начисляются на пропуск, с которым сотрудники проходят в офис. Им же и производится оплата в кафе и ресторанах.
Что может быть интересно девушкам - в офисе есть комната матери и ребенка. Все сотрудники без проблем могут приводить в офис своих детей. Которым там точно будет, чем заняться.
На крыше офиса площадка для отдыха, в самом офисе - столы для игры в настольный теннис, различные зоны отдыха и все, что может понадобиться человеку.
А ещё в Яндексе дают премию своими же акциями. Но не совсем акциями, потому что вроде как они есть, но дивиденды будут начисляться только через 4 года после их получения и только если все эти 4 года работать в Яндексе. Каждый год активируется четверть полученных в виде премии акций».
Как вам условия? Хотели бы работать в Яндексе?)
Только хотел написать анонс про митап в Райффайзенбанке, который планировался в марте, как коллеги рассказали, что регистрацию на него прикрыли из-за короновируса и карантина. Чувствую, такими темпами все перейдут скоро на вебинары. Ну, а картинка просто в тему) Не болейте!
UPD: пока митап перенесён на апрель, подождем-с.
Профдеформация и перегорание
У многих тестеров есть одна не очень хорошая особенность: чем дольше они работают в тестировании, тем больше косяков и изъянов замечают вокруг, в том числе и за пределами работы. Это угнетает, удовольствие от самой работы проходит, и иной раз масла в огонь подливают отдельные разработчики (не все), которые в тестерах в первую очередь видят монстров, ломающих тестовые стенды. В общем, налицо выгорание, хроническая усталость и все такое.
Самое главное в такой ситуации - вовремя остыть и успокоиться. Теряешь контроль - бери отпуск. Это самый лучший вариант. Еще можно переключиться на другой продукт и другую команду, если есть такая возможность в компании.
Какой будет зарплата, если ты решил переехать в Германию?
В минувшие праздники я побывал в Гамбурге и Берлине и заодно выяснил, что же ждёт тестировщиков там.
Вообще, зарплата у IT-сотрудников в Германии несильно отличается от зарплат специалистов другого профиля - учителей, юристов, аудиторов, финансистов. Многие инженеры и врачи здесь будут получать даже побольше, чем айтишники.
По требованиям все достаточно уютно: из всех вакансий, которые я просмотрел, только в одном месте, к примеру, потребовалась сертификация ISTQB FL. Инструменты для тестирования - фактически те же, что и указаны в большинстве наших вакансий. Заметил, что тестировщики требуются для многих индустриальных компаний, соответственно, требуются знания на стыке технологий - из машиностроения, робототехники.
Основное препятствие - знание языка. Немецкий нужен не менее B2, чаще - C1. Английский - Intermediate, Upper-intermediate. Часто команды интернациональные и рабочий язык английский, даже если большинство сотрудников в команде - немцы.
Зарплата - пожалуй, самая больная тема из-за больших налогов. В Германии существуют налоговые классы, в зависимости от которых меняется налоговая ставка. Например, если ты приехал в Германию один, без семьи и детей - налог будет одной величины, если приехал с семьей - налог уже будет поменьше. В вакансиях поэтому часто указывается годовая(!) зарплата брутто, до вычета налога. Для примерного расчёта налога есть куча онлайн-калькуляторов, которые учитывают налоговые классы.
По моим очень усреднённым подсчетам джун-тестировщик будет получать около 2000-2500€ в месяц на руки. Автотестеры - 3000-3500€ на руки. Понятное дело, везде есть свои исключения.
#Ролевыеигры
DevOps
Честно, я в восторге от наших девопсеров. Их работа часто невидима и неосязаема, но в этом и фишка - на них держится автоматизация CI/CD-процессов, мониторинг продуктивной среды, поддержка разработчиков и тестировщиков.
Если бы у нас их не было в команде - мы бы погрязли в рутине.
Внедрение автодеплоя (автоматизированной установки приложения на сервер) на моем проекте - во многом результат моей лени и большого желания автоматизировать процесс и двух девопсеров с их желанием помочь - до этого мне приходилось делать всё вручную.
Что значит деплоить вручную, спросите вы. Это значит, что один и тот же набор операций нужно будет монотонно сделать на всех нодах приложения и, разумеется, где-то забыть поменять конфиги, где-то поставить не ту сборку, где-то не прокатить скрипт. А потом полдня разгребать, почему тестовый стенд не работает. Я, конечно, утрирую, но плюс/минус такие ситуации случались.
По моим оценкам после внедрения автодеплоя влияние человеческого фактора на проекте снизилось на 80%, трудозатраты на деплой тоже снизились, процентов на 60%.
В итоге каким бы ленивым я ни был, но автодеплой вынудил прокачать некоторые скиллы - мы стали юзать git, Ansible, научились немного настраивать плейбуки и работать с YAML-форматом. Вот такие дела.
Резюме
Недавно помогал подруге с разбором резюме ее ученика - он хочет найти работу в тестировании, но опыта не так много. Некоторые тезисы по разбору оставлю здесь.
1. Электронную почту лучше всего указать с формальным адресом - по типу ivan.ivanov@...
2. Непрофильные образование и опыт работы (не IT) лучше всего не указывать, либо указывать максимально лаконично - эта информация скорее всего не заинтересует IT-рекрутера и будет лишней.
4. Когда совсем мало опыта, остаётся делать акцент на стажировки, тренинги, курсы - в резюме нужно указать не только название, но и приложить ссылку на сертификат.
5. Не нужно указывать курсы, которые вы прошли на пиратских ресурсах, - это очень быстро выявляется и может перекрыть доступ сразу к нескольким крупным компаниям.
5. Hard skills лучше детализировать. Умеете работать в баг-трекинговой системе - в какой именно? Умеете проводить нефункциональное тестирование - какое именно?
6. Подгонять резюме под вакансию не нужно - требования в вакансии нужно учесть при составлении резюме, но не более.
Да, кстати, в этом посте есть небольшой «баг». Нашли?
Регрессионное тестирование (Regression testing)
На нашем проекте сейчас начинается, пожалуй, самый рутинный этап для тестировщиков - регрессионное тестирование, то есть проверка того, что раньше работало, но могло сломаться в новой версии приложения.
Что обычно делают тестировщики в первую очередь?
⁃ Актуализируют тест-кейсы, если этого не было сделано ранее (например, по изменениям, которые появились в новой версии)
⁃ В конце спринта фиксируют версии всех компонентов приложения
⁃ Анализируют результаты прохождения автотестов
⁃ Проводят смоук-тестирование
⁃ Проводят регрессионное тестирование
⁃ В случае отсутствия критичных/блокирующих багов готовят релиз-кандидат к передаче в продуктив
Все перечисленное выше - достаточно гибкая штука и зависит от конкретной компании и проекта, но подход одинаков примерно везде.
Традиционно расшифрую терминологию (объясню простым и даже примитивным языком, более верные и полные с академической точки зрения определения лежат где-то в гугле):
Спринт - период времени, в течение которого запланирован выпуск нового релиза (и, получается, должны быть закрыты задачи на разработку и тестирование)
Автотесты - автоматизированные проверки, выполняемые на тестовом стенде без участия человека (сами автотесты пишутся, разумеется, человеком)
Смоук-тестирование - проверка основных функциональностей приложения на предмет отсутствия блокирующих и критичных багов.
А вот и #тестовое_задание подоспело.
В процессе регресса веб-приложения по доставке еды тестировщиками было выявлено два бага:
1) при попытке входа в личный кабинет у пользователя перестал отображаться баланс бонусных баллов, полученных за уже выполненные заказы, воспользоваться баллами из-за этого не получается
2) ранее на странице ввода адреса доставки для полей Город и Улица при вводе символов пользователю отображался выпадающий список с подсказками, соответствующими его вводу. Теперь выпадающий список перестал отображаться.
Являются ли данные баги критичными/блокирующими для этого релиза? Оценку нужно дать каждому багу. Общаемся здесь @qa_chat
Весомый плюс работы в IT-сфере - возможность работы удаленно. Даже если вы привязаны к офису, то, как правило, несколько раз в месяц, а то и в неделю, сотрудник может поработать из дома.
В каких-то компаниях нужно согласовать с руководителем весомую причину для удаленной работы (обычно это из серии "приболел, но готов поработать по VPN и не идти на больничный"), в других компаниях для удаленной работы достаточно предупредить коллег, а в третьих компаниях люди и вовсе всегда работают удалённо - из дома, коворкинга или сидя в гамаке где-нибудь на Бали.
Обычно я работаю из дома, когда действительно себя неважно чувствую или когда нужно немного абстрагироваться от офиса и полностью переключиться на свои текущие задачи. Эта потребность обоснованна: тестировщики наряду с менеджерами проектов самые общительные в IT-команде (готов поспорить с теми, кто так не думает, в чате канала @qa_chat ;). А продвинутые QA и тимлиды в течение рабочего дня часто переключаются на задачи своих же коллег. В итоге к концу дня может оказаться так, что задачи коллег закрыты, а твои остались нетронутыми до следующего дня) Вот в такие моменты удалёнка сильно выручает.
Сходил на митап к роботам, они же Redmadrobot - в IT-сфере, а точнее - в мобильной разработке - ребята известные и работают аж с 2008 года.
Доклады были очень доступные, рассчитаны на QA-джунов и -миддлов.
А вот и сами темы:
- UI-автотесты под iOS для самых маленьких
- UI-автотесты: неочевидные очевидности в планировании и реализации
- No pain, no gain: тестируем голосовые приложения
Меня особенно впечатлил последний из этих докладов: Паша Булич из KODE рассказал о сложностях, которые решала его команда при тестировании голосовых навыков для Алисы. Вообще, тестирование голосовых помощников - тема неизбитая - информации мало, перенять чужой опыт практически не у кого. Но стандартные техники анализа работают, к счастью, и тут: естественно, есть и граничные условия, и классы эквивалентности и т.п. О них обязательно расскажу более подробно в ближайших постах.
