Пара вводных слов
Всем доброго времени суток, меня зовут Туманов Дима. Сейчас я работаю в компании Rambler&Co и отвечаю за тестирование на проектах Афиши. В рамках данной статьи я развею несколько мифов об IT и тестировании в частности. Кроме того, приведу примеры из жизни как “не зная ничего” стать Junior QA Engineer в крупной компании.

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

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

Стек технологий был изначально выбран мелкомягкий, а в качестве хранилища данных использовался SQL Server 2014 Express. Одним из первых тасков, которые мне поручили — это поисследовать возможность ускорения автотестов.

Мы выложили парсер OOXML форматов на Ruby в open-source. Он доступен на GitHub'е и RubyGems.org, бесплатен и распространяется под лицензией AGPLv3. Всё как у модненьких Ruby-разработчиков.

17 июня в Нижнем Новгороде Mail.Ru Group снова проведет QA MeetUp. Событие будет интересно всем, кто работает в сфере тестирования. Приглашаем вас пообщаться с профессионалами из разных IT-компаний, передать свой опыт и получить новый. В программе встречи пять докладов.

Какие инструменты облачного тестинга используют в Яндексе? Как устроено тестирование в Badoo? Что представляет собой система автоматизированного frontend-тестирования в Wrike?



Пару недель назад наш Wrike Tech club собрал около 150 специалистов по тестированию, чтобы обсудить в питерском офисе компании насущные, вечные и, на первый взгляд, почти неразрешимые проблемы QA в больших (и не очень) проектах. Как и обещали, делимся видео и презентациями со встречи.

Часть 1

Сегодня поговорим о создании UI smoke-теста для сайта с использованием фреймворков Cucumber и Selenide. Статья рассчитана на junior, который совсем ничего не знает про данные фреймворки. Опытный junior найдет во второй части интересные моменты, до которых я доходил пару месяцев.
Статья состоит из двух частей:

• в первой описано создание нашего теста простейшим способом – чтобы запускалось и при этом никаких сложных вещей из фреймворков не использовалось. Только создадим описание фичи (.feature файл) и класс описания степов с использованием Selenide.
• во второй части в тот же самый тест добавим всякие интересные штуки от Selenide, посмотрим, как создавать красивые отчеты, которые будут содержать текст фич (мн.ч от слова «фича»).

Фреймворки

Selenide – фреймворк (а точнее библиотека), обертывающий Selenium. Чем он отличается, прекрасно описано автором, Андреем Солнцевым. Главное отличие – Selenide позволяет сократить кучу строчек кода при написании UI тестов, что является одной из главных задач при создании тестов/написании кода, ибо Вы должны заботиться о том тестере, который придет после Вас и должен будет разбирать Ваше творение.

Cucumber – это фреймворк, реализующий подход BDD/TDD.

Сижу я в комнате для раздумий и читаю «Вестник МЧС» от 2007 года, потому что баллончик освежителя уже надоел, а на обложке издания есть громкая фраза «Туристы должны быть защищены». А у меня как раз на носу турпоход на майских праздниках, грех не ознакомиться с материалом. В материале рассказано, что Александр Чуприян, в бытность свою замминистра, поднял актуальный вопрос о регулировании спасательных действий и глобальном учёте тургрупп, маршрутов следования и прочих данных для оперативного спасения туристов в случае внезапного ЧС. И деятельность такая на тот момент в некоторых регионах уже ведётся. И готовить будут многолетний план по распространению сей деятельности на все регионы.



«Туристы должны знать, что они защищены!» — поставил Александр Чуприян задачу коллегам по службе. Это было в далёком 2007 году.

Разрабатывая и тестируя сайт, зачастую замечаешь не все js-ошибки. Это происходит по ряду причин:

• отсутствие консоли в некоторых мобильных и планшетных браузерах;
• открытая консоль мешает при тестировании, перекрывая видимую часть страницы;
• консоль открывают когда страница уже загрузилась и ошибки, возникающие при загрузке, теряются (Firebug в Firefox, Internet Explorer);
• при разработке часто отключают логирование ошибок в системах аналитики, чтобы не было лишнего «шума» при анализе ошибок;
• и прочее.

Список составили разработчики Java, C++ и JavaScript библиотеки libphonenumber для парсинга, форматирования и проверки телефонных номеров

Телефонные номера используются повсеместно и довольно давно. Поэтому очень удивительно, сколько заблуждений остаётся у программистов относительно них.

1. Телефонные номера, действительные сейчас, останутся действительными всегда. Телефонные номера определённого типа (например, мобильные), никогда не сменят тип.

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

Подсказка. Не сохраняйте свойства телефонного номера, такие как валидность или тип. Проверяйте эту информацию с помощью библиотеки, когда необходимо.

Компания Badoo одной из первых перешла на PHP 7 — мы совсем недавно писали об этом. В той статье мы говорили об изменениях в инфраструктуре тестирования и обещали подробнее рассказать о разработанной нами замене для расширения runkit под названием SoftMocks.

SoftMocks

Идея у SoftMocks очень простая и отражена в названии: нужно реализовать аналог для runkit, максимально совместимый с ним по семантике, на чистом PHP. Soft здесь подчеркивает то, что он реализован не внутри ядра PHP, а поверх него, без использования Zend API и прочего hardcore. Тот факт, что он на чистом PHP, означает, что мы можем спокойно переходить на новую версию PHP и просто добавлять поддержку нового синтаксиса, а не переписывать расширения с новой версией Zend API и ловить миллионы багов из-за различных тонкостей в семантике.

Сегодня у многих IT-компаний есть собственные bounty-программы (или программы по поиску уязвимостей). Badoo — в их числе.

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

Со времени старта нашей bounty-программы прошло три года. Нам до сих пор продолжают присылать сообщения участники со всего мира.

