×Закрыть
Software Engineer @ Playtika
  • Как сократить ручное тестирование и можно ли без него обойтись

    Огромное спасибо за статью.
    TestFest / BugBush / etc — имеет как плюсы, так и минусы.
    Плюсы — это разные люди с разным бекграундом внутри компании могут проверить функционал.
    Минусы — крайне редко эти самые люди обладают достаточно глубоким знанием продукта. Как результат — это скорее всего приведет к куче багов UI/UX, но крайне небольшому количество действительно критичных багов.
    Плюс ко всему возникает вопрос — кто формирует конфигурацию для тестирования, если требуется пройти кейсы на куче операционных систем, девайсов, разрешениях, версиях и тд?
    Как в таком случае проходит тестирование безопасности, производительности, и тд?

    Если говорить o QA как просто «пройди вот эти кейсы и отметь несоответствия бездумно» — то да — такой подход с фестами и код кавередж метриками подойдет.

  • Автоматизация тестирования: подготовка стратегии и подводные камни внедрения

    Зависит от конкретного продукта, проекта, процесса разработки.
    А также — зависит от того, что называть интеграционными тестами.
    Если интеграционные тесты — это проверка бекенда через АПИ запросы — то такие тесты вполне могут написать отдельно взятые автоматизаторы (с ревью девелоперов на предмет полноты покрытия).
    А если же интеграционные тесты — это как кусок бизнес логики работает в внутренней базой данной, меседжинг системой или другим third-party — то гораздо лучше и правильнее, когда подобные тесты напишет девелопер функционала — т.к. он\она лучше всего знает специфику конкретного изменения в коде.

  • Автоматизация тестирования: подготовка стратегии и подводные камни внедрения

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

    Для меня все-таки не раскрыта тема стратегии автоматизации: что должно быть туда включено, как донести (и «продать») ее до разных участников процесса девелопмента?

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

  • Как развиваться тестировщику, если не привлекает автоматизация

    Спасибо за статью.
    Действительно — если не хочется в автоматизацию (разработку) то есть варианты.
    Но для грамотного performance / security тестирования нужно знание на уровне разработчика, а то и выше (плюс технический бекграунд).
    Тестирование безопасности — это не просто «запустил анализатор — получил автоматически отчет — отправил менеджеру». Это знание веб — технологий, как входные параметры обрабатываются на сервере; как работает внутри приложение для мобильных девайсов и где что может пойти не так. Для вирусного аналитика — умение читать дизассемблированный код — дабы понять — что делает тот или иной вирус.
    Тестирование производительности — в любом случае надо будет писать скрипты для нагрузки, профилировать приложения — и тут без знаний как работает код не обойдешься.
    Вывод: в большей половине экспертной ветки для тестировщика — так или иначе писать и понимать код — это крайне важно. Просто знания кода нужны специфические.

    P.S. Везде на вакансии этих самых FAANG — тестировщика сначала погоняют по алгоритмам, структурам данных и прочему. А потом — написать тесты и обьяснить — где потенциально может быть проблемы. На чем нужно их писать — на каком-то языке программирования.
    А то что там написали Manual QA — совершенно ни о чем не говорит.
    Вот требования на тест инженера в Гугле:
    — Lead/collaborate on improving developer and engineering team’s test coverage, release velocity and production health
    — Work closely with development teams in instrumenting their workflow to build a comprehensive picture of velocity, coverage and quality
    — Hands-on ability to automate repeated tasks and build test coverage through existing or new infrastructure
    — Write moderately complex code/scripts to test systems, implementing test harnesses and infrastructure as necessary

  • 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

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

← Сtrl 12 Ctrl →