Тестировщики! Когда мы обсуждаем ручное тестирование, мы помогаем “тонуть кораблю”.
Это сильное заявление, но оно сформировано на основании долгих лет наблюдения за людьми, которые говорят на тему тестирования неосторожно. Опасность заключается в том, что людей, не специализирующихся на тестировании (и даже некоторых из тех, кто специализируется) вводит в заблуждение формулировка, что какой-то вид тестирования называется “ручным”, а какой-то - “автоматизированным”. Они не понимают, что разработка ПО и тестирование в рамках разработки можно сравнить с тонкой дизайнерской работой, а не фабричным выпуском продукции. Эти люди ослеплены скоростью и надежностью автоматизации, внедренной на производстве. Очень скоро они зацикливаются на идее, что тестирование может быть автоматизировано. Ручное тестирование - плохо, автоматизация - хорошо.
Впоследствии тестировщики, обладающие хорошими способностями к критическому мышлению, и навыками выявления проблем, испытывают сложности в поиске работы. Вместо них нанимают тестировщиков с весьма скромными навыками программирования и не внушающими доверия аналитическими способностями, которые месяцами пишут программы, суть которых сводится к нажатию кнопок компьютером. Целью становится отладка автоматизированных проверок, а не выявление проблем функционала, который важен для пользователя. Сложности, связанные с тем, чтобы “заставить” компьютер взаимодействовать с продуктом, отнимают время, которое могло быть потрачено на изучение продукта и наблюдение за тем, как ведет себя система. В результате имеем продукт, который мог быть тщательно или не очень протестирован, но в котором присутствуют дефекты, снижающие или даже напрочь уничтожающие его ценность.
Тема внедрения KPI в тестирование является актуальной уже много лет, этому вопросу посвящено немало исследований. В данной статье мы на примере реального проекта рассмотрим процесс внедрения KPI и методику оценки качества нашей работы.
Что такое KPI?
Итак, для начала обратимся к самому понятию KPI. KPI (Key Performance Indicator) – это показатель достижения успеха в определенной деятельности или в достижении определенных целей. Можно сказать, что KPI – это количественно измеримый индикатор фактически достигнутых результатов.
В нашем случае KPI на проекте – это показатель эффективности работы всей команды тестирования. Помимо термина KPI в статье будет использоваться термин «метрики», под которым мы будем понимать числовое значение для измерения этой эффективности.
Есть множество определений тестирования ПО, и множество взглядов на то, как должно выглядеть ответственное тестирование в нашей области. Ваш взгляд на роль тестировщика влияет на то, какие практики и артефакты вы считаете ценными.
Мое любимое определение тестирования дал Кем Кейнер: «Тестирование – это эмпирическое исследование, которое проводится с целью предоставить заинтересованным лицам информацию о продукте или сервисе, который тестировался».
В целом я рассматриваю тестирование, как часть бизнеса по сбору информации и ее передаче.
Более того, я считаю себя тестировщиком контекстной школы. У нее семь принципов. Вот моя интерпретация этих принципов и то, что они значат лично для меня:
«Ценность любой практики зависит от контекста» и «внутри контекста есть хорошие практики, но лучших не существует». Любая проблема тестирования уникальна. Наш подход к этой проблеме, следовательно, тоже уникален. Выяснить как можно больше и передать другим свое понимание проблемы жизненно необходимо для эффективного тестирования. Чем гибче инструмент или процесс, тем выше количество контекстов, в котором я могу его использовать.
Существует практически бесконечное множество антивирусов, их версий и комбинаций настроек. Ничто в мире не совершенно, поэтому иногда они могут перестараться и, например, заблокировать нужные файлы, в безопасности которых мы уверены. Подобные проблемы совместимости могут повлечь за собой заметный отток пользователей. Чтобы не допустить такого в конечном продукте, есть тестировщики. +
Антивирусы могут просто не давать корректно работать законно купленной игре из-за подозрений на вирусы или даже их реального присутствия (такое тоже случается). Например, из-за отсутствия контроля за безопасностью на ПК разработчика, вирус может попасть в игровой билд, который позже скачают пользователи. Шансы невелики, но подобная оплошность всегда очень сильно бьет по репутации продукта и компании в целом, может повлечь за собой утечку информации о пользователях. «Подозрительные» файлы в игре могут быть помещены в «карантин», а то и просто удалены. Антивирус может блокировать установку ПО или ограничить его доступ в интернет. Например, во время наших тестов COMODO, клиент игры удалялся самим антивирусом после его закрытия. То есть пользователь мог купить игру, спокойно запустить и даже поиграть, а потом просто не обнаружить ее у себя на ПК. Также сильно распространена проблема с обнаружением троянских программ в клиенте игры, установленном на абсолютно чистом ПК. В нашем случае это происходило на Qihoo 360 Total Security Essential с любыми параметрами защиты.
Каждому человеку хочется профессионально расти и развиваться. И область тестирования не исключение. Но в последнее время в тестировании складывается тенденция: если ты не автоматизатор, то и расти особо некуда. Это не так, и наша компания может это доказать!
«Лаборатория качества» ищет талантливого руководителя направления тестирования / аккаунт-менеджера (АМ). Что это значит? Если ты давно работаешь в тестировании, за твоими плечами опыт построения процессов, управления командой и налаживания связей с заказчиком, но ты хочешь большего, то мы готовы предложить тебе работу с разными проектами и множество нестандартных задач.
Какие задачи предполагаются?
Работа с заказчиками:
Налаживание контакта (заказчик не должен быть для вас простой аватаркой в скайпе; вы должны понять, что это за человек и как с ним работать).
Выявление потребностей (не только то, что написано в ТЗ, но и понимание текущих проблем; в идеале – взгляд на готовый продукт глазами заказчика).
Счастье клиентов (решать проблему не тогда, когда уже все горит, и все в огне, а увидеть первые искорки пламени и потушить их, не дожидаясь пожара).
Работа с командой:
Налаживание контактов (решать вопросы, которые не может решить тест-менеджер, и помочь тест-менеджеру научиться в будущем решать их).
Построение процессов (не останавливаться на достигнутом, а постоянно развивать команду и совершенствовать сами процессы работы, внедрять новшества и улучшения).
Счастье команды (наладить единую систему работы заказчик – команда тестирования, донести цели, сроки и задачи по проекту до команды).
Сейчас я готовлюсь к докладу на тему использования статистики тестирования, для которого важно собрать информацию от всех коллег. Для этих целей совместно с порталом организован опрос, в котором Вы сможете поделиться опытом сбора метрик тестирования и полезности анализа тестовых данных.
Просим поделиться своим опытом работы со статистикой тестирования в этом опросе (прохождение опроса займет не более 2 минут), из результатов которого мы сможем понять:
* какие метрики вы собираете и анализируете на постоянной основе
* какая статистика была собрана лишь однажды, но оказалась очень полезной для понимания сути происходящего
* какие графики вы строите на основании собранных данных
* какими инструментами пользуетесь для сбора, хранения и визуализации данных
Более подробную информацию об опросе Вы можете найти в этом топике на форуме.
Большая благодарность каждому, кто поделится примерами графиков, которые Вы создаете на основании собранных метрик тестирования. Ответ не должен быть максимально развернут или как-то аргументирован. Важно лишь узнать какую статистику собирают и используют на практике другие команды, и какие самые популярные виды графиков, построенные на основании собранных тест данных.
Результаты опроса будут также позже опубликованы на портале.
Возможно ли уменьшить или даже исключить человеческий фактор при тестировании релизов программного обеспечения? Коротко говоря, да. В этой статье говорится как.
Тестирование релиз-кандидатов отнимает слишком много времени.
Для большинства agile команд - это одна из самых сложных задач. С этим снова и снова сталкиваются мои клиенты и коллеги, которые работают над крупными интегрированными веб-сайтами и приложениями.
Но что, если вам не нужно было бы прибегать к помощи сотрудника для проверки определенной версии билда, чтобы минимизировать риски перед деплоем? Вместо него бот сообщал бы команде о готовности билда и кому-то оставалось бы только нажать кнопку деплоя?
Внедрение такой практики потребует расширения инфраструктуры и улучшения дисциплины. Возможно, это нереализуемо в вашей команде, но существуют компании, применяющие такой подход на регулярной основе.
«В одном IT-царстве жила-была себе команда тестировщиков: Алеша Попович, Добрыня Никитич, Любава и Гай Юлий. Были в том царстве и разработчики – Змей Горыныч, Илья Муромец и Тихон. Ну и, конечно же, присутствовал тим-менеджер Царь. Все они, такие разные, творили одно доброе дело и корпели над одним общим заданием: укрепить и облегчить жизнь мирскую и не пропустить ни одного Бага. Объединяло их общее желание и стремление, а посему и решили они – будем работать вместе».
Работа над проектом – это командный процесс. В любом коллективе значительную роль играет человеческий фактор. Оставлять его без внимания нельзя – напротив, всегда нужно предвидеть и учитывать возможные сложности. Все мы разные, у всех у нас свой склад характера, взгляд на вещи и отношение к работе. Очень важно найти правильный подход к каждому сотруднику для того, чтобы не просто объединить коллектив общим проектом, но и создать комфортные условия работы. Помочь в этом может соблюдение основных принципов, которые делают коллективный труд продуктивным и результативным:
внедрение в сознание всех сотрудников постулата «общее дело объединяет»;
установление дружелюбных, искренних и налаженных коллективных отношений;
достижение сплоченности как важного фактора эффективности;
понимание того, что любой человек в команде – важное звено;
налаживание взаимодействия каждого участника со всеми остальными;
учет мотивации каждого конкретного сотрудника в зависимости от его выявленных целей и желаний.
Так уж сложилось на практике, что самые главные инструменты для специалиста в сфере тестирования ПО - это его зоркий глаз, пытливый ум и интуиция. Тем не менее, жизнь тестировщика "и опасна, и трудна", и чтобы её сделать несколько комфортнее, существует ряд замечательных инструментов. И как раз о таких инструментах будет данный доклад.
