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

Оригинальная статья: «The Tough Life of a Games Tester».

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

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

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

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

Несколько раз начинал писать эту статью и бросал. Бросал потому, что тема, как мне кажется, несколько спорная. Изобретенный мною велосипед может кому-то показаться смешным и нелепым и вообще не совсем корректным. Тем не менее…

Вообще, мне кажется, что в области разработки электронных устройств существует как бы несколько мало пересекающихся миров. Например, существует разработка устройств на базе микроконтроллеров и параллельно существует разработка устройств на базе ПЛИС. Принципы работы этим микросхем принципиально отличаются и точно так же отличаются принципы и методы разработки, используемые языки программирования и отладки. Конечно, выбор элементной базы сильно зависит от поставленной задачи. Однако и так понятно, что эти миры, мир микроконтроллеров и мир ПЛИСов почти не пересекаются. Может быть на стыке технологий что-то есть?

Ещё недавно отгремели скандалы про МТС и Nestea и Ebay и Biglion, а разработчики всё не учатся на чужих ошибках. На этот раз у нас отличилась компания FRIMA с их сухими сливками.

Сегодня вечером, я открыл пачку сливок, и заметил там маленький круглешок с кодом. Вообще в подобных мероприятиях я обычно не участвую, но мой взгляд привлекла маленькая мелочь, а именно: «код выигрыша» выглядел подобным образом: FRIMA1234123. Как заметили многие читатели, код состоит по сути из семи десятичных цифр, то есть всего у нас 10 000 000 комбинаций.

Первое же, что мне пришло в голову — это залезть на сайт для ввода кода — frima.biz/lottery, где обнаружилось, что для проверки кода не используется никакая капча. Беглый осмотр проходящего AJAX-запроса для проверки показал, что в ответ приходит JSON-объект, в котором есть поле code, которое равно 0 если код существует.

UPD: Фото с конференции в FB и Вконтакте.

Весь прошлый год мы много писали на Хабр и рассказывали на конференциях о том, как у нас устроен процесс тестирования в Badoo, как мы выкатываем релизы два раза в день и о многом другом.

Этот год мы решили начать со своей небольшой мини конференции — LoveQA (ЛавQA), на которую хотели бы позвать специалистов, которым интересно послушать про автоматизацию тестирования, тестирование мобильных приложений, безопасность и многое другое. Нам тоже было бы интересно пообщаться с коллегами из других компаний, ответить на вопросы и узнать, как устроено тестирование у них.

Кроме презентаций, которые вы уже могли слышать на конференциях, мы подготовили для вас несколько совершенно новых докладов.
Мы хотим сделать небольшую уютную конференцию, и позвать примерно 120 человек.
В программе интересные доклады, кофебрейк и обед, экскурсия по офису Badoo.
Будем делать трансляцию и видеозапись докладов. Следите за новостями по хэштегу: #loveqa

LoveQA — Meet New People! Посидим, пообщаемся.

Когда: 15 февраля, суббота

Где: Офис компании Badoo, Цветной бульвар д.2, БЦ «Легенды Цветного», Москва

Полтора года назад, когда вышла книга «How Google Tests Software», я загорелась перевести ее на русский язык. Я давно восхищаюсь Уиттакером, я переводила его статьи, слушала мастер-классы и считаю его самым крутым чуваком в тестировании. Тогда я еще работала руководителем отдела тестирования в «Иннове», и компания поддержала мой проект.

С тех пор многое поменялось: я перестала заниматься тестированием, выпускала приложения для iOS, сейчас работаю продакт-менеджером большого веб-проекта. Уиттакер же еще в 2012 году ушел из Google в Microsoft, громко хлопнув дверью.

Несмотря на все это, весь прошлый год я работала над книгой: договаривалась с издательством, пыталась организовать группу добровольцев для перевода текста (не получилось), искала переводчика, помогала переводить и редактировала текст, работала с дизайнерами над макетом и обложкой, утверждала корректуру и сверстанные макеты. Проект занял намного больше сил и времени, чем я рассчитывала, но результатом я осталась довольна.

И вот, в январе издательство «Питер» выпустило книгу на русском языке с нашим переводом и дизайном:

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:

• На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
• Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
• Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
• За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

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

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

Осенью 2013 года я дважды на конференциях (сначала SECR, потом ConfeT&QA) рассказывал о том, как происходило развитие инструмента Selenium и каково текущее состояние дел. Предлагаю вашему вниманию запись, сделанную на второй из упомянутых конференций.

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