Мы хотим усилить интерес к ней, в том числе со стороны иностранных исследователей. Поэтому мы, во-первых, открыли страничку с нашей программой на крупнейшем портале исследователей hackerone.com, а во-вторых — увеличили суммы вознаграждений за найденные уязвимости! Теперь сумма вознаграждения, в зависимости от категории, начинается от £100 и может достигать £1000, сумма супер-премии составляет £2000 (а это более 200 000 рублей по текущему курсу!) и даже больше, если обнаруженная уязвимость представляет реальную угрозу для наших пользователей.

Привет!

Пару месяцев назад я писал пост, о том как научить webpack для spa. 
С того момента инструмент шагнул вперед и оброс дополнительным количеством плагинов, а так же примерами конфигураций.

В этой статье хочу поделиться опытом смешивания гремучей смеси webpack + jasmine + chai + karma.

На сегодняшний день видеоконференцсвязью (ВКС) никого не удивишь. Бесплатные видеозвонки доступны практически всем. Даже сервисы для обмена текстовыми сообщениями постепенно получили функционал сначала звонка, а затем и видеочата. Существуют также бесплатные приложения с базовым функционалом для объединения нескольких участников в видеоконференцию. Но есть ряд минусов подобного общения: качество связи иногда оставляет желать лучшего, сервис находится в облаке и, следовательно, конфиденциальность и бесперебойность переговоров не гарантирована, функционал минимален и не позволяет решить большинство поставленных задач.
Для того, чтобы обеспечить качественную коммуникацию и решение бизнес-процессов, организации используют профессиональные решения ВКС.

Перевод статьи Vitalij Mik Clean Code Architecture and Test Driven Development in PHP

Понятие «архитектура чистого кода» (Clean Code Architecture) ввел Роберт Мартин в блоге 8light. Смысл понятия в том, чтобы создавать архитектуру, которая не зависела бы от внешнего воздействия. Ваша бизнес-логика не должна быть объединена с фреймворком, базой данных или самим вебом. Подобная независимость даёт ряд преимуществ. К примеру, при разработке вы сможете откладывать какие-то технические решения, например выбор фреймворка, движка/поставщика БД. Также вы сможете легко переключаться между разными реализациями и сравнивать их. Но самое важное преимущество такого подхода — ваши тесты будут выполняться быстрее.

Просто подумайте об этом. Вы действительно хотите пройти роутинг, подгрузить абстрактный уровень базы данных или какое-нибудь ORM-колдовство? Или просто выполнить какой-то код, чтобы проверить (assert) те или иные результаты?

2015 год выдался богатым на нововведения, связанные с улучшениями веб-платформы. Аксель Рошмайер рассматривает 6 технологий, которые ему кажутся наиболее интересными:

1. Electron;
2. React Native;
3. Прогрессивные веб-приложения;
4. Visual Studio Code;
5. Rollup;
6. WebAssembly.

Программы поиска уязвимостей всегда привлекают немало внимания со стороны хакеров и специалистов по безопасности. Ведь это легальный способ неплохо зарабатывать одними только поисками багов (при условии, что есть хороший опыт и голова на плечах). На днях нам представилась возможность взять интервью у багхантера Ивана reactors08 Григорова. Он лидер нашей программы Bug Bounty и занимает 11-е место в общем рейтинге платформы HackerOne.

Как начать искать баги? Может ли это быть единственным источником дохода? В каких Bug Bounty участвовать? Сколько зарабатывают багхантеры? И почему поиском уязвимостей особенно выгодно заниматься в кризис? Ответы на эти и другие вопросы читайте в нашем интервью.

Предисловие

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

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

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

P.S.: И последнее — данный текст бы никогда не сформировался, если бы не полезные лекции Алексея Баранцева и Натальи Руколь, а также пропасть информации, написанная добрыми людьми за последние годы по данной теме.

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

Новый год начался для нас с возвращения на Хабр. Итак, daddy’s home. Мы решили вернуть наш блог к жизни, чтобы делиться новостями компании, технологическими секретами, жизненным опытом и общаться c вами, тем более и рассказать нам есть о чем.

Новую страницу нашего блога мы начнем, пожалуй, с небольшого эксперимента. Мы решили развернуть наш офисный пакет ONLYOFFICE на мини-серверах. В качестве непривычной тестовой среды для нашего ПО мы использовали три разных (по стоимости и, соответственно, мощности процессора) машины Intel NUC.

Что из этого всего вышло — читайте далее.

Не так давно мне довелось выступать на конференции FFConf с докладом «Вам следует использовать <впишите нужную библиотеку/фреймворк>, это самое лучшее!». И основные мысли я решил изложить в публикации, в надежде, что это спровоцирует в профессиональной среде более широкую дискуссию о «стоимости» современных фреймворков на мобильных устройствах.

Для желающих обратиться к оригиналу моего выступления вот видео:



и слайды презентации: speakerdeck.com/paullewis/framework-here-its-the-bestestest.

Именно таким вопросом задалась команда Почты Mail.Ru перед написанием очередного сервиса. Основная цель такого выбора — высокая эффективность процесса разработки в рамках выбранного языка/технологии. Что влияет на этот показатель?

• Производительность;
• Наличие средств отладки и профилирования;
• Большое сообщество, позволяющее быстро найти ответы на вопросы;
• Наличие стабильных библиотек и модулей, необходимых для разработки веб-приложений;
• Количество разработчиков на рынке;
• Возможность разработки в современных IDE;
• Порог вхождения в язык.

Кроме этого, разработчики приветствовали немногословность и выразительность языка. Лаконичность, безусловно, так же влияет на эффективность разработки, как отсутствие килограммовых гирь на вероятность успеха марафонца.