Теория тестирования. Миф и реальность.
Почетный член коллегии RSTQB, “дедушка русского тестирования” с опытом работы более 50 лет Александр Александров в интересной и доступной форме развеивает миф о “теории тестирования” и панацеи автотестов.
Около семи лет назад я работал в компании Luxoft, маркетологи которой предложили прочитать доклад на крупнейшей в России конференции по тестированию программного обеспечения Heisenbug. Конференция рекламировала себя слоганом “Воды не будет. Как и докладов про Agile, оптимизацию работы коллектива и управление командами тестеров”. Я радостно сообщил программному комитету, что как раз и занимаюсь тест-дизайном, тест-менеджментом, оценкой трудозатрат, т.е. прочими “жидкостями”. Расстались друзьями.
Прошло несколько лет… И я случайно обратил внимание, что не сайте конференции Heisenbug немного поменялся слоган и он подтолкнул меня все-таки принять участие во встрече: “Никаких тест-кейсов, правил заведения багов и управления командами — только технологии, только хардкор!”. На другой странице написали: “Нам интересны доклады на следующие темы: … теория тестирования”. Интересно, как маркетологи Heisenbug сумели сочетать два таких посыла?
Термин “теория тестирования” мы слышим часто, проводя технические интервью (за последние годы я уже провел порядка тысячи). Если мы посмотрим определение теории в Википедии, то станет понятно, что это никак не технологии, не хардкор, и к нашей деятельности не имеет отношения. Так, может быть, под “теорией тестирования” организаторы конференции понимают что-то другое? Решено было это определение препарировать.
Как известно, все тестирование делится на две части: там, где кнопки нажимаются (ТНК) и там, где кнопки не нажимаются (ТННК). В свою очередь кнопки можно нажимать вручную — Ручное тестирование (РТНК), или автоматически — Автоматическое тестирование (АТНК). Обычно под “теорией тестирования” понимают ТТНК (тест-дизайн, подготовку тестовых данных, выбор методики, ЖЦ и др.), то есть, где не нажимают кнопки (потому что кнопки нажимать — это слишком просто). При этом с термином “теория тестирования” часто связывают негативную коннотацию: “теория ваша — фигня! Ты покажи, как ты баг находишь”. Только вот без этой теории баг найти нельзя.
Приведем примеры из жизни. Снайпер руководствуется наставлением по стрелковому делу и опытом, а не теорией баллистики. Командир воздушного судна — летными инструкциями и опытом, а не теорией аэродинамики. Водитель — правилами дорожного движения и опытом, а не теорией… Продолжать можно долго.
Задумаемся. Сколько времени мы тратим на написание автотестов? Сколько времени мы тратим на поддержку автотестов и инфраструктуру? Сколько денег мы тратим вместе с тратой этого времени? Автоматизация на проекте — необходимость или дань моде? Результативность или деньги на ветер? Сколько багов при регрессе находят автотесты? А сколько багов выявляются в продакшене? Не все тесты одинаково полезны. Все ваши знания ничего не значат без практики.
Применить любую теорию для решения конкретной возникшей проблемы просто так сходу, быстро и правильно невозможно. Нужно проводить исследование, выбирать альтернативы и т.д. Применить любую теорию без серьезного владения знаниями и навыками иногда можно, но редко и дорого. Теория в непосредственной работе снайпера, водителя, тестировщика — неприменима.
А что же вместо теории? Чем должен руководствоваться тестировщик? Методиками/методологиями, изложенными, например, в публикациях (список литературы представлен ниже). Лучшими практиками — материалами конференций, форумов, тренингов и др. При этом важно, чтобы они были доступны и максимально понятны. Чтобы к ним было отношение не как к теории, а как к фундаменту, на котором нужно строить дом. А самое главное, опыт — сначала свой, после еще и корпоративный.
Но почему же все-таки регулярно возникает тема теории тестирования? Потому что, огромное количество людей, которые работают в региональных бордах и в центральном аппарате ISTQB, заботятся о том, чтобы лучшие методики и практики были изложены максимально четко и понятно. За этим часто не было видно тех практических усилий, которые прикладывались для того, чтобы все максимально просто изложить. Вот тогда этот опыт создает впечатление теории. Поговорка «Летные инструкции пишутся кровью» в полной мере применима к программам, которые разработаны ISTQB. Потому, что за каждой программой стоит опыт с набиванием шишек, преодолением препятствий, решением ошибок.
Получается, что никакой теории нет. Есть теория схем программ, которая разрабатывалась в новосибирском Академгородке, теория автоматов, теория алгоритмов Юрия Янова, которую изучают на мехмате. Но к тестированию они непосредственного отношения не имеют. Тестирование — это рафинированный опыт.
Как же назвать все то, что нужно знать тестировщику, если это не теория? Техники, методики, приемы, технологии тестирования — что является для них фундаментом? Все это опирается на процессы тестирования. ПТ — это база и для технологий, и для хардкора (за который, кстати совершенно правильно, ратуют на Heisenbug).
Тогда возникает следующий вопрос — откуда берется опыт? Прежде всего это, хорошо известный, цикл Деминга — Plan-Do-Check-Act (планирование, реализация, анализ и, при необходимости, коррекция. Опыт может (и должен) быть разный, но всегда обязан быть целенаправленным и осмысленным.
Однако, обычно получается так:
Работа цикла Деминга: Срочно! — А-а-а-! — Не успел! — Не умею!
Оценка трудозатрат на тестирование: оркестр из 30 музыкантов исполняют 6-ю симфонию Бетховена за 40 минут. За какое время оркестр из 60 музыкантов исполнит 12-ю симфонию Бетховена?
Техника тест-дизайна и проверки конечных значений: Тестировщик заходит в бар. Заказывает пиво. Заказывает 0 пива. Заказывает 99999999999 пива. Заказывает ящерицу. Заказывает -1 пиво. Заказывает двравпорывп. Первый реальный посетитель заходит в бар и спрашивает, где туалет. Бар взрывается. В последнем случае — тестировщик вроде бы все делает правильно, но знание предметной области у него нулевое.
Что же можно порекомендовать? Во-первых стараться не использовать выдуманный термин “теория тестирования”. Не надеяться, что у тестирования низкий порог вхождения. Это байка, которая губит профессию: можно прийти в тестирование с низким порогом вхождения и остаться на нем навсегда. Под порогом вхождения следует понимать не умение использовать автоматизацию и писать автотесты, а прежде всего владение методологиями тестирования, подходами к тестированию и опытом тестирования. Тестирование — это сложная инженерная область, потому, что тест-дизайнер, который разрабатывает тестовые сценарии, разрабатывает их для того, чтобы найти дефекты, про которые он мало что знает и которых еще вообще разработчики, может быть, еще не создали.
Сейчас возникаем много шума вокруг автоматизации тестирования. Это уже вторая волна интереса к автоматизации, хотя первая окончилась ничем. Потому что умение нажимать кнопки и писать скрипты, не имея понимания, зачем и для чего эти скрипты пишутся — это хороший способ освоения денег заказчика, но не лучший способ уложиться в сроки, в бюджет и добиться качества.
При разграничении РТНК, АТНК и ТТНК нужно руководствоваться замечанием M.Bolton и J.Bach: “Поскольку взаимодействие тестировщика и программного продукта во время тестирования нельзя описать словами, его невозможно закодировать и, следовательно, автоматизировать”. Говоря проще: в тестировании все автоматизировать нельзя. Хотя менеджменту это сделать всегда очень хочется.
Автоматизация не является панацеей и никак не влияет на качество тестирования, что доказывает число проектов в которых использовалась автоматизация, но которые закончились неудачно. Это становится особенно заметным, когда специалисты, которые пишут автотесты, прекрасно умеют кодировать, не не умеют применять техники тест-дизайна.
Еще один совет — использовать мировой опыт, зафиксированный в программах ISTQB. Это никакая не теория, это опыт более 70 тысяч региональных членов организации.
По традиции, закончим списком рекомендованной литературы:
— Эдвард Деминг (E.Deming) о качестве и процессах,
— Гленфорд Майерс (G.Myers) о тестировании,
— Ли Коупленд (L.Copeland) о технологиях тест-дизайна,
— Рекс Блэк (R.Black) о тест-менеджменте.
Спасибо за внимание.
Авторы: Александр Александров, Ксения Такташева
По материалам Конференции BCON-2023