Наследство

Все началось с того, что первой трудностью, которая ожидала нас при разработке дизайна приложения, оказалась работа с так называемым legacy-дизайном. У нас на руках был продукт, в котором нужно было разобраться и понять, какие метафоры использовал предыдущий дизайнер.

На примере профиля видно, как было «до» и что стало «после».

С развитием и ростом популярности ОС Android количество и разнообразие устройств под её управлением неуклонно растёт. Из-за различий в архитектуре, предназначении и оптимизации скорость и стабильность работы исполняемого кода может значительно изменяться. Поэтому, для обеспечения стабильности и оптимизации работы приложений и ОС, особенно использующих особенности конкретной архитектуры, платформы, или кода, портированного с других платформ, стоит особо внимание уделить процессу отладки кода под Андроид. В этой статье пойдёт речь о ключевых моментах и особенностях работы с native-кодом под Android. Всем, кому интересен этот мануал, прошу под кат.

В ходе тестирования некоторых продуктов компании Positive Technologies возникла необходимость проведения быстрых стресс-тестов одного веб-сервиса. Эти тесты должны были быть простыми и быстрыми в разработке, нетребовательными к аппаратным ресурсам и одновременно с этим давать значительную нагрузку однотипными HTTP-запросами, а также предоставлять статистические данные для анализа системы под нагрузкой.

Для их реализации мы исследовали и опробовали некоторое количество инструментов, среди которых были Apache JMeter и написанный нами на Python скрипт LogSniper, который выполнял реплей заранее подготовленных серверных логов с HTTP-запросами на цель.

Привет! Меня зовут Денис Чернилевский. В Яндексе я руковожу группой автоматизации тестирования системы медийной рекламы. В процессе своей работы в Яндексе и на предыдущих местах мне довелось руководить командами 10+ человек, налаживать процессы и придумывать подходы автоматизации тестирования различных систем. И так уж вышло, что в каждом из этих проектов приходилось задумываться о подготовке тестовых данных. По итогам довольно долгой рефлексии был придуман подход, который позволяет в общем виде решить эту задачу и применять его в разных проектах. Помимо того, что я буду говорить о нём на Тестовой среде, решил рассказать подробности и здесь.

Кстати, если вы не можете приехать на наше мерпориятие для тестировщиков, можно будет посмотреть трансляцию, которая начнётся завтра, в субботу, 30 ноября в 11:00.



Эта статья основана на опыте решения задачи подготовки сложных наборов синтетических тестовых данных в процессе автоматизации тестирования системы медийной рекламы Яндекса. Конечно, мы не первые, кто сталкивается с такой задачей, поэтому для начала проанализировали существующие подходы и решения. В результате решением стала библиотека ObjectBuilders (на Python), которую можно применить в проектах, где необходимо создавать иерархически связанные наборы данных. Она позволяет задавать их связи, параметры и свойства. А также дает несколько бонусов в качестве побочных эффектов.

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

Трудно одним заголовком сформулировать, чем же является Galen Framework. Все началось с того, что у меня возникла потребность тестировать сайты в различных браузерах и проверять: не поехала ли разметка, например, в том же Internet Explore или Chrome. Затем возникла мода на Responsive Web-Design, и пришлось вручную менять ширину браузера и проверять, как отображаются сайты. И, хотя все это время были WebDriver и Selenium Grid под рукой, так и не получалось нормально тестировать верстку сайта в Java коде. Одна из идей была: делать скриншоты в разных браузерах в Selenium Grid и затем собирать их все в один большой отчет, по которому один из тестировщиков обязан пробежаться глазами и, в случае обнаружения несоответствий, рапортовать о дефекте. К сожалению, вся эта затея долго не продержалась. Тестировщикам стало лень листать огромный отчет и сравнивать скриншоты, и они все равно пропускали мелкие дефекты. А затем пошли требования внедрения во всех сайтах Responsive Design. И вот тут появился Galen Framework. Решение оказалось простым: проверять размер и расположение элементов относительно друг друга. Для этого понадобился специальный язык Galen Specs, который было бы легко читать и понимать.



Если коротко, Galen Framework — это специальный язык и инструмент для тестирования отображения сайта в браузере. Он позволяет тестировать адаптивный дизайн, а также проводить кросс-браузерное тестирование сайта.

