Тестирование веб-сервисов *

Если задуматься, для каких российских компаний тестирование может быть особенно хардкорной задачей, в голову сразу приходят Сбербанк-Технологии. Во-первых, там гигантские масштабы, во-вторых, большая ответственность (финансовые операции — это вам не фотошеринг с геолокацией), в-третьих, взят курс на максимально быстрый релизный цикл: то есть тестировать нужно очень много, очень качественно и при этом очень быстро.

Каково живётся с такими почти взаимоисключающими установками? По следам конференции Гейзенбаг, где компания была спонсором, мы задали несколько вопросов Антону Романову из её Департамента качества — заместителю начальника отдела тестирования корпоративно-кредитных систем.

Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.

Прежде чем начну рассказывать про сам selenium grid и все, что связано с ним, я хочу пояснить суть проблемы, которую мы пытались решить.

В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline.

В Москве конференция Гейзенбаг уже проходила в декабре 2016-го, а теперь впервые добралась до Петербурга. Суть у Гейзенбаг 2017 Piter осталась прежней: «конференция о тестировании, но не только для тестировщиков». А изменились ли детали? Какие доклады были в этот раз? Правда ли, что Илари Хенрик Эгертер сбрил свою удивительную бороду? Ответы на все эти важнейшие вопросы — под катом.

Прошли те времена, когда банковские системы представляли из себя большие монолитные приложения, неспешно обновляющиеся с учетом требований регулятора. Сейчас это сотни взаимодействующих между собой подсистем и тысячи модулей,  которые непрерывно развиваются вместе с новыми требованиями бизнеса и быстро меняющимся IT-пространством. На разработку всего этого брошены сотни отдельных боевых единиц — Agile-команды.

Представьте: вы работник стартапа, сварганили по-быстрому прототип и постепенно начинаете его развивать. И вот вам уже хочется, чтобы во время очередного спешного релиза не приходилось перепроверять все разделы сайта вручную (руками директора по продукту). Конечно, можно нанять отдельного тестировщика, но на это в вашем LEAN-стартапе бюджета не дают — «лучше давайте купим наконец-то кофе-машину». Знакомо?

И тут кто-то произносит слово «автотесты».

И сразу начинается: это целая история, это очень сложно, это очень дорого, от этого будет больше вреда, чем пользы и вообще это кровавый Enterprise и СЕЛЕНИУМ.

На конференции Гейзенбаг, помимо основной программы, будет бонус от компании T-Systems: на её стенде проведёт небольшой мастер-класс сотрудник Герман Варгин, уже знакомый многим тестировщикам по выступлениям на других конференциях (вот даже Google Images всё про него понимает).

А в преддверии Гейзенбага мы решили узнать больше о том, как обстоят дела с тестированием внутри самой компании, и задали вопросы трём её сотрудникам: самому Герману, Андрею Павлову (он также известен своими докладами) и специалисту по внутренним коммуникациям Марии Зерновой.

Где находятся сердца конференций, организуемых JUG.ru Group? Сердца конференций, конечно же, в их главных залах. И если на конференцию в Питер вас не отпустил начальник и даже не согласовал онлайн-участие — мы откроем для вас окно в сердце Гейзенбаг 2017 Piter. Смотрите в это окно сами, пригласите коллег и начальника — в следующий раз вы точно сможете прийти лично (или получить полный онлайн-доступ) и целиком окунуться в стремительный и бурлящий поток жизни конференции.

4 июня 2017 в 10 утра (по московскому времени) мы откроем бесплатную онлайн-трансляцию из главного зала конференции.



Ссылка на онлайн-трансляцию первого трека конференции Гейзенбаг 2017 Piter и краткое описание докладов — под катом.

Как заметить, что для компании важно тестирование? Если компания спонсирует соответствующую конференцию, а её сотрудник выступает там с докладом — значит, важно. В случае с Grid Dynamics и конференцией Гейзенбаг всё обстоит именно так, и перед конференцией мы решили задать вопросы двум сотрудникам компании:

• Евгению Хорохорину, генеральному директору Grid Dynamics в России — о компании в целом
• Илье korobochka Коробицыну, ведущему QA инженеру, который и выступит на конференции — непосредственно о его работе

АБ-тестирование — один из самых сильных и полезных инструментов управления продуктом, который позволяет оценить эффективность тех или иных решений на экономические показатели в интернет-бизнесе. За пять лет работы мы провели огромное количество АБ-тестов, и поэтому отлично знаем, насколько сложно провести эксперименты правильно и какие ошибки повторяются постоянно.

