Home

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи: http://www.developsense.com/blog/2017/01/drop-the-crutches/

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

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

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

Вчера у меня состоялся забавный разговор с клиентом/коллегой. Он предположил, что тест-кейсы похожи на костыли, и я с ним согласился. И добавил, что костыли регулярно навязываются людям, которые и изначально-то не хромали. Как будто перед началом футбольного матча мы раздали всем игрокам по костылю, чтобы они прихрамывали.

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

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

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

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

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

Чтобы ни происходило, вы должны осознать вот что:

Никто не может предсказать, какие проблемы возникнут в нетривиальном продукте.

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

а как фрактал.

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

По этой причине мне кажется, что любые выбитые в камне или слишком подробные критерии готовности – это полная противоположность настоящего Agile. Давайте принимать во внимание непредсказуемость, обучение, изменения, и относиться к критериям готовности как к очень ненадежной эвристике. Лучше даже рассмотреть критерии того, что еще не готово – "мы, возможно, не закончили, пока как минимум вот это не будет сделано". В части "как минимум" мы допускаем, что мы можем выяснить или открыть важные требования, когда начнем работать над продуктом. И кто знает – мы можем в любой момент решить выкинуть что-нибудь из нашего списка критериев. Может, единственное, от чего мы действительно зависим – это правило нестабильности.

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

Многим людям хочется сказать "Но нам нужно запускать пачку старых кейсов, потому что мы не знаем, как изменения кода повлияли на наш продукт!". Если вы потеряли способность понимать собственный продукт, почему вы думаете, что вы все еще понимаете эти тест-кейсы? Почему вы верите, что они все еще актуальны?

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

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

Сделайте это, и вы отбросите костыли, которые на самом деле никогда не были вам нужны. Вы будете более ценным сотрудником и подспорьем для команды. Вы и ваше тестирование станете актуальными.

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