Мы продолжаем говорить со специалистами в области тестирования ПО, чтобы разобраться в вопросе «Что случилось с тестировщиками?»

В теме продолжают разбираться Слава Панкратов (case) и Саша Орлов (eagleson) — в славном боевом прошлом специалисты и руководители команд по тестированию.

Напомним, что мы провели небольшой опрос на сайте www.it4business.ru к которому присоединились наши коллеги из сообщества www.happy-pm.com и сообщество Стратоплан.Ру в Фесбуке из которого узнали, что половина опрошенных считает проблемой тестировщиков ПО непонимание целей и задач тестирования ПО.

Мы уже записали и опубликовали на Хабре небольшой подкаст с Глебом Рыбалко, который работает в тестировании более 6 лет.

Сегодня мы пригласили побеседовать на эту тему Алексея Лянгузова: 11 лет в тестировании, tech lead команды тестирования в Oracle, до этого работал в TogetherSoft и Borland, со-основатель сообщества тестировщиков Санкт-Петербурга.

Причины, которые, как нам показалось, могут пояснить, почему 50% опрошенных, солидарны в своей позиции: «Тестировщики не понимают целей и задач тестирования».

1. Мы не говорим, что и как мы делаем: недостаток визибилити и прозрачности нашей работы для других членов команды или соседних рабочих групп и отделов.
2. Мы не можем банально посчитать в цифрах эффективность наших решений и показать результаты нашей работы.
3. Мы не готовы честно провести анализ полученных результатов и сказать «Да, я провтыкал и ошибся».
4. Мы закапываемся в работу и забываем, что «пилу надо точить»: книги, вебинары, публикации, тренинги – всего этого в нашей отрасли сейчас навалом.
5. Мы не смотрим шире своих рабочих задач: многие из нас тестировщиков «стажировались» в группе разработки за последний год? Не барское дело, понятно.
6. Мы не делимся опытом и наработками с другими группами: аналитики, программисты, менеджеры, наконец! А у нас есть что сказать: тестировщики — это пользователь номер 1 любого программного продукта. И только они знают готов ли он к запуску или нет.

Конечно, есть еще одна, банальная причина того, что тестировщиков ПО не воспринимают, как специалистов, которые понимают, что и зачем они делают. Даже не причина, а источник проблем — мы сами.

Здравствуйте, уважаемые коллеги.

Одним из косвенных показателей качества кода считается code coverage — степень покрытия его тестами (как правило, имеются в виду модульные тесты). В большинстве случаев за coverage принимается соотношение количеству строк кода, в котрое попадает управление во время прогона тестов, к общему числу значимых (не являющихся комментарием, пустой строкой, или, например одной фигурной скобкой, обозначающей начало или конец блока) строк кода модуля.

Другим же условием хороших тестов является отсутствие сторонних эффектов (side effects), как например создание/удаление файлов, установка сетевых соединений, запись в порты и т.д.

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

Под катом вы найдете мое решение и, в качестве бонуса, еще одну ОПП-обертку к курлу, полностью покрытую тестами.

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

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

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

• Протестировать жизнеспособность самой идеи. Возможно, даже до того, как написана первая строка кода. Представте, сколько денег и бессонных ночей можно сэкономить, если заранее понять, что “гениальная” идея попросту никого не цепляет.
• “Разогреть” аудиторию, которая к моменту запуска уже начнет понимать, что за проблемы решает продукт.
• Привлечь первых пользователей. Они послужат фундаментом и, за счет эффекта “сарафанного радио”, ускорят распространение идеи.
• Испытать собственное приложение под нагрузкой. И избежать тем самым необходимости тестирования на первых покупателях. Публичное бета тестирование это честный способ предупредить людей о возможных ошибках и не вываливать весь ворох на ничего не подозревающих клиентов, которые думают, что покупают зрелый продукт. Береги честь смолоду!

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

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

Требование к инструменту организации всего процесса одно — он должен быть очень простым и легким в развертывании. Необходимость в подобных мероприятиях возникает в двух случаях. Либо когда продукт уже написан, вся команда находится в запарке и ни на что нет времени. Либо, когда, как указывалось ранее, продукт существует еще только в голове: есть задача понять нужен ли он вообще кому-нибудь.

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

При этом может показаться, что обучение — это сложно или дорого. Как бы не так! У тестировщиков есть масса возможностей учиться либо совсем недорого, либо вообще бесплатно! Сегодня я хочу поделиться новостями в мире обучения тестировщиков: надеюсь, каждый заинтересованный найдёт для себя что-то подходящее.

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

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

В одном из наших проектов, в который согласно записям redmine вложено около 400 часов работы нашего коллектива ситуация с тестами до распараллеливания выглядела так (пару дней назад):
151 scenarios (151 passed)
3997 steps (3997 passed)
17m49.257s


18 минут!!!

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

Но анализ загрузки процессора при прогоне показывает, что в работе участвует только лишь одно ядро независимо от того, сколько их всего есть. Как говорит пословица, лучше день потерять, а потом за пять минут долететь. Порыскав в гугле мы нашли гем parallel_tests. Теперь мы не с такой завистью будем смотреть на erlang группу, которые могут спокойно распараллелить свои тесты на кластер арендованных облачных машин в Selectel.