Несколько месяцев назад один из наших конкурентов начал делать странное – предлагать нашим клиентам сравнение своей системы рекомендаций с Retail Rocket через АБ-тесты в формате «пари» с обязательством заплатить 100 000 рублей в случае проигрыша.

Подобные истории для нас не редкость — за время существования компании нашу систему сравнивали практически со всеми существующими рекомендательными системами в России и за рубежом, и мы всегда показывали отличные результаты (ни в одном тесте мы не проиграли по эффективности).

Первый тест с Rees не заставил себя ждать, но в ходе его проведения мы столкнулись с довольно странными результатами, которые вылились в серьезное исследование. То, что мы обнаружили в итоге, удивило нас так сильно, что мы хотим поделиться деталями этого исследования и вынести его результаты на суд IT-сообщества и индустрии электронной коммерции в России.

Целью данной статьи я ставил показать людям, не знакомым с тестированием, как можно действительно быстро начать тестировать, собрав все в одном месте с минимумом воды и на русском языке. Пусть это будет весьма примитивно. Пусть не очень интересно людям, которые уже живут по TDD, SOLID и другим принципам. Но дочитав до конца, любой желающий сможет сделать свой первый уверенный шаг в мир тестирования.

Мы рассмотрим приемочные (Acceptance), функциональные (Functional) и юнит-тесты или модульные тесты (Unit-Tests).

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

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



После того, как вы просмотрите приведённый ниже контрольный список задач, которые нужно решить для обеспечения безопасности веб-проекта, вы, наверняка, сами увидите, что многое из того, что в нём есть, в вашей разработке не учтено. Что делать? Как минимум — будьте честны с потенциальными пользователями и сообщите им о том, что ваш проект пока находится в стадии разработки, что вы предлагаете им ознакомиться с прототипом, в котором пока не реализована полноценная система безопасности.

В апреле наши коллеги побывали на международной конференции по системному и бизнес-анализу Analyst Days 2017, проходившей в Москве. Под катом — впечатления от самых интересных, на наш взгляд, докладов этой конференции.

Доклады были сгруппированы по тематическим блокам. Начнём с краткого обзора докладов секции Качество требований, которая, как можно было судить по переполненным залам, вызвала большой интерес со стороны участников конференции, так как докладчики затрагивали одни из наиболее важных аспектов работы бизнес-аналитиков.

Светлана Шаповалова, редактор «Нетологии», адаптировала статью Michael O'Brien, в которой он составил чек-лист для веб-разработчиков, предпочитающих разрабатывать не только удобные, но и безопасные приложения.

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

Если вы уже заразились идеей «минимально жизнеспособного продукта» (англ. MVP — minimum viable product, прим. перев.) и считаете, что за месяц можно создать одновременно полезный и безопасный продукт — подумайте дважды, прежде чем выпускать его. Просмотрев чек-лист, вы поймете, что оставляете немало уязвимостей.

Сегодня пятница, впереди выходные и много свободного времени – пора публиковать десятку лучших докладов с Гейзенбаг 2016 Moscow! Подборка получилась весьма разнообразная и охватывает тестирование со всех сторон. Рейтинг, как всегда, предельно объективен, никем не проплачен и основан на отзывах тех, кто был на докладах.



Впрочем, вы можете проверить всё сами: полные видео докладов под катом.

Вы наверняка знаете, что есть большая разница между тем, как будет работать ваше приложение/сервис в зависимости от того, сколько пользователей его используют. То, что работало во время разработки, может развалиться, когда придут первые реальные пользователи со своим окружением, а то, что работало с сотней пользователей, может умереть, когда их станет 10 тысяч. Или бывает, что вы все потестили на искусственных данных, а потом ваша база начинает торзмозить из-за пользователя с именем İnari.

О том, как выживают баги, когда «включать» в проекте нагрузочные тесты, откуда брать для них данные и можно ли вообще не тестировать, вывалив результаты сразу в продакшн, мы поговорили с Алексеем Лавренюком («Яндекс») и Владимиром Ситниковым (Netcracker).

Старший инструктор Дуайт Т. Барнс (Half-Life) о конференции по тестированию Гейзенбаг 2017 Piter: «… Как твоё имя, солдат? Представляешь, твоё имя каким-то мистическим образом попало наверх списка продвинутой тренировки! И я попрошу тебя… а ну тащи своё тело вниз на тренировочную зону и отрапортуй полковнику Шарпу!… До Гейзенбаг 2017 Piter осталось три недели — все взводы уже оформили бейджики и вовсю полируют штиблеты. А тебя-то где носит? На конференции будут все: спецы по автоматическому и нагрузочному тестированию, тимлиды, разработчики. 17 докладов в 3 треках за один день — это тебе не мышку щелкать. Ветераны доложат о новых боевых приемах практического и хардкорного тестирования на реальных проектах.»

