Тестирование нуждается в постоянном улучшении, как и любой другой процесс. Возникал ли у вас вопрос “как улучшать”? Можно прибегнуть к конкретной методике, можно использовать отдельные принципы популярных практик... Но, прежде чем приступить к действию, можно прислушаться к специалистам, которые уже внедряют некоторые из них.
Ниже представлены записи докладов с конференции COMAQA Spring на тему улучшения процессов тестирования:
Срыв сроков выпуска ПО – часто возникающая проблема, от которой не застрахован ни один проект. Причины такого явления кроются в разнообразных непредвиденных ситуациях, связанных с деятельностью заказчиков, разработчиков или тестировщиков. К счастью, эту проблему, как и большинство других, можно предотвратить.
В данной статье я рассмотрю вопрос выделения достаточного количества времени на проведения тестов. Практика показывает, что именно на этом шаге создания продукта время зачастую экономится («там всего-то протестировать на полчасика – и все»). Для того, чтобы понять, почему нам важно выделить достаточно времени для проведения тестов, подробно рассмотрим, какие именно факторы могут привести к срыву сроков.
Что такое «достаточность времени» и как ее рассчитать?
1. Определение Итак, что подразумевается под «достаточностью времени», и чем «достаточное время» отличается от «номинального»? «Номинальное время» затрачивается на работу в идеальных условиях (без непредвиденных ситуаций). Но бывает ли так на практике?
Например, для установки компьютерной игры или программы в прилагаемой спецификации ПО приводятся номинальные и рекомендуемые (достаточные) характеристики ПК. Не следует ожидать от продукта высокой производительности, если технические параметры компьютера будут близки к номинальным требованиям. Именно поэтому рекомендуемые (достаточные) параметры для установки ПО всегда превышают номинальные.
В нашем же случае «достаточное время» – это время, которого гарантированно хватает для завершения поставленных задач даже в случае возникновения непредвиденных проблем. В этой статье я приведу реальные примеры из моей практики работы на двух проектах. Один из них обозначу «Отелем», а другой – «Утилитой».
Взаимоотношения разработчиков и тестировщиков служат неистощимым источником возникновения шуток и анекдотов, что свидетельствует о наличии целого ряда конфликтных ситуаций.
Корни проблемы кроются в различии основных функций этих специалистов: тестировщики вынуждены искать ошибки, погрешности и недочеты в программах, на создание которых разработчики потратили немало сил. К сожалению, такое положение дел не всегда способствует тесному сотрудничеству.
Хотя каждый из нас по-своему уникален как человек и как специалист, можно выделить ряд характерных особенностей взаимодействия сотрудников в ходе рабочего процесса. Некоторые из них способны привести к серьезным неприятностям, а потому наша задача – найти способы разумного решения существующих проблем и не допустить возникновения новых.
Типы взаимоотношений
Для понимания сути проблемы приведем классификацию взаимоотношений в рабочей группе, предложенную американскими исследователями Блейком и Myтoном и учитывающую комбинацию двух основных параметров – взаимоотношения сотрудников и их отношения к рабочему процессу.
Выделим 5 основных типов: 1) невмешательство – низкий уровень заботы как о проекте, так и о коллегах (каждый сам за себя, сотрудники не заинтересованы в совместном конечном результате и не чувствуют себя членами рабочего коллектива); 2) теплая компания – комфортные отношения в коллективе, не направленные на достижение конкретных и устойчивых результатов работы; 3) задача – внимание каждого полностью сосредоточено на решении производственных задач, человеческий фактор недооценивается или просто игнорируется; 4) золотая середина – сотрудники в своей деятельности стремятся оптимально сочетать интересы дела и коллег; 5) команда – наиболее предпочтительный тип взаимоотношений в рабочей группе. Максимально учитывает интересы производства и коллектива, объединяет деловитость и человечность на всех уровнях отношений.
Случалось ли с вами такое, что ваша пачка тестов стабильна, всегда проходит, и каждый прогон приятного зеленого цвета?
Чувствуете ли вы, что это неплохой фильтр, который изловит практически любой внедренный баг?
Как вы будете себя чувствовать, когда узнаете, что был найден баг, а ваш зелененький прогон будет улыбаться вам с экрана? Не очень?
"Почему тесты этого не уловили?" Хм.
Причина
Потому, что вся наша автоматизация делает то и только то, что мы приказываем ей делать. Наши тесты не замечают изменений в приложении, пока мы не скажем им их заметить.
Я мог уже об этом писать где-то: код – это органическая структура.
Возможно, странно говорить так о коде. Но мы говорим о неодушевленных предметах, что у них есть личность – так и код впитывает природу и характер человека, который его пишет.
И если разработчиков у вас достаточно много, вы увидите вещи, которые не происходят, как правило, в небольших командах.
О многом просто забывают. Или в продукт вносятся изменения, а люди еще не в курсе, что автоматизация эти изменения не учитывает.
После того, как ваши автотесты написаны и дают вам достойную доверия обратную связь, как вы узнаете, что настала пора менять и пополнять их?
И прежде чем люди начнут бегать и кричать "В хороших Agile-командах люди общаются друг с другом, и такие вещи просто невозможны" – даже если с коммуникациями у людей все в порядке, шанс, что что-то произойдет, а вы об этом не узнаете, и автоматизация это не покроет, есть всегда.
Это как контраварийное вождение – обычно вам оно не требуется, но неплохо уметь это делать на случай, если другие водители ведут себя на дороге, как уроды. Надеюсь, мысль понятна?
Мы, тестировщики и автоматизаторы, пытаемся сохранить баланс между тестированием и чересчур обширной автоматизацией. Или мало делая. Или и то, и другое разом.
Если мы думаем, что у нас вполне приличный набор тестов, мы можем начать думать, что он не нуждается в добавлениях. Он полон, и мы, возможно, не стремимся к 100% покрытию, нам вполне достаточно 70-80%, и их мы получаем.
И даже в этом случае что-нибудь да просочится через нашу защиту.
Это происходит, как правило, редко, но если какой-нибудь "не тот" баг прокрадется в релиз, это станет проблемой для компании.
Пытаться решить вопрос "как протестировать добавленное" довольно сложно. Зато вполне легко решить вопрос "как определить, когда что-то добавлено".
Все мы не раз сталкивались с понятием целевой аудитории. В последнее время это словосочетание все чаще используется в качестве одной из характеристик организации, товара или услуги. И действительно, в любом бизнесе действует простая и очевидная схема: для любого продукта есть свой пользователь. Несомненно, это правило затрагивает и ПО. В этой статье я предлагаю обсудить довольно сложный вопрос: чем знание целевой аудитории поможет при оценке степени несоответствия заложенных ожиданий реальным по отношению к тестируемому продукту?
Прежде всего разберемся, что же такое целевая аудитория (в дальнейшем – ЦА). В соответствии с определением из Британского бизнес-словаря, целевая аудитория (англ. target audience) – это группа людей или сегмент рынка, для которого предназначен продукт, услуга, веб-сайт, реклама, телевизионная или радио программа и т. д.
Если не вникать в суть вопроса, то может показаться, что ЦА – это некая общность потенциальных потребителей или покупателей продукта. На практике все обстоит далеко не так просто, и подтверждение тому – огромное количество несостоявшихся проектов, владельцы которых при запуске ожидали увидеть ажиотажный спрос на свое детище. Причиной провала во многих случаях являлась в том числе не соответствующая реальности оценка ЦА.
Для чего нам нужно знать целевую аудиторию проекта?
Знать и понимать ЦА важно на каждом этапе разработки программы. Может ли разработчик приложения-мессенджера, к примеру, не учесть, что продуктом могут воспользоваться слабовидящие пользователи, для которых нужны специальные возможности? Запросто!
При проектировании сайта важно не только добиться привлекательного оформления страниц, но и обеспечить пользователю простое и понятное выполнение пользовательских действий (например, сделать процесс поиска товара легким и очевидным). На этом этапе тщательное изучение ЦА является обязательным. Оно необходимо для того, чтобы понять, почему пользователь не выполняет ожидаемых от него действий и не реализует цель нахождения на сайте (или использования продукта).
Нефтепереработка все сильнее адаптируется к цифровому веку, и это приводит к большей зависимости от ПО, автоматизированных трудовых процессов и облачных технологий. Парное тестирование становится обычной практикой с целью убедиться в качестве ПО, поддерживающего нефтепереработку – например, цифровой симулятор резервуаров, геологические инструментв, и так далее. Также оно помогает комбинировать знания, использовать различные перспективы, и улучшает коммуникацию, делая процесс тестирования более эффективным. Эта статья описывает некоторые преимущества, которых можно достичь при помощи парного тестирования ПО нефтеперерабатывающей индустрии, и в большинстве случаев это применимо к другим областям и приложениям.
2. Преимущества, связанные с дележкой знаниями.
Одна из основных областей, в которых парное тестирование приносит большую пользу – это дележка знаниями. Ниже перечислены достоинства парного тестирования для нефтеперерабатывающей отрасли:
В одну команду были объединены тестировщики с разным техническим опытом (технические эксперты по нефти, математики, компьютерные инженеры, и т. д.), которые, следовательно, смогли предоставить спектр перспектив и подходов к тестированию.
В одну команду были объединены тестировщики с разным уровнем опыта. Сочетание новых инновационных взглядов со зрелыми опытными умами может дать отличные результаты в плане качества поддержки новой функциональности.
Более тесное взаимодействие с разработчиками и командами портфолио и менеджмента. Два тестировщика создают больше каналов коммуникации, чем один, позволяя знаниям эффективнее распространяться между командами и повышая эффективность разработки.
Сочетание различных практик тестирования. Процесс тестирования может быть разделен между двумя тестировщиками различными способами: одновременное тестирование одной и той же фичи, одновременное тестирование разных фич, тестирование частей одной и той же фичи и ее зависимостей, и т. д. Парное тестирование – это отличная возможность комбинировать различные практики и подходы к тестированию.
Несколько месяцев назад мой коллега Макс прислал мне заинтересовавшую его ссылку со списком когнитивных искажений человека. Читая описания разнообразных ловушек мышления, я понимала, что вижу проявления многих из них как в повседневной жизни, так и на работе. Изучив вопрос, решила поделиться с коллегами: впервые статья вышла на английском языке в журнале компании Logeek Magazine, сейчас же я хочу поделиться с более широкой аудиторией, разместив на DOU.
«You should work to reduce your biases, but to say you have none is a sign that you have many» — Nate Silver
Существует прямая связь восприятия человека с образом его мыслей, мнением относительно различных ситуаций. Не всегда мышление и мнения человека объективны — в них могут наблюдаться систематические ошибки и отклонения. При возникновении подобных отклонений видимого от реального, говорят о ловушках мышления или же, научным языком, о когнитивных искажениях.
Ловушками мышления называют стандартные, шаблонные отклонения в мышлении человека, основывающиеся на деформированных убеждениях.
Люди живут в собственной реальности, основанной на их восприятии окружающей действительности. Именно на этой реальности базируется их поведение и взаимоотношения с окружающими. Часто причиной нелогичного поведения, неверных выводов и нелогичных интерпретаций являются именно присущие людям ловушки мышления.
Программное обеспечение неизменно создается людьми, тестируется людьми и, в большинстве случаев, используется людьми. И каждый человек в этой цепочке подвержен собственным когнитивным искажениям.
Многие современные компании, разрабатывающие ПО, настолько завалены проблемами качества, что это мешает им развивать бизнес. Они демонстрируют весь спектр классических симптомов перегруженных организаций – нехватку понимания проблем, нехватку понимания, что происходит, и ряд характерных поведенческих шаблонов и ощущений. Менеджмент, возможно, не связывает подобную перегрузку и проблемы качества, проявляющиеся в крупных, сложных системах. Если это так, то все, что они делают, только вредит делу. Чтобы исцелить или предотвратить подобную болезнь, менеджменту нужно понимать системную динамику качества.
Симптомы перегрузки, связанные с плохим качеством
В работе консультанта нас часто просят спасти проекты по разработке ПО, которые каким-то образом вышли из-под контроля. Организации внезапно погрузились в постоянное состояние кризиса, а менеджменту, кажется, не удается найти первопричину всех этих симптомов. Очень часто центральная причина – это перегрузка из-за нехватки качества продукта, и нехватка качества продукта из-за перегрузки.
Наша первоначальная задача, как консультантов – изучение симптомов. Мы классифицируем симптомы перегрузки на четыре разные категории – непонимание существования проблемы, непонимание, что происходит, характерные поведенческие шаблоны и чувства. Прежде чем описать динамику этих симптомов, давайте посмотрим на некоторые из них на примере компании АБВ.
Как часто мы сталкиваемся с проблемой, что проведя аудит процесса тестирования наши рекомендации носят достаточно общий характер. А еще хуже, когда мы внедряем новые решения, подходы, но они не дают нужного нам результата, что приводит к появлению недоверия со стороны руководства к руководителям отделов тестирования или аудиторам.
Очень часто основной причиной таких проблем является неправильное понимание менеджером поставленной задачи, и как следствие, неправильный выбор подхода для проведения аудита.
Для начала мы немного опустимся в основы процессов и попробуем понять, как должен существовать любой процесс.
Любой процесс, неважно, разработка это или тестирование, сопровождение, управление качеством и т.д., всегда должен быть цикличен. Существуют 4 основных подхода к работе с процессами, и самый популярный из них, это уже общепризнанный цикл Демминга. Именно на его основе строится работа процесса и все другие методологии, такие как DMAIC (6 сигм), IDEAL, EFQM, которые всегда говорят нам о том, что нужно не только требовать выполнение процесса, но и постоянно его анализировать и непрерывно совершенствовать. Эти модели позволяют нам понять, как мы должны работать с процессом, и самое главное, мы должны всегда видеть проблемы нашего процесса и стараться их решить.
Говоря о тестировании, существуют 2 основополагающих подхода к совершенствованию процесса тестирования, это MBI и ABI.
MBI или Model Based Improvement — подход к совершенствованию процесса тестирования, который основан на референтных моделях совершенствования процесса тестирования. Модели могут быть процесcные, такие как TMMi, TPI и контекстные, такие как STEP или CTP. Эти модели позволяют нам на основе практик строить наш процесс тестирования по конкретным шагам, тем самым развивая процесс тестирования равномерно и последовательно.
Но подходят ли нам такие модели для аудитов уже существующих процессов?
Отрасль тестирования и обеспечения качества сильно эволюционировала за несколько последних десятилетий. С появлением конкуренции на рынке появилась необходимость в тестировании. Сначала это были тестировщики-мартышки, нажимающие на кнопки и нечаянно находящие некоторые ошибки в продуктах. После появились тестировщики-аналитики, создающие модели тестируемого ПО и обеспечивающие более высокие уровни тестового покрытия.
Но и этого оказалось мало для нужд рынка: стали появляться различные инженерные и процессные практики, направленные на обеспечение качества: TDD, Code Review, QA, Model-based testing, и т.д. В обеспечение качества оказалась вовлечена вся команда, а не только выделенные специалисты по тестированию.
В своём докладе я хочу рассказать о ступенях эволюции тестирования, уровнях обеспечения качества, и рассмотреть наиболее эффективные решения по обеспечению качества.
Доклад рассчитан не только на специалистов по тестированию, но и на всех вовлечённых в продуктовую разработку профессионалов. Только вместе мы делаем этот мир качественнее!
Тестирование нуждается в постоянном улучшении, как и любой другой процесс. Возникал ли у вас вопрос “как улучшать”? Можно прибегнуть к конкретной методике, можно использовать отдельные принципы популярных практик... Но, прежде чем приступить к действию, можно прислушаться к специалистам, которые уже внедряют некоторые из них.
Автор: Людмила Лихогляд, ведущий специалист по тестированию "Лаборатории Качества"
Автор: Майкл Фритциус (Michael Fritzius)
Автор: Виктория Юркевич
Автор: Мелвин Салазар (Melvin Salazar)
Автор: Алёна Соколова
Автор: Джеральд Вайнберг (Gerald Weinberg)