Перевод интервью с Семом Канером("Получайте удовольствие, используя ваши метрики"). Часть 1я

Существует замечательнй портал uTest , который взял серию обширнейших интервью у мирового гуру в области тестирования Программного Обеспечения - Сема Канера(Cem Kaner).  
Я не смог обойти стороной такой кладезь знаний и решил что переведу серию этих статей на русский язык. Так как информации очень много, то переводить я буду частями. Итак первая часть интервью перед Вами.

uTest:  В Вашей онлайн автобиографии,  Вы говорите что целью вашей карьеры было «улучшить безопасность  увеличить общую удовлетворенность людей от использования ПО». Чтобы этого добиться Вы обучались и работали с такими науками как: психология, юриспруденция, программирование, тестирование, лингвистика и продажи. Объясните, как работа во всех этих областях помогла Вам в более глубоком и правильном понимании ПО? А так же какой полезный опыт тестировщик может получить, общаясь с адвокатами, писателями и людьми занимающимися продажами?

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

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

Поэтому я не вижу «других областей знаний» или еще чего то.

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

Особенности тестирования Safety Critical систем. Part 2

В этой части хочу поговорить  статическом тестировании, которое, как правило, играет очень важную роль в процессе тестирования Safety Critical проектов. Собственно, что такое статическое тестирование. В двух словах это тестирование, которое не подразумевает выполнение кода программного продукта. В основном это различного вида инспекции и анализ кода. Стоит упомянуть, что Safety Critical  системы характеризуются различным уровнем критичности и в зависимости от этого уровня глубина тестирования может варьироваться. Хорошим примером различных уровней критичности может выступать американский стандарт DO178B (его европейский аналог ED-12B).

Инспекции

Основываясь на различной степени критичности проектов, практикуют следующие виды инспекций:

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

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

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

Неформальная инспекция – не документированный или мало документированный процесс,  в рамках которого происходит так называемые peer to peer reviews(один сотрудник просматривает документ или код разработанный другим сотрудником)

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

Самые распространенные техники это техническая инспекция и Walkthrought. Причины в том, что этот микс наиболее оптимален с точки зрения усилий затраченных на внедрение использование на проекте.

Статический анализ кода

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

Покрытие условий – как видно из названия используется для анализа покрытий всех условий используемых в программном коде и выявления утечек памяти. Эта техника более действенна чем «покрытие операторов» но и более трудозатратна. Как правило, также автоматизируется.

Покрытие переходов между состояниями – третья разновидность, используемая для анализа программного кода, проводит проверку на покрытие всех переходов между состояниями. Можно сказать что в каком то роде, эта техника объединяет в себе 2 предыдущие. Так же автоматизируется.
Существует большое количество техник, которые родились в результате миксования основополагающих. Об этом стоит писать серию отдельных статей.
Дополнительные техники
Хорошей практикой длинных и долгоиграющих проектов, коими, несомненно, являются Safety Critical проекты, можно назвать написание Тест Дизайнов.
О тест дизайнах мы поговорим в следующей части[...]