Функциональное тестирование ПО. Часть 2

Какие виды багов позволяет выявлять функциональное тестирование?

Классификации могут быть разными. Можно выделить ошибку, то есть софт работает неправильно; плюс непосредственно на каком этапе и в каком модуле она была найдена, а также отдельно выделить степень сложности ее исправления.

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


Как функциональное тестирование помогает сократить финансовые затраты и время разработки и выпуска продукта (Time to market)?

Тестирование — неотъемлемая часть выпуска продукта или обновления ПО. Но я бы не делал акцент именно на экономии времени. В спешке есть риск получить множество проблем и пропустить дорогие дефекты, которые могут нанести компании ущерб.

Предположим, софт будет тестироваться командой, которая разрабатывает приложения. Она может рассуждать так: «Нам не нужна большая команда, у нас удовлетворительно работает приложение. Да, пользователи недовольны чем-то, но критических багов нет, и приложение не падает каждые 5 минут. Можем и без тестирования обойтись». Но если мы говорим про высоконагруженный софт со сложными бизнес-процессами и Workflow, разными сложными цепочками, то без тестирования обойтись нельзя. Чем раньше мы нашли дефект, тем дешевле его исправить.

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

Пример из жизни. В банкомате забыли поменять курс доллара. Это было в 2014 году. В банкомате доллары можно было купить за 60 рублей, а в онлайн-банке продать за 75, условно. Словом, с большой разницей. В итоге в банкомате курс был старый, и там можно было купить доллары дешевле, а потом сразу же их онлайн конвертировать и продать дороже. Вот и цена ошибки. Были толпы людей, которые снимали в этот момент деньги, потому что случайно заметили «тонкости перевода» и воспользовались ситуацией.


О юзабилити-тестировании

Кому-то удобно, кому-то — нет. Это философский вопрос. В каких-то системах бывает необходимо 35 раз перейти из одной вкладки в другую, и это реально раздражает. Допустим, терпение лопнет, и пользователь напишет в техподдержку. Скорее всего, техподдержка заведёт в Service-desk task, в котором укажет, что такой-то пользователь очень ругался на удобство использования какого-либо модуля ПО. Если таких пользователей будет много, эффективный менеджер по продукту или руководитель проекта не оставит без внимания и заведёт фичу на исправление. Это будет исправлено, ляжет в ТЗ и станет требованием.

Однако попытка устранить, казалось бы, небольшую проблему интерфейса может повлечь за собой большую череду изменений. Это может стать такой же глобальной проблемой, как ошибка системы, и «влететь в копеечку». Так что эффективный менеджер не забудет про соотношение цены решения данной задачи и принесенной выгоды после ее исправления. Если исправление стоит дорого, но никак не скажется, например, на количестве пользователей, использующих наше приложение, и т. д., то скорее всего править ничего не будут. Как вариант, накопят как можно больше замечаний и уже тогда выпустят глобальное обновление своего софта.


Про ISTQB

Сдавал экзамен ITSQB, когда был уже middle-инженером по тестированию. Решил я его сдать без особой подготовки. Естественно, не сдал, расстроился. Когда прочитал методичку, понял, что там другие определения. Там есть задание: что бы вы делали в конкретной ситуации. В материалах написано, что надо поступить определенным образом. Если так сделать в реальной работе, то не факт, что это единственное правильное, а порой может быть и неправильное решение.

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

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