Какое-то время назад, я и не подозревал о том, что существует такое понятие как Context-Driven Testing, буду называть его Контекстным Тестированием (или КТ для краткости). Хотя я и сказал, что не подозревал об этом, но как оказалось, на протяжении всей моей карьеры инженера по тестированию, я руководствовался принципами, провозглашенными такими известными специалистами в тестировании ПО как Cem Kaner, James Bach и Bret Pettichord, которые являются авторами и проповедниками КТ.
Я могу назвать себя успешным специалистом в тестировании, и теперь я знаю, что КТ и есть тот базис, который позволил мне добиться успеха. Но я жалею, что не знал об этом раньше, когда был еще молодым специалистом. Пришлось всего достигать самостоятельным путем, а знание принципов КТ позволило бы пойти путь быстрее и проще. Но, как известно, одно дело знать о чем-то, другое дело уметь применять это знание на практике. Таким образом и зародилась идея познакомить людей с КТ и объяснить, как легко данный подход может быть использован в повседневной работе.
Самое интересное, что КТ полезно, не только для инженеров по тестированию, но и для других участников разработки ПО. Тяжело добиться эффективного тестирования без взаимодействия с разработчиками и руководством проекта. А для плодотворного сотрудничества, и разработчики и руководство, в первую очередь, должны понимать что они хотят от команды тестирования, а команда тестирования должна знать об этом.
1. Школы тестирования
Для полного понимания того, что такое КТ, необходимо узнать откуда появилось такое понятие и какие есть альтернативы. Материал этой главы основан на презентации:
"Schools of Software Testing" (http://www.io.com/~wazmo/papers/four_schools.pdf)
Автор: Bret Pettichord (Copyright © 2003-2007)
Автор вышеуказанной презентации, выделил 5 школ тестирования. Деление на школы тестирования было произведено исходя из:
- интеллектуального сходства
- социального взаимодействия
- общих целей
Школы не базируются ни на каких-либо спицефических методах тестирования, ни на общей теоретической основе или методологии.
Вот эти 5 школ:
Аналитическая школа (Analytic School) . Базируется на аналитическом и логико-математическом подходе к тестированию. Пример - оценка покрытия кода тестами (code coverage)
Стандартная школа (Standard School) . Базируется на четком планировании, отслеживании прогресса и проверке правильности(validation) разрабатываемого ПО. Пример - матрица прослеживаемости (traceability matrix)
Школа обеспечения качества (Quality School) . Базируется на процессах, установленных правилах (policies) и метриках. Пример - критерии окончания тестирования, метрики и аудит исходного кода.
Школа "гибкого" тестирования (Agile School aka Example-driven School) . Базируется на проверке пользовательских сценариев (user's story) и наборе автоматизированных регрессионных тестов. Пример - разработка через тестирование (test driven development).
Школа контекстного тестирования (Context-Driven School) . Базируется на текущих нуждах проекта, предметной области и направлено на предоставлении информации о текущем положении дел в проекте. Пример - исследовательское тестирование (exploratory testing).
Среди этих школ нет плохих или хороших. Каждый из подходов имеет право быть использован, и зачастую, применение того или иного подхода обусловлено разрабатываемым ПО или инженером по тестированию. У кого-то лучше получается быть надзирателем, у кого-то лучше аналитические навыки.
С другой стороны, специалисты школы контекстного тестирования наиболее легко могут приспосабливаться к различным условиям, процессам, окружающей обстановке. Данный подход не отрицает ни математического обоснования для тестирования, ни использования метрик, ни следования заведенным процессам. Инженеры, проводящие тестирование в соответствии с принципами КТ, становятся полноправными участниками разработки ПО и играют более значительную роль по сравнению с представителями других школ тестирования.
2. Базовые принципы КТ
По материалам: http://www.context-driven-testing.com/
Авторы: Cem Kaner, James Bach
Давайте подробнее остановимся на этих принципах и попытаемся понять, чем же они так замечательны. Заодно, для каждого принципа буду давать советы по практическому применению их в вашей работе.
Ценность любых действий зависит от условий, в которых они выполняются. Один из основных принципов КТ. Любое тестирование должно приносить максимальную пользу в данный конкретный момент времени. Ценность результатов тестирования минимальна, если они получены несвоевременно. Например, если по плану вы должны гонять сегодня тест "А", сперва подумайте, а нет ли другого теста "Б", результаты которого сейчас всем нужнее.
В конкретных условиях существуют хорошие решения, но идеального решения не существует. Перед началом тестирования, подумайте над тем, что вы тестируете. Не выполняйте тупо все предписания чек-листа или все тесты. Возможно, нужно сделать только часть или надо придумать новые тесты, которых не было. Прежде чем прогонять тест - изучите то, что и как вы собираетесь тестировать именно сейчас - возможно ситуация поменялась.
Люди работающие над проектом - самая ценная составляющая проектного контекста. Спрашивайте у коллег, а что в данный конкретный момент важнее всего. Чем вы максимально эффективно можете помочь. Узнавайте у разработчиков как это работает и почему это работает именно так. Не говорите программисту, который попросил вас прогнать пару тестов на приватной сборке, что не будете этого делать ибо по плану вы другими делами должны заниматься. Может быть, в данный момент, изучить такую приватную сборку - это самая актуальная задача и вы сэкономите кучу времени себе и другим в будущем.
Во время работы над проектом случаются непредсказуемые вещи. Будьте готовы к тому, что по ходу проекта будет появляться необходимость в новых тестах (сделайте их), старые тесты могут стать ненужными (забудьте про них). Вполне возможно, потребуется изучение чего-либо, для того чтобы повысить эффективность тестирования (изучите это). Будьте готовы ко всему. Например к тому, что в какой-то момент вам придется сделать более поверхностное тестирование, чем вам бы того хотелось, но, зато, для большего объема функциональности. В противном случае вы ничего не успеете и вывалитесь из контекста.
Каждый продукт предназначен для решения какой-то задачи. Если эта задача не решена, значит продукт не работает. Самое важное, чтобы продукт делал то, что от него хотят. Это ваш приоритет в тестировании - сначала убедитесь, что то, для чего предназначена программа - работает. Не уводите разработчиков в сторону, пытаясь заставить их решать какие-либо сторонние и неприоритетные проблемы. Сперва попытайтесь заставить программу ошибиться в главном.
Хорошее тестирование - напряженный интеллектуальный процесс. Не ждите, что придет кто-то и скажет вам что надо делать (хотя и будут приходить). Предлагайте услуги по тестированию. Придумывайте новые услуги, новые тесты. Составьте свое мнение о качестве продукта, о том какое оно должно быть. Подталкивайте коллег к тому, чтобы достичь такого уровня качества. Не перестарайтесь - помните: идеальных решений не бывает - к вашему продукту это тоже относится.
Только посредством рассудительности и мастерства, применяемых в течение всего периода работы над проектом, мы сможем делать своевременные действия направленные на эффективное тестирование продукта. Тут и добавить-то особо нечего. Не верьте, если вам говорят, что все работает - проверьте. Делайте так, как считаете нужным, если вы уверены, что эти действия принесут максимальную пользу. Помните, что выпасть из контекста легко, вернуться - сложно. Участвуйте в обсуждениях, старайтесь узнать о грядущих изменениях до того как они случились. Помогите людям сделать эти изменения.
3. Контекст - что это?
Теперь, когда мы ознакомились с принципами КТ пришло время понять, а что же такое этот контекст, о котором идет речь.
Контекст - это совокупность знаний о разрабатываемом проекте в определенный момент времени.
В первую очередь контекст определяется всеми людьми, задействованными в работу над проектом, а так же сопутствующими документами и базами знаний (спецификациями, требованиями, стандартами, базой дефектов, перепиской и так далее). Третьей составляющей контекста является что-либо, произведенное на основе уже имеющихся данных. Я выделяю три разновидности контекста: истинный, ложный и скрытый.
Истинный контекст. Реальное положение дел в проекте, определенное действиями проводимыми до этого момента. То, что является отправной точкой для дальнейшего развития.
Ложный контекст. Устаревшие данные, неправильно понятая или двусмысленная информация. Что-либо желаемое, выдаваемое за действительное. Истинное положение дел не может быть таким, только потому, что кто-то хочет, что бы оно было таким. Следует избегать любого искажения или сокрытия информации. Не говоря об умышленном искажении фактов. Разоблачить неверные знания - одна из задач тестирования.
Скрытый контекст. Информация, по каким-то причинам, не доступная заинтересованным лицам. Возможно потерянная цепочка логических выводов, незамеченные изменения в спецификациях, расхождение текущей реализации с ее истинными целями. Задача людей работающих в тестировании находить такой скрытый контекст и незамедлительно информировать всех, кому это необходимо знать.
4. КТ и процесс тестирования
Хочу обратить внимание на то, что истинный контекст формируется на основе действий, а не желаний и не на основе процессов по которым эти действия совершаются. Но тем не менее, любая команда тестирования выполняет свою работу, в соответствии с каким-либо внутренним процессом организации труда. С этой точки зрения КТ дает возможность построить максимально гибкий и рациональный процесс.
Во-первых, КТ дает возможность сэкономить ресурсы на планирование и перепланирование. Я не призываю вообще отказаться от планирования или не иметь долгосрочной стратегии тестирования. Можно просто иметь список задач, элементы которого добавляются, удаляются или меняют приоритет перед началом тестирования каждой новой сборки, переданной на тестирование.
Второй момент, который поможет сберечь ресурсы и позволить проводить больше опытов - это тестовая документация. Давно пора перестать описывать тесты так, чтобы их мог прогнать "человек со стороны". Не будет "человек со стороны" тестировать ваш продукт. Никогда не будет. Такие чрезвычайно подробные описания тестов вредны по нескольким причинам - а) их в 99% случаев будут выполнять как есть, не смотря по сторонам; б) любое минимальное изменение в продукте обычно влечет за собой изменение описания теста; в) они требуют больше ресурсов на создание; г) они не дают исполнителю "включить голову".
Третья область где, вероятно, можно выиграть время - отчеты о тестировании. Отчеты должны быть содержательными и полезными. Не стоит писать никому ненужные отчеты, особенно делать это регулярно. Информация содержащаяся в отчете по результатам работы, в первую очередь должна быть полезна сотрудникам отдела тестирования. Ни руководству, ни программистам не нужна очень подробная информация. Таким образом, максимальный уровень детализации отчетов должен регулироваться потребностями самих инженеров, проводящих эксперименты.
В-четвертых, постоянное взаимодействие с командой разработки и с руководством проекта помогут выполнять наиболее важные задачи вовремя.
Последнее, и наверное самое главное, это команда. Процесс должен определяться теми людьми, которые ему следуют. Чем ровнее уровень профессионализма в команде тестирования, тем более эффективно можно организовать процесс тестирования. Наиболее важные качества это самодисциплина и ответственность каждого из участников.
5. КТ и процесс разработки
Команда тестирования - команда, оказывающая услуги другим участникам разработки. При этом все задействованные в разработку (включая тестирование) люди должны преследовать единственную цель - вовремя выпустить качественный продукт, решающий поставленные задачи. Вот несколько советов основным участникам процесса разработки.
Разработчики , воспринимайте людей работающих в тестировании как помощников. Отвечайте на их вопросы, даже если они на первый взгляд кажутся вам глупыми. Ведь проще обсудить возникшее недопонимание прежде чем оно будет сформировано в виде дефектов и окажется на всеобщем обозрении. Прислушивайтесь к тому, что говорят тестеры, объясняйте им почему вы считаете, что они не правы. Знайте - люди работающие в тестировании не глупее вас, они просто делают за вас кое-какую грязную работенку, позволяя вам сосредоточится на других аспектах разработки ПО.
Руководители тестирования , не нагружайте исполнителей бюрократической работой, если ее результаты никому не нужны. Каждый ненужный отчет отнимает драгоценное время от проведения экспериментов. Не требуйте слепого соблюдения планов или процессов, если текущая ситуация диктует поступить иначе. Старайтесь нанимать в тестирование людей, которые умеют думать и знают, зачем они совершают те или иные действия. Откажитесь от набора более дешевых "кликеров", выполняющих, зачастую, никому ненужные действия.
Руководители проектов , определитесь, что вы хотите от тестирования. Придите к соглашению о тех сервисах, которые будет предоставлять команда тестирования. Не гонитесь за большим количеством услуг, лучше меньше, но лучше. Убедите всех участников разработки, что ответственность за качество лежит на каждом, а группа тестирования может только контролировать и информировать о текущем уровне качества продукта. Также помните о том, что нет магического порошка, который выявляет все дефекты - тестирование процесс сложный и ресурсоемкий.
Коллеги по тестированию , думайте, спорьте, не верьте, проверяйте все домыслы на практике, не скрывайте никакие знания или результаты вашей работы. Каждый ваш шаг должен иметь какой-то повод, исходя из контекста. Добивайтесь своего, если вы считаете, что это правильно. Помните, вы одновременно являетесь искателями истины, контролерами качества и первыми пользователями продукта. Знайте, что ожидают от вашей работы коллеги, разработчики и руководители.
6. КТ - стиль жизни думающего инженера по тестированию ПО
Вне зависимости от того, какие процессы разработки и тестирования существуют на вашем текущем месте работы, вы всегда можете руководствоваться принципами, приведенными выше. Сделайте контекстный подход к тестированию вашим жизненным кредо. В этом случае с вашим мнением всегда будут считаться, так как ваше мнение основывается не на количестве тестов, которые надо бы было прогнать, не на закостенелых процессуальных действиях, не на основе вредных метрик. Ваше мнение всегда основывается на текущих нуждах, понимании происходящего и желании принести максимальную помощь. Ваши действия всегда должны быть разумны, резонны и понятны для других членов команды.
7. Как обучиться КТ
Так как я не занимаюсь профессиональным обучением, а сам учился только на практике, то могу привести еще несколько советов для самообучения, которыми я и руководствуюсь:
- Всегда старайтесь изучить предметную область. Не копайте слишком глубоко, если этого не требуется для тестирования.
- Только пробуя что-то на практике возможно научиться тестированию. Но основное тестирование происходит в голове, поэтому старайтесь больше читать и узнавать что-либо новое, что поможет вам думать.
- Изучите текущий контекст, прежде чем что-то сделать. Например, перед тем как предоставить отчет о дефекте, поищите, может кто-то уже нашел его до вас.
- Пытайтесь докопаться до сути проблемы самостоятельно, но тратьте на это разумное время. Иногда проще спросить знающих людей, не боясь показать, что у вас нет достаточного количества знаний. Заодно и узнаете что-то новое.
- Всегда пишите в отчетах о дефекте, что по вашему является правильным или ожидаемым. Обосновывайте ваши требования. Приводите несколько возможных вариантов решения проблемы.
- Обращайте внимание на любые проблемы, будь то тестируемый продукт, спецификации, тесты и инструменты тестирования или процесс.
- Обсуждайте спорные вопросы со всеми заинтересованными людьми. Иногда так вопрос решить проще, чем если бы вы написали сомнительный дефект.
- Не бойтесь новых областей знаний. Никогда не говорите, что вы не будете этого делать потому, что не делали раньше. Новый вид тестирования или новая область подлежащая тестированию должны стимулировать вас и подталкивать к новым достижениям.
- Иногда абстрагируйтесь от контекста разработки, оставаясь при этом только в контексте разрабатываемого продукта. Попытайтесь быть просто пользователем. Если возможно, используйте продукт по назначению.
- Если вы выполняете какой-то тест повторно, варьируйте свои действия. Единственное исключение - верификация дефектов.
- Знание предметной области и особенностей реализации - отличная база для дизайна новых тестов.
- Иногда вы можете ошибаться. Прислушивайтесь к доводам других людей. В любом случае, всегда есть возможность достичь компромисса.
- Если вы не нашли ни одного дефекта в ходе тестирования - значит вы тестировали плохо.
8. Заключение
Может показаться, что статья не содержит ничего нового и что советы вполне очевидны и тривиальны. Да, да это так и есть. Но как ни странно, почему-то, в повседневной работе очень мало людей руководствуются данными принципами.
Разве ситуация, когда команда тестирования узнает об каких-то изменениях последней является исключительной? Разве не считается, что мнением инженера по тестированию можно, в определенный момент, пренебречь? Разве не общепринятая практика, что лучше набрать побольше низкооплачиваемых и неопытных сотрудников в тестирование, ибо считается что для этой работы ни ума ни опыта много не требуется? Разве нерадивых разработчиков не переводят в "ссылку" в отдел тестирования? Разве руководители не обсуждают ситуации, когда они не понимают, зачем им вообще это тестирование, что они там вообще делают? Можно продолжать список вопросов "разве не...". Печально, но факт, что все перечисленное довольно часто встречается. А самое печальное в том, что люди работающие в тестировании, зачастую, сами подтверждают сомнения в сложности и важности их работы, просто потому, что делают не то, что от них требуется.
Если, хотя бы, несколько человек задумаются над советами приведенными в статье, если пересмотрят свое отношение к тестированию, если кто-то сможет извлекать больше пользы от тестирования во благо качества разрабатываемого продукта - то я буду считать, что статья написана не зря.