Entry tags:

it, тестирование

Сферический тестировщик в вакууме и его более осязаемые собратья.
И снова здравствуйте, мои маленькие любители (и профессионалы, чего уж там) IT!
Давненько собирался я поведать вам историю чудную о сферическом тестировщике в вакууме, а тут, вот, собрался.
В каком-то смысле натолкнули меня на это.
Однажды уже я рассказывал вам (а кому-то напоминал) азы IT-менеджмента, то есть, то, с чего всё, в общем-то, и началось.

А для рассказа, собственно, о тестировании воспользуемся мы с вами одним из вариантов расширения каскадной модели - так называемой V-образной моделью.

Так вот, в идельном случае (а в данном случае идеал достижим) пунктирными стрелками обозначаются этапы, в которых должно привлекаться тестирование.

1. Первый этап частенько никого из рядовых специалистов не касается - это процесс принятия решений о сроках, целях и бюджетах проекта. Привлечение к этой работе тест-менеджеров наравне с менеджерами разработки, документаторами и аналитиками, имеет смысл с целью получения более точных оценок.
2. Второй этап, с которого, собственно, и начинается проект работки программной системы - это сбор требований. И является этот этап одним из самых сложных, так как многие хорошие идеи приходят в голову, когда в руки попадает первый прототип программы (эта проблема частично решается различными итерационными моделями, но об этом потом).
   Что же такое сбор требований? Это менеджеры и аналитики клещами вытягивают из заказчика, чт оименно он хочет получить, как это должно работать, в каких условиях, на каких компьютерах и операционных системах... Вопросов десятки, и далеко не на все из них можно с ходу ответить.
   В чём критическая важность этого этапа и участия профессиональных тестировщиков в нём, так это в том, что исправление ошибки на этом этапе почти ничего не стоит (по разным оценкам, 1-10 долларов). А вот если ошибка, внесённая на этом этапе, обнаружится только во время системного и приёмочного тестирования, её исправление может обойтись, скажем, в тысячу долларов или в десять тысяч. Тестирование на данном этапе имеет ряд задач:
   • выявить неоднозначные (англ. ambigious) формулировки - мы не имеем права рассчитывать на то, что аналитик, формулирующий требования и программист, который по этим требованиям будет создавать собственно продукт находятся в непрерывном телепатическом контакте. Нужно исходить из того, что если что-то может быть понято неправильно, оно обязательно будет.
   • выявить конфликты между различными требованиями - это тоже очень важная и сложная задача, ведь для сколь-нибудь крупной системы требований могут быть не сотни, а сотни тысяч.
   • выявить потенциально "проблемные" функции или модули. Сложность редко бывает распределена по всему продукту равномерно. Согласно тому же правилу 80/20, 20% кода содержат 80% ошибок, и в данном случае мы, как предлагают авторы одной хорошей книги по тестированию, исходим из того, что причина ошибок - не "криворукие" программисты (или индусы, или китайцы, или просто студенты), а сложность самой системы, то есть, некая объективная и поддающаяся оценке характеристика. Очень часто в проектах, где тестировщиков привлекают уже на этой стадии, опытные тестировщики сразу могут указать потенциально "опасные" с точки зрения содержания ошибок места, и это не интуиция (хотя и профессиональной интуиции есть место в тестировании), это опыт, который можно и нужно нарабатывать.
   
   А теперь давайте соотнесём написанное выше с пунктирной горизонтальной стрелкой. На правой стороне видим "Системное и приёмочное тестирование". Что же это значит? Это значит, что перед тем, как система перейдёт на этап эксплуатации, должна быть осуществлена её приёмка. А на основании чего осуществляется приёмка? На основании требований, разумеется! Приёмочное тестирование - это проверка работспособности системы, цель которой - подтвердить, что система делает то, что должна и не делает того, чего не должна. Как нам в данном случае помогает тестирование требований и спецификаций? Очень просто! Когда проект близится к завершению (а переход к системному и приёмочному тестированию - это уже очень близко), нервы у всех на пределе, бюджеты тоже, и вот тут-то как раз и помогает раннее тестирование: тестировщики уже готовы, они уже видели эти спецификации, читали и проверяли их, и восстановить их в памяти гораздо легче, поверьте, чем за два дня осиливать, скажем, четыреста страниц спецификаций (и такое бывало, скажу я вам).
