JavaScript fwdays conference: performance, Node.js, animations, DevTools and more
×Закрыть
Lead Software Engineer In Test @ Playtika
  • QA как класс уходит в небытие?

    QA не уходят и не уйдут — просто эволюционируют их задачи на проекте и требования к ним как к инженерам.
    Сейчас QA (в мировом масштабе) это не самый простой способ «войти в айти».
    Лет 8 — 10 назад достаточно было прочесть книгу Савина и уметь установить Виндовс — и тебя брали :).
    Сейчас продукты стали намного сложнее. Одностраничные и статичные веб сайты со скудным набором функционала давно уже пропали. Все пилят «комбайны». Куча интеграции, CI\CD, эти ваши микросервисы, клауды и иже с ними.
    Поэтому и требования к QA уже подтянулись к проектам.
    Девелоперы могут и должны писать тесты. Как можно больше автотестов на разных уровнях.
    Но, те же QA должны иметь возможность оценить на каком тестовом уровне у нас есть «проседание в кавередже», где потенциально могут быть риски и где нужно потестировать лучше и тщательнее. Это все — требует очень хорошего технического бекграунда у специалиста.

  • Senior automation QA vs Senior developer

    На данный момент на рынке ИТ Украины сложилась очень интересная ситуация с этими самыми Automation QA.
    На каждом проекте и в каждой компании эту должность видят по своему. Где — то — это просто QA, который время от времени пописывает тесты (в готовом солюшене), где — то это человек, от заката до рассвета пищущий тесты на регрессию (стремясь догнать и покрыть новые фичи).
    Где — то — даже выделяют новую («высшую :)») ветку развития AQA — это Software Engineer In Test / Software Developer In Test (которые пилят фреймворки и драйвера для браузеров, солюшены для автоматизации, внутренние сервиса для девелоперов и куа, настраивают тестовую инфраструктуру, прочее).
    Обычно для «пописывать тесты» или просто засучив рукава покрывать все UI тестами на Selenium Webdriver (или даже API автотестами) навыков программирования выше джуниор-миддл девелопера не нужно.
    Для работы SDET / SET — нужен набор навыков такой же как на девелопера — просто сфера разработки будет специфическая.
    В плане интересности работы — зависит очень от конкретной работы и от человека.
    Есть проекты, где очень крутые девелоперы занимаются днями и ночами конвертацией XML в XML и ничего больше — надо ли Вам такое?:)
    Есть проекты, где надо только покрывать регрессию — и в репозиторий с фича кодом Вас не пустят («ну ты же всего лишь тестер»).
    Есть проекты, где написание внутренних тестовых сервисов, настройка окружения и вылавливание багов в сложной распределенной системе может быть даже интереснее — чем собственно написание фича кода плюс минус похожего от таски к таске.
    И последнее. Кроме денег, решите, что Вам более по душе — пилить фича код, релизить и видеть, что он реально сейчас и сразу приносит пользу и деньги — или пилить штуки, которые будут помогать всей разработке и куа в компании в целом.

  • Складнощі тестування мікросервісів та що з ними робити

    Если еще нужны материалы — советую начинать с habr.com/...​y/oleg-bunin/blog/349632 .
    Дальше тоже про подходы: www.infoq.com/...​ques-microservices-intro

  • Складнощі тестування мікросервісів та що з ними робити

    Микросервисы очень хорошо тестируются атомарно.

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

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

    Разные средства коммунации между сервисами: но ведь и в монолите могут быть разные типы апи, которые так же надо тестировать. И тоже — изучать надо много инструментов.

    Для микросервисов вполне можно делать UI тестирование — как системы целиком. Нужно только иметь самые важные кейсы на этом уровне. И если сервис покрыт тестами хорошо на нижних уровнях — то много автотестов на верхнем уровне при деплое сервиса не нужно. (Особенно если изменение деплоится в hidden mode). Отдельно можно заморочиться с Test Impact Analysis (автоматически или вручную) и запускать ровно те UI тесты, на которые влияет конкретный сервис.

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

    В любом случае при тестировании микросервисов свои трудности есть. Но, имхо, они больше сосредоточены в сложности и непредсказуемости таких систем в больших масштабах (на продакшене).

  • У 2018 році 184 тисячі українських програмістів забезпечили експорт IT-продукції на 4,5 мільярда доларів і за обсягом експорту індустрія посіла друге місце в країні

    Дополнительно удивило, что у нас оказывается 20 процентов компаний лидеров имеет офисы. Не нашел локаций в Украине у Microsoft и Huawei. Статистика видимо неточная.

  • Онлайн тестирование для программистов

    Чем текущий ресурс отличается от quizful или brainbench?

  • А что у нас сейчас в Украине с депозитами?

    А каким образом для не резидента страны евросоюза это можно провернуть?

  • Как выжить в круговороте современного IT, или Зачем изучать основы

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

  • Порошенко запретил вконтакте, яндексовские сервисы, и другие

    А Spotify в Украине уже доступен?

    Поддержали: Gennady Dogaev, Oleksandr Tkalenko
  • Блиц-опрос: нужны ли гуманитарные предметы в технических вузах

    Обычно если человеку любопытна та или иная дисциплина — то он сможет ею овладеть. Тот же Ричард Фейнман помимо физики, занимался и биологией, и изучал языки, музыку.
    Ключевое слово — любопытство (интерес). Если студенту реально интересно изучить экономику, философию или культурологию — то добро пожаловать на факультативы.
    А в быстром темпе и скомканно запихивать знания (считая что они самые важны) — это явно не полезно.

  • Некоторые IT-компании сами виноваты, что к ним пришли с обысками — Дмитрий Шимкив

    Которые не знали, что они взламывают. Они просто писали код. А он что — то делал. Втихаря. По ночам.

  • Девушки в QA, идти или не идти?

    Откройте вакансии практически любых стартапов или софтверных компаний Европы/США и найдите там мануальную позицию. Нет? Или все должны ориентироваться только на локальный украинский рынок — ведь это он диктует все новые подходы в программировании / тестировании :)
    Везде нужны специалисты инженеры — которые могут и собрать продукт, и настроить любое окружение, и код тестов / скрипты написать, и руками проверить (и еще кучу сопутствующих задач). Или Вы думаете вручную без знания системы и того, как работает код, можно протестировать нагрузку, безопасность, выявить утечку памяти и различные низкоуровневые (но не менее критичные) баги? Или качество — это найти, что у нас инпут на странице на два пикселя съехал?
    На любую позицию кьюа инженера первое, что дают соискателю — это тест на умение писать код и решать базовые простые алгоритмические задачки. И это еще на этапе собеседования с рекрутером. А потом уже идет техническое задание / собес и тд.
    Программирование на базовом уровне становится стандартом для любого специалиста в сфере инжиниринга ПО. Чистые мануальные тестировщики могут быть (очень изредка) если имеют огромные знания в смежных областях — например финансы или медицина (причем включая зарубежные стандарты). Но таких людей у нас на рынке тоже очень мало.

    Поддержал: Nian Terry
  • Япония отменила гуманитарные науки

    Даже не так. Это все должны предметы по выбору. Если человеку очень хочется изучить основы экономики, менеджмента или литературы ( интересы разные бывают, не только же ИТ ), то студент может взять эти курсы как факультатив.
    А то получается забивают почти всю учебную сетку этими предметами, а реальных инженерных предметов — очень мало.

  • «Пришлите фрагмент вашего кода» и NDA

    Многие компании частично автоматизировали процесс первичного отсева кандидатов путем использования сервисов оценки, вроде codility.com. Там каждому кандидату за ограниченное время предлагается решить N небольших задач (разного уровня). Решения прогоняются через заранее определенные наборы тестов и оценивается как кандидат может решать типовые задачи, беря во внимание time/space complexity. А дальше уже идет обычное техническое.

    Поддержал: Андрей Помазков
  • QA дайджест #10: Удобная коллекция докладов SQA Days, библиотека самообразования, Testing Challenge

    Крутая подборка. Спасибо.

  • Встречи мануальщиков QA

    Если скилл тест инженеров позволяет — можно и сорцы проекта смотреть — вайт бокс тестинг еще никто не отменял. Особенно стандарты по безопасному коду.
    По поводу вечного поиска после работы после курсов — у меня есть примеры людей, которые после курсов тестирования, еще шли на курсы автомейшена и в общей сложности потратили почти год ( год, Карл!) напряженного обучения для получения работы. И такие люди безусловно достойны уважения.

  • Встречи мануальщиков QA

    Я всецело за подобные мероприятия, тусовки и прочее. В нашем городе встречи кьюа комьюнити организовываются время от времени. Основная проблема — люди не хотят делиться ни своим опытом, ни делиться проблемами и путями решения.
    Разделение тестировщиков на автоматизаторов и ручных — это сугубо СНГшные условности. В зарубежных компаниях (как в стартапных так и крупных), тестировщики всецело отвечают за качество — начиная от требований, заканчивая написание тулов, инфраструктуры автотестинга и прочим (вплоть до код-ревью и тд). Поэтому в большинстве своем и доклады как ни крути, но получаются тоже технические.
    Вывод 1: общаться и собираться нужно, но людям, которым это интересно и которые готовы обсуждать темы и после доклада (даже если будет 5 человек). А если эти сборы — очередной повод поесть печеньки с кофе в офисе лидера рынка, послушать с умным видом доклад и пойти домой сразу же — то грош цена таким встречам.
    Вывод 2: для вопросов от начинающих и продолжающих — есть огромное количество скайп и слак чатов для тестировщиков, где по возможности народ всегда рад помочь советом.

  • Пособие для будущего Java разработчика. Новые горизонты

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

    Поддержал: Artem Pychenko
  • Суровая реальность начинающих тестировщиков. Пособие: что и как учить

    Самая главная полезность курсов (еси эти курсы действительно для обучения, а не для стрижки «капусты») — это возможность получить фидбек от выполненных заданий. Если на курсах обещается только «теория» — можно смело забивать на такие курсы.
    Но для того, чтобы этот фидбек получить и вынести из него максимально информации — требуется огромная работа и изучение материалов вне курсов.
    При необходимости курсы можно заменить: желанием + невероятной усидчивостью + наличием работающего знакомого (который может провести ревью и дать обратную связь).
    Конечно компаний много и требования разные, но имхо кроме Савина и 30 минутного урока по БД — нужно потратить значительноевремя на то, чтобы разобраться — как работают те же веб (мобайл) — приложения. Чтобы не было потом ситуации, когда джуниор/трейни с горящими глазами наизусть рассказывает весь словарь ISQTB терминов (порой не понимая и половины), а потом сыпется на вопросе — что такое IP адрес. (молчу уже про навыки программирования).
    Вывод: попасть в тестирование можно — но курсы — это только 20% от того, что нужно знать.

  • Кто займет вакантные места в IT в ближайшем будущем

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