Первая часть статьи: Жми на кнопки, получишь результат

Миф № 3. Тестирование приложений на мобильных устройствах — это легко

Андрей (тестировщик, специализация — мобильные приложения):

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

Вот и тестируется приложение в условиях, приближенных к полевым:

— в офисе отыскиваются места с плохим приемом сигнала Wi-Fi, 3G, GPRS и т.п. (приложение не должно пугаться и ломаться при отсутствии Интернета);

— телефон поворачивается в пространстве (экран приложения должен, так сказать, повернуться к пользователю лицом);

— на телефон делаются входящие звонки и присылаются SMS (ничто не должно сбить с толку приложение);

— если в приложении есть карта, проверяется работа с GPS (странно было бы узнать, что находишься в Тихом океане);

— проверяются жесты («одно лишнее движение и все удалено» — такого не должно быть);

— проверяется встроенная клавиатура (набор текста в 700 символов для проверки полей ввода превращается в не самое легкое занятие на экране смартфона);

— аккумулятор доводится до истощения, а иногда просто вытаскивается;

— имитируется ситуация «телефон-в-кармане-а-блокировки-нет»;

— и другое экстремальное тестирование.

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

Миф № 4. Юзабилити тестирование — пустышка

Алексей (тестировщик, специализация — юзабилити и автоматизированное тестирование):

«Очень часто от заказчика слышишь, что тестирование юзабилити того не стоит. Любой заказчик может сам сесть, пройтись по сайту, покликать на формы и точно сказать, что удобно, а что — нет. Смысл кому-то платить ради этого, когда всё понятно и очевидно? Эх, если бы всё действительно было так просто, то не существовало бы огромного множества книг, статей, мнений, методик, средств, программ, таблиц, публикаций и форумов. Да и не было бы нужды в специалистах. К счастью, всё это есть, а специалисты востребованы. Результаты исследований NNGroup сообщают, при улучшении юзабилити каждый сайт мог бы увеличить свои продажи в среднем на 79%.

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

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

Не все так просто, если хочется результата».

Миф № 5. Автоматизированное тестирование? Нужно быть очень крутым программистом!

Алексей:

«Часто приходится слышать, что разработка автоматических тестов — это слишком сложно, нужно много кодировать, да и вообще проще вручную всё сделать… Да, разработка автотестов сложна и требует времени, не всегда целесообразна. Но вовсе необязательно знать десяток языков программирования и различных паттернов. Современные средства тестирования во многом сами помогают писать код для автотестов. Например, Selenium IDE в своей среде имеет экспериментальную возможность экспортировать записанный код в C#, Java и Python проекты. К тому же существуют конструкторы тестов и специальные нотации для них. Если совсем туго с программированием, то автотест можно написать в конструкторе JMeter (если забыть, что он для нагрузки, и использовать одного пользователя) или использовать автокликеры. Более совершенные методы — это использование MSC диаграмм.

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

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

Метки: интервью, тестирование

Мифы о тестировщиках, часть 1

Пожалуй, самый популярный вид статьи про тестировщиков в интернете — это вводные статьи «Кто такие тестировщики и что такое тестирование?». Сегодня хотелось бы поговорить о другом: любая крупная IT компания имеет отдел тестирования, но вокруг профессии вертится немало мифов, которые давно не соответствуют реальности или не соответствовали ей никогда. Сегодня у нас знакомство с реальными людьми и реальными проектами ЦВТ. Рассмотрим классические мифы с комментариями самих тестировщиков касательно того, что о них говорят.

Миф 1. Работа тестировщика — низкоквалифицированный труд

Николай (тестировщик, специализация — новостные порталы):

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

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

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

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

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

Миф 2. Да что там тестировать-то в телевизорах? Жмешь по кнопкам пульта и все!

Екатерина (тестировщик, специализация — Smart TV и Set top box):

«Smart TV — это такое относительно новое ТВ, к которому можно подключать интернет и устанавливать различные приложения, такие как Skype, игры, приложения для просмотра фильмов и т. д., также можно просматривать интересные сайты.

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

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

Так же проводим стресс-тестирование, к примеру, быстрое и долгое нажатие кнопок пульта, отключение интернета. Интересным и одновременно сложным моментом тестирования приложений под телевизоры является момент, когда в полностью протестированное приложение вносят изменения. Для того, что бы найти ответ на вопрос: «А что именно теперь тестировать?» нужно хорошо подумать, на работу какой части программы могло прямо или косвенно повлиять изменение.

Тестирование нового направления IT, такого как Smart TV, процесс интересный, ввиду своей новизны, но одновременно и сложный».

Продолжение: Мифы о тестировщиках, часть 2

Метки: интервью, тестирование