Home

Оригинал статьи: https://testzius.wordpress.com/2017/02/13/sun-tzu-was-a-tester/

Автор: Майкл Фритциус (Michael Fritzius)

Перевод: Ольга Алифанова

О книге

Книга Сун Цзы "Искусство войны" была написана в 5 веке до нашей эры. С тех пор она переводилась на множество языков и использовалась не только с целью обучения военной тактике, но и в корпоративных отношениях, спорте, бизнесе, и ряде других дисциплин, требующих стратегии и тактики.

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

Давайте посмотрим, как мудрость Сун Цзы применима к "Искусству тестирования".

Далее следуют цитаты из книги и их возможное приложение к тестированию. Расширенный набор цитат можно посмотреть здесь.

Применение в тестировании

"Превосходство над вражескими нациями без вступления в военные действия есть наивысшее из искусств".

Работая с другими людьми, мы должны помнить о том, что люди – существа эмоциональные. Каждый приносит на рабочее место свой личный "багаж" эмоций. Часть нашего багажа отвечает за наше отношение к другим людям. Если вы хотите напасть в ответ на чей-то укол, остановитесь и подумайте, почему люди говорят именно это? Действительно ли они хотят "достать" вас, или преследуют личные цели? Обычно это скорее второе, а не первое. Хорошая коммуникация – залог успеха: обезвредьте ситуацию, поговорив с коллегой и попытавшись понять, какие цели он преследует.

"Если ты знаешь себя и знаешь других, не подвергнешься опасности и в сотнях битв. Если ты знаешь себя и не знаешь других, твои победы будут равны поражениям. Если ты не знаешь ни себя, ни других, опасность будет подстерегать тебя повсюду".

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

"Планы нужно держать в секрете, атаковать нужно быстро".

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

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

"Победоносная армия побеждает и затем уже ищет битвы. Армия поражения вступает в битву и потом уже ищет победы".

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

“Хаос открывает новые возможности”

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

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

"Лучшая победа — победа без борьбы".

В тестировании и автоматизации тестирования наилучшее решение не требует никаких действий вообще. Это или отсутствие тестирование, или отказ от создания новых автотестов.

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

"Длительные войны не могут быть полезными для нации".

В изматывающих "зарелизь или умри" нет ничего хорошего, я это видел сотни раз. Череда больших провальных релизов – не лучший способ наладить отношения с потребителями и взбодрить команду.

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

“Сила движется быстро, как ветер, который не оставляет следов, и действует как молния. Она подобна лесу, потому что в ней есть порядок. Она прожорлива как пламя, потому что, проходя по равнинам, она не оставляет ни единой травинки. Она неподвижна как гора, когда стоит лагерем".

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

"Заботься о солдатах как о возлюбленных детях, и они с радостью умрут за тебя".

Менеджеры, я знаю, что вы в курсе, что тестирование – сложная штука. Если вы игнорируете налаживание дружеских взаимоотношений с командой, вы потеряете их расположение. А затем – их воодушевление. А затем вы потеряете их физически, потому что они уйдут к конкуренту.

Доменное знание тяжело наработать и легко потерять. Без обид.

“Когда враг силен, его можно опустошить. Когда враг запасся провиантом, его можно обречь на голод. Когда враг отдыхает, его можно заставить двигаться".

Когда мы тестируем приложение одним и тем же образом, нам может показаться, что оно стабильно. На самом деле мы просто не проверили все его возможности. Поменяйте хоть что-то – используйте случайно сгенерированные данные, спецсимволы, или что-то новое каждый раз, когда вы приступаете к тесту. Наседайте на приложение, атакуйте его, заставьте его работать на износ. Чем больше вы варьируете тесты, тем выше вероятность поимки бага. Не бойтесь грязных приемов.

"Сочетания пяти нот порождают множество звуков".

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

"Мудрый воитель избегает столкновения с острой силой и ударяет по убывающей и падающей силе".

Если в системе что-то хорошо протестировано, не концентрируйте усилия на этой части приложения. Скорее всего, баги окопались вовсе не там, а в местах, где система слаба – код написан в спешке или тем, кто часто пропускает ряд проверок, требования были недостаточно детальными, пользователи могут контролировать входные данные, и т. д. Определите слабости своей системы и действуйте соответственно.

"Тот, кто стремится побеждать в битвах, не является мудрым. Тот, кто делает противника беспомощным, не вступая в прямое столкновение, — лучший из воителей".

Лучшие тестировщики – это люди с прекрасными коммуникационными навыками. Выше я уже упоминал о переговорах как способе найти баги еще до того, как написан код. Метрика качества кода сразу же взлетает, если вы применили подобный подход.

"Если ты собираешься начать войну, предварительно рассчитай затраты".

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

"Ты можешь знать, как получить преимущество над противником. Но ты не сможешь заставить противника подчиниться твоему преимуществу".

Люди могут теоретически знать, как именно тестируется ПО, и не уметь тестировать его самостоятельно. Старайтесь быть человеком, который делится идеями, но и не впадает в ступор, когда приложение наконец попадает к нему в руки.

"Провоцируй, заставляй действовать и раскрывать планы. Тогда увидишь, каковы достоинства и недостатки врага, и поймешь, каков его труд и каков отдых".

Тестируя свободным поиском, бдите за тем, как именно приложение реагирует на ваши действия. Есть ли в его реакции закономерности? Есть ли странности? Не указывают ли они, где, возможно, кроются баги?

"У военных действий, так же как у воды, нет постоянной формы".

Будьте гибкими в любых ситуациях. Не делайте ничего одним и тем же способом – адаптируйте свой подход к тому, что происходит, и вы добьетесь успеха.

"Усиливая все подряд, он все ослабляет".

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

"Если вы сражаетесь изо всех сил, у вас есть шанс выжить. Если вы цепляетесь за свой уютный уголок, смерть неизбежна".

Цепляясь за определенный порядок действий, вы вскоре утратите все свои преимущества, учитывая тенденции в разработке ПО. ПО меняется так серьезно, что мы просто не можем позволить себе упорствовать в приверженности какому-либо инструменту или методологии. Мы должны вторгаться в области, с которыми мы пока не знакомы, и постоянно учиться новому.

"Генерал, который не ищет славы и не пытается избежать наказания, вместо этого заботясь исключительно о безопасности народа и его интересах – сокровище нации".

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

"Убедиться, что защита хороша, можно только тогда, когда вы заняли позиции, которые невозможно атаковать".

Разрабатывая автотесты, очень важно не использовать подходы, результатом которых будет нестабильное поведение тестов или необходимость постоянно их исправлять. Сделайте их небольшими, простыми и "защищенными от атак". Чем меньше времени вы тратите на игрища с автотестами, тем более эффективными они – и вы – будете.

"Если тот, кого посылают за водой, пьет сам, значит, в лагере жажда. Поскольку в армии все едят поровну, по одному человеку видно, что голодают все".

Если ваша команда состоит из людей, которые много знают, но не особо горят желанием делиться этими знаниями, то это путь в никуда. Никто не знает про тестирование абсолютно все. Идеи должны свободно циркулировать внутри команды – это залог ее успеха.

Заключение

Знаете, мне пришлось удалить около 50 цитат, потому что я устал печатать. Из "Искусства войны" можно почерпнуть множество других абстрактных идей. Попробуйте приложить их к своим рабочим задачам.

Вперед, к победе!

Обсудить в форуме.