Графен — тонкий, легкий и непроницаемый для всего кроме мельчайших молекул материал (он, например, является отличным водяным фильтром). Презервативы же, хотя и являются отличными барьером для болезней передающихся половым путем — не являются ни тонкими ни легкими, а это уменьшает чувствительность, из-за чего многие их не используют. Фонд Билла и Мелинды Гейтс считает, что мир станет лучше, если людям будет нравиться пользоваться презервативами. Поэтому они решили профинансировать разработку тонких, повышающих удовольствие графеновых кондомов.

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

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

Некоторое время назад мне пришлось очень плотно поучаствовать в приемо-сдаточных испытаниях самолета. Эти испытания были основной частью процесса передачи свежеизготовленного, самого (по моему мнению) технически продвинутого на настоящий момент времени бизнес-джета от производителя заказчику. Казалось бы, причем здесь тестирование, разработка, да и вообще тематика Хабра? Желающие узнать это могут перевернуть страницу и прочитать довольно много текста, причем вообще без картинок.

Я хочу сегодня вспомнить о том, как нагрузочное тестирование в Яндексе появилось, развивалось и устроено сейчас.



Кстати, если вам понравится этот рассказ, приходите на Тестовую среду в нашем питерском офисе 30 ноября (зарегистрироваться), – там я расскажу больше об игровых механиках в тестировании и с удовольствием вживую с вами поговорю. Итак.

В 2005-2006 годах часть не поисковой инфраструктуры Яндекса стала испытывать нагрузки растущего как на дрожжах Рунета. Появилась необходимость тестировать производительность смежных с поиском сервисов, в первую очередь — баннерную крутилку. Тимур Хайруллин, на тот момент руководивший нагрузочным тестированием, озадачился поиском подходящего инструмента.

Чем крупнее и сложнее становится сервис, тем больше времени приходится уделять тестированию. Поэтому желание автоматизировать и формализовать этот процесс вполне законно.

Чаще всего для автоматизации тестирования веб-сервисов применяется Selenium WebDriver. Как правило, с его помощью пишут функциональные тесты. Но, как всем хорошо известно, функциональные тесты не могут решить задачу тестирования верстки сервиса, что требует проведения дополнительных ручных, зачастую кроссбраузерных, проверок. Как тест может оценить корректность верстки? Чтобы обнаружить регрессионные ошибки верстки, тесту потребуется некоторый эталон, в качестве которого может выступать изображение корректной верстки, взятой, например, с продакшен-версии сервиса. Этот подход носит название screenshot-based testing. Подход этот применяется достаточно редко, и чаще всего верстку все же тестируют вручную. Причина этому – ряд достаточно строгих требований к сервису, к среде выполнения тестов и к самим тестам.

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

На примере тестирования колдунщиков в поиске мы расскажем, какими особенностями должен обладать тестируемый сервис, какие проблемы возникают у нас при использовании screenshot-based testing, и как мы их решаем.

Хочу поделиться опытом, о том, как создавать хорошие отчёты об автотестах и одновременно пригласить вас на первое мероприятие Яндекса специально про тестирование.

Сначала пару слов о событии. 30 ноября в Санкт-Петербурге мы проведём Тестовую среду — своё первое мероприятие специально для тестировщиков. Там мы расскажем, как у нас устроено тестирование, что мы сделали для его автоматизации, как работаем с ошибками, данными и графиками и о многом другом. Участие бесплатное, но мест всего 100, поэтому надо успеть зарегистрироваться.

Тестовая среда для нас в первую очередь — площадка для общения. Мы хотим не только рассказать о себе, но и поговорить с участниками о том, как работают они, обменяться знаниями, ответить на какие-то вопросы. Думаем, общих тем будет много, но чтобы вы начали обдумывать их уже сейчас, мы начинаем серию публикаций о тестировании в Яндексе.

Автоматизации тестирования на Тестовой среде будет посвящено несколько докладов, в том числе мой. Итак, начну.

Бывают unit-тесты, а бывают высокоуровневые. И когда их количество начинает расти, анализ результатов запусков становится проблемой. Скажите честно, кто из вас не думал сделать свой отчет?

Это, пожалуй, самый болезненный отчет об ошибке, который я когда-либо читал. Он красочно описывает шаги, которые привели к потере 465 миллионов долларов компанией Knight Capital в связи с ошибкой программного обеспечения, проявившейся в прошлом году и обанкротившей компанию.

В этом отчете есть все характеристики технического долга в огромной, лишенной поддержки и запущенной базе кода (ошибка произошла из-за исполнения кода, который не использовали почти 9 лет) и ужасная и грустная история взаимодействия между разработчиками ПО и ИТ-профессионалами.