3. На стадии разработки архитектуры информационной системы роль тестировщиков я преувеличивать не буду. Если среди них есть действительно отличные профессионалы, которые в IT уже не год и даже не два или имеют опыт в архитектуре, они могут помочь, в остальном же архитекторы могут помочь им. Примерно так же, как и в предыдущем пункте: получая свежие данные об архитектуре системы, тестировщики могут начать планировать интеграционное тестирование. Случается, уже на этом этапе также выявляются потенциальные неприятности, но даже если нет, в любом случае, какая-то доля тестов уже будет готова, и тестировщикам не придётся, сломя голову, бежать изучать архитектуру, как только будет завершено модульное тестирование.
4. Детализированная разработка проекта - ответственнейший этап, чем лучше будет выполнена работа на этом этапе, чем точнее и непротиворечивее будут поставлены задачи разработчикам, тем будет лучше всем. Тестированиена этом этапе предоставляет только консультационные услуги, но как можно понять из стрелок, на этапе первичного модульного тестирования могут быть выявлены проблемы, которые отбросят проект (или какую-то из его составных частей) обратно на этот этап, этап детализированной разработки проекта.
5. Кодирование. Грубоватый термин, но сойдёт для обозначения процесса. Здесь тестировщики, как правило, не вмешиваются вообще, но бывают и исключения. В некоторых фирмах в составе групп разработки работают подгруппы тестировщиков, которые занимаются, собственно модульным тестированием - тестированием на уровне кода. То есть, код как таковой они не пишут, но их тесты ближе к "нутру" информационной системы, чем к обычным "тестерским" задачам. Ещё на этой стадии тестировщики могут привлекаться в роли аналитиков (разумеется, если ранее их привлекали к тестированию требований и спецификаций), либо для различных оценок кода. Иногда тестировщики занимаются собственно анализом кода, например, оценка кода по ряду метрик (вроде размера, цикломатической сложности и других). Но, повторюсь, это редкость. В большинстве случаев тестировщики в этом этапе не участвуют, на этом этапе они занимаются разработкой тестов по спецификациям.
6. Модульное тестирование бывает задачей чисто программистской, бывает чисто тестерской (как я писал выше), иногда над этой задачей работают сообща. Цель - протестировать отдельные модули (функции, подсистемы) программного продукта и убедиться, что по отдельности они работают правильно.
7. Интеграция и тестирование - непростой этап, многое здесь зависит от архитектуры системы. Обычно под интеграционным тестированием понимают соединение отдельных модулей (функций, подсистем) и проверка взаимодействия между ними, как правило, задача весьма сложная, и силами одних тестировщиков тут можно и не справиться, так что, подключаются на этом этапе и разработчики, и архитекторы.
8. Системное и приёмочное тестирование. Вот это как раз то, что обычно понимается под тестированием :-) Но дочитавшию досюда, полагаю, уже понимает насколько это далеко от истины. Это верхушка айсберга: к этому моменту проделана огромная работа (для случая сколь-нибудь сложной программной системы), уже проведено значительное количество тестов, подготовлены планы тестирования, тестовые сценарии, тестовые случаи и варианты использования, пулы данных, частично - скрипты для автоматизированного тестирования. В общем, считать, что проведение тестирования - это и есть тестирование сравнимо с утверждением, что нажатие на кнопку, запускающую конвеер - это и есть автомобильное производство (а строительство завода, разработка, поставка, монтаж и наладка сложнейшего и дорогого обрудования - так, мелочи).
   В этом пункте я вывалил целую кучу специфических тестерских терминов. Дабы не перегружать пост, я не буду их здесь пояснять. Возможно, чуть позже я напишу отдельный пост с терминологией тестирования, а особо заинтересованным людям, не готовым ждать - гугл в помощь, он все эти термины знает, не сомневайтесь.
9. Так вот, вы будете смеяться, но на системном и приёмочном тестировании работа тестировщиков не заканчивается. Как правило, в период эксплуатации и сопровождения программной системы, тестирование обрабатывает поступающие в службу сопровождения (или технической поддержки) жалобы и ошибки, проверяют их, после чего эти ошибки идут на исправление разработчикам, и каждая ошибка проходит все (иногда, конечно, не все) этапы, начиная с "Детализированной разработки проекта".

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