Давайте посмотрим, что будет ждать вас на месте.


Учитывая мнения участников Гейзенбаг 2016 Moscow, мы поддали жару и увеличили количество технически сложных, глубоких и необычных докладов. Для вашего удобства мы прикрутили к каждому докладу индикацию хардкорности, чтобы вы точно знали, где раздают РПГ, а где — мастер-класс по бою монтировкой. Для тех, кому до Питера не добраться, мы делаем онлайн-трансляцию с возможностью задавать «вопросы из зала» во время докладов и смотреть интервью со спикерами в перерывах между сессиями.

Итак, обзор докладов с группировкой по тематике:

В IT все происходит стремительно, и полгода-год — достаточный срок для кардинальных перемен. Это применимо и к автоматическому тестированию. Чтобы узнать, как изменился этот сегмент и отношение самих тестировщиков к своей профессии, поговорим с двумя опытнейшими специалистами в этой области — Игорем Хролом и Илари Хенриком Эгертером.

TLDR для нетерпеливых — в принципе можно закрывать статью

Так уж сложилось, что я принимал участие в создании / управлении / переговорах с большим количеством банков и платежных систем, которые предоставляют услуги онлайн-эквайринга в России. Это происходило на ряде мини-проектов с абсолютно разными провайдерами, но суть не в этом.

Я больше на работаю в этой сфере, но я хочу поделиться тремя аспектами онлайн платежей: i) бизнес и ситуация на рынке на 2016-2017 год (гайд для менеджера) ii) детали технической интеграции (CTO) iii) поведение клиента / дизайн / верстка платежной странички (дизайн, верстка, тестирование).

Весь этот опыт набран не сразу — примерно за 1.5 — 2 года активного ковыряния в этой сфере. Если вас не интересует бизнес опыт, а интересуют только материалы по дизайну — смело пропускайте первые спойлеры.

Добрый день, дорогие друзья.

Недавно, сидя на диване, я задумался о том, что хочется мне сделать своего паука, который что-то бы смог качать с веб сайтов. Но качать он должен был бы не простой загрузкой, а как настоящий милый добрый браузер (т.е. JavaScript чтобы исполнялся).

В моей голове всплыли такие интересные штуки, как Selenium, PhantomJS, Splash и всякое подобное. Все эти штуки были мне немного втягость. Вот какие причины я выявил:

• Дело в том, что я хотел бы писать на своем любимом питоне, потому что очень не люблю JavaScript, а это уже означает, что большая часть уже не работала бы (или пришлось их как-то склеивать, что тоже отстой).
• Еще эти безголовые браузеры обновляются как когда.
• Но вот Selenium очень милая штука, но я не нашел, как там отслеживать загрузку страниц, или хотя бы адекватного способа выдрать куку или задать её. Слышал, что многие любители селениума инжектят в страничку JavaScript, что для меня дико, потому что где-то полгода назад я делал сайтик, который отрывал любые JavaScript вызовы с сайта и потенциально мог определять моего паука. Мне бы очень не хотелось таких казусов. Хочется чтобы мой паук выглядел как браузер максимально точно.

Soft Mocks для Go!

Основная идея Soft Mocks для PHP — это переписывание кода «на лету» перед include(), чтобы можно было поменять реализацию любых методов, функций и констант во время исполнения. Поскольку go — компилируемый язык, то логично делать то же самое на этапе компиляции. В этой статье я расскажу по свой проект Soft Mocks for Go.

Функциональность

Возможности Soft Mocks for Go весьма ограничены — вы можете временно переопределить нужные вам функции и методы, а потом откатить свои правки. Также можно вызвать оригинальную функцию.

При использовании soft mocks, следующий код:

func main() {
    closeFunc := (*os.File).Close
    soft.Mock(closeFunc, func(f *os.File) error {
        fmt.Printf("File is going to be closed: %s\n", f.Name())
        res, _ := soft.CallOriginal(closeFunc, f)[0].(error)
        return res 
    })  
    fp, _ := os.Open("/dev/null")
    fmt.Printf("Hello, world: %v!\n", fp.Close())
}

Напечатает вот что:

File is going to be closed: /dev/null
Hello, world: <nil>!

Скачать библиотеку можно тут.