Какие мероприятия необходимо выполнить для обеспечения качества тестирования

Что такое качество. Разбираемся в иерархии терминов «QA», «QC» и «тестирование»

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

Если спросить коллег про обеспечение качества в энтерпрайзе, то с ними проблем обычно нет: тебя быстро посылают в группу обеспечения качества и дальше занимаются своими делами. А вот в не энтерпрайзе (например, в ритейле) начинается интересное. В зависимости от того, кого спрашивать, тебя будут посылать к разным людям, но в большинстве случаев всё сводится к «Не мешай работать, иди к тестировщикам, они вот как раз про качество». Не проблема, сходим.

Ниже результаты моего небольшого исследования, что же такое качество и как его обеспечить, чтобы не слушать в ответ: «Слушай, да что ты докопался, сходи на www.protesting.ru (далее – ПроТестинг), там специально для таких, как ты все написано». Поскольку про него (ПроТестинг) я слышу постоянно, я буду опираться на него.

Основные понятия и определения

Процитирую определения SQ с ПроТестинга:

Качество программного обеспечения (Software Quality) – это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [1061-1998 IEEE Standard for Software Quality Metrics Methodology]

Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [ISO 8402:1994 Quality management and quality assurance]

Хочу обратить внимание на годы, которые я выделил жирным. Стандарты, откуда взяты определения были выпущены больше 20 (!) лет назад. А что есть сейчас?

Ответ: ГОСТ Р ИСО 9000—2015. Тут у многих возникает реакция «Эм, а номера-то стандартов не бьются!». Верно, рекомендую погуглить самостоятельно и потратить время на изучения того, как менялись номера стандартов и один стандарт поглощал другие.

Вернемся к «Качеству». ГОСТ нам говорит следующее:

Качество (Quality) – степень соответствия совокупности присущих характеристик объекта требованиям.

Если сравнить его с предыдущими версиями, то слов стало меньше, а смысл стал более кристаллизованным. Из этого определения вытекает важный вывод: если вы не выдвинули требования, то и разговор про качество не имеет под собой основания. Качество само собой не появляется, оно требует затрат. Об этом развернуто говорится в разделе «2.2.1 Качество».

Приведу абзац из этого раздела:

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

Культура ест стратегию на завтрак? Да, но не только. Она «ест» всё, включая качество. Если вы не будете вкладываться в культуру, поощряющее качество, то можете забыть про него. Качество не может жить в отрыве от организации как системы.

Качество продукции и услуг организации определяется способностью удовлетворять потребителей и преднамеренным или непреднамеренным влиянием на соответствующие заинтересованные стороны.

Качество не может жить в отрыве и от тех, кто пользуется продуктом. Если не удовлетворять требования, которые основаны на пожеланиях пользователей, то продукт будет восприниматься некачественным. С другой стороны, если вы не рассказываете о своем продукте и о его предназначении, то ваш продукт будет воспринят неправильно и будет считаться некачественным.

И еще один абзац. Очень важный абзац:

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

Если мы не транслируем свою видение качества, политику в отношении качества, то восприятие наших продуктов потребителями может не совпасть с тем, какой мы ожидаем видеть.

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

Пойдем дальше и обсудим, что изменилось в определении: Обеспечение качества (Quality Assurance)

С сайта ПроТестинг:

Обеспечение качества (Quality Assurance) — это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта.

Согласно ГОСТ Р ИСО 9000-2015:

Обеспечение качества (Quality Assurance): Часть менеджмента качества, направленная на создание уверенности, что требования к качеству будут выполнены.

Что мне нравится в определении ГОСТа: ушли от всей многословности про мероприятия, этапы и прочее, а сфокусировались на сути – на обеспечение уверенности. Если задуматься, то это единственное, что вы можете сделать. Гарантировать на 100% нельзя ничего. А как вы будете обеспечивать эту уверенность – напрямую зависит от корпоративной культуры и политики качества.

Где-то это четко выраженные критерии приемки фичи в работу, где-то специальные договорные отношения или множество политик и инструкций. Как реализовать обеспечение качества компания выбирает сама. Но одно очевидно – это очень дорого.

Quality Control – а вот тут начинается самое интересное! Смотрим и сравниваем, верхнее определение взято с ПроТестинга, нижнее из ГОСТа:

Контроль качества (Quality Control) – это совокупность действий, проводимых над продуктом в процессе разработки, для получения информации о его актуальном состоянии в разрезах: «готовность продукта к выпуску», «соответствие зафиксированным требованиям», «соответствие заявленному уровню качества продукта».

Управление качеством (Quality control) – часть менеджмента качества, направленная на выполнение требований к качеству.

Внимательные уже заметили, что поменялся перевод. Теперь это управление качеством!

Из нового определения также ушла многословность, и остался фокус на выполнение требований, что, на мой субъективный взгляд, сделало его сильно лучше, в старом варианте. В основном потому что в нем присутствовало «…для получения информации…».

Что потом со всей этой информацией делать не уточнялось… В новом определении четко прописано: надо выполнять требования. Опять же, как вы это будете делать зависит от корпоративной культуры.

Например, политика качества предписывает, что тест кейсы должны быть максимально полные – это обеспечение качества. А управление качеством это:

проверка, что эти тест кейсы полные и достаточные;
проверка, что тестирование по ним выполняется в полном объеме.

Если соотнести определения с циклом Деминга-Шухарта, то обеспечение качества = планирование, часть выполнения и часть корректировки. А управление качеством – это часть выполнения, проверка и часть корректировки.

Теперь мы поговорим о том, что такое тестирование. Ниже даны два определения, первое взято c ПроТестинга, ниже – из ISO/IEC TR 19759:2015, он же SWEBOK.

Тестирование программного обеспечения (Software Testing) – проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004].

В более широком смысле, тестирование – это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Software testing consists of the dynamic verification that a program provides expected behaviors on a finite set of test cases, suitably selected from the usually infinite execution domain».

Официальный перевод отсутствует, поэтому ниже я приведу свой перевод. Альтернативные версии пишите в комменты под постом.

«Тестирование программного обеспечения это проверка того, что программа обеспечивает ожидаемое поведение на конечном наборе тестовых случаев, выбранных определенным образом из бесконечного набора тестовых случаев».

Определения если и изменились, то не сильно. В целом это уже проверка, и я полностью согласен с коллегами: это часть управления качеством.

А из всего вышесказанного получается вот такая картинка.

Пример

Про определения можно говорить много, долго и красиво. А как в жизни? Она же сложная, многогранная. Рассмотрим на простом примере, чем отличается тестирование от управления качеством и обеспечения качества.

Дисклеймер: пример, представленный ниже, является полностью вымышленным. Все совпадения случайны.

Знакомьтесь, компания Икс

Компания занимается продажей продуктов, дела у нее все хорошо. Сквозной процесс доставки ценности показан ниже:

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

Компания заботилась о качестве выпускаемых продуктов и доносила до клиентов, что тестирование выполняется на самом высшем уровне. И действительно, продукты компании были классные и здорово решали проблемы клиентов. Клиенты подумали, раз продукты такие хорошие, то и тесты, с помощью которых их проверяют, тоже хорошие, и эти данные помогут помочь уже с проверкой собственных бизнес процессов. И компания получила заманчивое предложение «Продайте нам ваши тесты, вот договор с открытой суммой». Компания решила «А почему бы и нет!».

Процесс поставки ценности приобрел следующий вид:

Теперь на выходе два артефакта: дистрибутив и тесты. Но возник вопрос от коллеги из ИБ: что у нас с персональными данными? В дистрибутиве их понятно нет, а в тестах? Как мы соблюдаем 152-ФЗ? А вдруг кто-то использовал свои ФИО или ФИО коллег для тестирования?

Согласно закону фамилия, имя и отчество трактуются как персональные данные. Я понимаю, что юристы тут много что могут сказать, но помните – у нас упрощенный пример.

Понятно, что можно попросить сотрудников подписать документы на передачу ПД, но мы сейчас чуть про другое. Мы рассматриваем кейс как нам обеспечить уверенность в том, что персональных данных в тестах нет. В качестве ПД рассматриваем только фамилию имя и отчество, сильно упрощаем под формат статьи. Что это все означает? В политику качества компании добавлено требование «В поставляемых тестах отсутствуют персональные данные». Реализуем его.

Тестирование

Идем от частного к общему. Подход к тестированию очень простой: нужно проверить, что в наших тестах нет ФИО сотрудников. Хороший тестировщик скажет, что неплохо бы пропустить ФИО через морфер, чтобы получить их в различных падежах.

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

Дешево и быстро. Если нашли ПД, то убрали их в выходном артефакте, и в тестах в системе управления тестированием. Кстати последнее уже больше про QC. Вопросов к такому подходу нет, проверили, молодцы, но выполняются ли требования к качеству? Нет. Например, в компанию устроился новый сотрудник, как он попадет в это список?

Здесь переходим на следующий уровень. Рассматриваем решение нашего кейса уже с точки зрения управления качеством.

Управлением качеством

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

В общем случае возможны два события, которые требуют добавления информации в список:

Сотрудник поменял ФИО. Всякое бывает;
В компанию пришел новый сотрудник.

Сразу возникает вопрос: почему не обновлять и когда информация удаляется из списка? Ответ на них один – никогда. Информация не удаляется и не обновляется, а только добавляется, таким образом мы гарантируем отсутствие ПД. Лучше, как говорится, перебдеть.

Процесс создания ценности становиться вот таким:

Уже хорошо, но нас будут постоянно преследовать две проблемы: ложноположительные и ложноотрицательные срабатывания. И сделать с ними ничего нельзя, ведь мы находимся в конце цепочки создания ценности, не влияем на предыдущие шаги. Более того, мы реагируем на уже свершившиеся события.

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

Обеспечение качества

Для того чтобы предотвратить попадание ФИО наших сотрудников в тестовые данные мы переходим на процедурную генерацию ФИО. Тестировщикам больше не надо придумывать ФИО для заполнения полей, за них это сделает процедура. Более того, тестировщикам запрещено использовать данные полученные не из процедуры. Процесс создания ценности становится следующим:

Какие плюсы мы получаем от такого подхода:

Обеспечиваем уверенность, что в созданных для тестирования данных не будет ФИО сотрудников. В самой процедуре реализованы проверки на то, что созданные ФИО отсутствуют в списке ФИО сотрудников;
Гарантируем, что они не будут похожи на «человеческие». Очень хорошая практика + еще одна ступень уверенности. Например, ФИО могут быть созданы в эльфийском стиле;
Гарантируем, что в них будут внедрены сигнатуры для быстрой скриптовой идентификации. Например, в начало и в конец вставлять букву «й»;
Обеспечиваем единую точку поставки тестовых данных;
Всё есть код! Обеспечивается прозрачный контроль над алгоритмом создания тестовых данных;
Приятный бонус: мы можем использовать наши процессы для обеспечения качества кода. Например, любые изменения возможно только после одобрения ИБ запроса на изменение.

Все эти меры обеспечивают нам уверенность в том, что требование «В поставляемых тестах отсутствуют персональные данные» будет выполнено. Но важно понимать, что это никак не отменяет тестирования выходных данных на наличие ПД.

Заключение

Определения не отлиты в граните, они меняются. То, что было справедливо в 1999 году, в 2022 может оказаться совершенно устаревшим. Одни стандарты сменяются другими, значения терминов изменяются со временем. Нам остаётся это только принять.

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

Качество программного обеспечения
software quality
гост
качество по
обеспечение качества
quality assurance
управление качеством
quality control
тестирование по
software testing

Блог компании Ростелеком
Тестирование IT-систем
Терминология IT

Обеспечение качества и тестирование программного обеспечения — основные понятия и определения

Качество программного обеспечения (Software Quality) — это степень, в которой программное обеспечение обладает требуемой комбинацией свойств.

Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

Обеспечение качества (Quality Assurance — QA) — это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО для обеспечения требуемого уровня качества выпускаемого продукта.

Контроль качества (Quality Control — QC) — это совокупность действий, проводимых над продуктом в процессе разработки для получения информации о его актуальном состоянии в разрезах: «готовность продукта к выпуску», «соответствие зафиксированным требованиям», «соответствие заявленному уровню качества продукта».

Тестирование программного обеспечения (Software Testing) — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, которые были определены в начале текущей фазы.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

План Тестирования (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Тест дизайн (Test Design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с определенными ранее критериями качества и целями тестирования.

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

Баг/Дефект Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования с указанием причин и ожидаемого результата.

Тестовое Покрытие (Test Coverage) — это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.

Детализация Тест-Кейсов (Test Case Specification) — это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию.

Время Прохождения Тест Кейса(Test Case Pass Time) — это время от начала прохождения шагов тест-кейса до получения результата теста.

Качество программного обеспечения

Каждый день в своей работе мы сталкиваемся с достаточно абстрактным понятием «качество ПО» и если задать вопрос тестировщику или программисту «что такое качество?», то у каждого найдется своё толкование. Рассмотрим определение «качества ПО» в контексте международных стандартов:

Качество программного обеспечения — это степень, в которой ПО обладает требуемой комбинацией свойств.

Качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

Характеристики качества ПО

Функциональность (Functionality) — определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает то, что ПО работает исправно и точно, функционально совместимо соответствует стандартам отрасли и защищено от несанкционированного доступа.

Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость.

Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.

Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности, в соответствии с выделенными ресурсами, временем и другими обозначенными условиями.

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

Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/ hardware) в другое.

Модель качества программного обеспечения

На данный момент, наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки.Рис.1. Модель качества программного обеспечения (ISO 9126-1)

Кто такой тестировщик и что он делает

Если поискать информацию по ключевым фразам из названия этой главы,то можно найти уйму совершенно противоречивых ответов. И дело здесь, в первую очередь, в том, что авторы большинства «должностных обязанностей» приписывают всей профессии некий утрированный набор характеристик отдельных её представителей.

В начале карьеры любой специалист (и тестировщик не является исключением) является исполнителем и учеником. Достаточно хорошо понимать, что такое тест-кейсы, отчёты о дефектах, уметь читать требования, пользоваться парой инструментальных средств и хорошо уживаться в команде.

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

Если выразить образно главную цель тестировщика, то она будет звучать так: «понимать, что в настоящий момент необходимо проекту, получает ли проект это необходимое в должной мере и, если нет, то как изменить ситуацию к лучшему». Звучит похоже на цель руководителя проекта, верно? Верно. Начиная с некоторого уровня развития, IT-специалисты, по большому счёту, различаются лишь наборами технических навыков и основной областью приложения этих навыков.

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

Знание иностранных языков. Да, это не технический навык. Но, тем не менее, он идёт под номером «ноль». Можете считать это аксиомой: «нет знания английского — нет карьеры в IT». Другие иностранные языки тоже приветствуются, но английский первичен.
Уверенное владение компьютером на уровне по-настоящему продвинутого пользователя и желание постоянно развиваться в этой области. Можете ли Вы представить себе профессионального повара, который не может пожарить картошку (не «не обязан», а «не умеет в принципе»)? Выглядит странно? Не менее странно выглядит «IT’шник» (именно так, в кавычках), неспособный набрать вменяемо отформатированный текст, скопировать файл по сети, развернуть виртуальную машину или выполнить любое иное повседневное рутинное действие.
Программирование. Оно на порядок упрощает жизнь любому IT’шнику, а тестировщику — в первую очередь. Можно ли тестировать без знания программирования? Да, можно. Можно ли это делать по-настоящему хорошо? Нет. И сейчас самый главный (почти религиозно-философский) вопрос: какой язык программирования изучать? C/C++/C#, Java, PHP, JavaScript, Python, Ruby и т.д. — начинайте с того, на чём написан ваш проект. Если проекта пока ещё нет, начинайте с JavaScript (на текущий момент — самое универсальное решение).
Базы данных и язык SQL. Здесь от тестировщика тоже не требуется квалификация на уровне узких специалистов, но минимальные навыки работы с наиболее распространёнными СУБД и умение писать простые запросы можно считать обязательными.
Понимание принципов работы сетей и операционных систем. Хотя бы на минимальном уровне, позволяющем провести диагностику проблемы и решить её своими силами, если это возможно.
Понимание принципов работы веб-приложений и мобильных приложений. В наши дни почти всё пишется именно в виде таких приложений, и понимание соответствующих технологий становится обязательным для эффективного тестирования.

Надеюсь, Вы обратили внимание на то, что самого тестирования в списке нет. Всё верно, ведь ему посвящена вся эта книга целиком, так что позволим себе не копировать её сюда.

Также отметим личностные качества, позволяющие тестировщику быстрее стать отличным специалистом:

Повышенная ответственность и исполнительность;
хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать свои мысли;
терпение, усидчивость, внимательность к деталям, наблюдательность;
хорошее абстрактное и аналитическое мышление;
способность ставить нестандартные эксперименты, склонность к исследовательской деятельности.

Да, сложно найти человека, который бы в равной мере обладал всеми перечисленными качествами, но всегда полезно иметь некий ориентир для саморазвития.

Откуда берутся ошибки в ПО?

Почему бывает так, что программы работают неправильно? Все очень просто – они создаются и используются людьми. Если пользователь допустит ошибку, то это может привести к проблеме в работе программы – она используется неправильно, значит, может повести себя не так, как ожидалось.

Ошибка (error) – это действие человека, которое порождает неправильный результат.

Однако программы разрабатываются и создаются людьми, которые также могут допускать (и допускают) ошибки. Это значит, что недостатки есть и в самом программном обеспечении. Они называются дефектами или багами (оба обозначения равносильны). Здесь важно помнить, что программное обеспечение – нечто большее, чем просто код.

Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы.

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

Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result).

Сбой в работе программы может являться индикатором наличия в ней дефекта.

Таким образом, баг существует при одновременном выполнении трех условий:

известен ожидаемый результат;
известен фактический результат;
фактический результат отличается от ожидаемого результата.

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

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

Всего существует несколько источников дефектов и, соответственно, сбоев:

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

Дефекты могут возникать на разных уровнях, и от того, будут ли они исправлены и когда, будет напрямую зависеть качество системы.

Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям.

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

Требование (Requirement) – потребность или ожидание, которое установлено. Обычно предполагается или является обязательным.

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

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

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

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

Условно можно выделить пять причин появления дефектов в программном коде.

Недостаток или отсутствие общения в команде. Зачастую бизнес-требования просто не доходят до команды разработки. У заказчика есть понимание того, каким он хочет видеть готовый продукт, но, если должным образом не объяснить его идею разработчикам и тестировщикам, результат может оказаться не таким, как предполагалось. Требования должны быть доступны и понятны всем участникам процесса разработки ПО.
Сложность программного обеспечения. Современное ПО состоит из множества компонентов, которые объединяются в сложные программные системы. Многопоточные приложения, клиент-серверная и распределенная архитектура, многоуровневые базы данных – программы становятся все сложнее в написании и поддержке, и тем труднее становится работа программистов. А чем труднее работа, тем больше ошибок может допустить исполняющий ее человек.
Изменения требований. Даже незначительные изменения требований на поздних этапах разработки требуют большого объема работ по внесению изменений в систему. Меняется дизайн и архитектура приложения, что, в свою очередь, требует внесения изменений в исходный код и принципы взаимодействия программных модулей. Такие текущие изменения зачастую становятся источником трудноуловимых дефектов. Тем не менее, часто меняющиеся требования в современном бизнесе – скорее правило, чем исключение, поэтому непрерывное тестирование и контроль рисков в таких условиях – прямая обязанность специалистов отдела обеспечения качества.
Плохо документированный код. Сложно поддерживать и изменять плохо написанный и слабо документированный программный код. Во многих компаниях существуют специальные правила по написанию и документированию кода программистами. Хотя на практике часто бывает так, что разработчики вынуждены писать программы в первую очередь быстро, а это сказывается на качестве продукта.
Средства разработки ПО. Средства визуализации, библиотеки, компиляторы, генераторы скриптов и другие вспомогательные инструменты разработки – это тоже зачастую плохо работающие и слабо документированные программы, которые могут стать источником дефектов в готовом продукте.

Принципы тестирования

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

1. Тестирование показывает наличие дефектов

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

2. Исчерпывающее тестирование невозможно

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

3. Раннее тестирование

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

4. Скопление дефектов

Разные модули системы могут содержать разное количество дефектов, то есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.

5. Парадокс пестицида

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

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок.

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

И еще несколько важных принципов:

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

Верификация и валидация

Эти два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.

Верификация (verification)– это процесс оценки системы или её компонентов с целью определения того, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. То есть выполняются ли задачи, цели и сроки по разработке продукта.

Валидация (validation)– это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

Следующая таблица поможет выделить ключевые отличия между этими понятиями:

С помощью валидации Вы можете быть уверенным в том, что создали «правильный» продукт. Продукт, который полностью удовлетворяет заказчика.

С помощью верификации Вы можете увериться в том, что продукт сделан «правильно»: придерживаясь необходимых методик, инструментов и стандартов.

На практике отличия верификации и валидации имеют большое значение:

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

QA, QC и тестирование

Так в чем же разница между QA и тестированием и что такое Quality Control?

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

Можно оформить их соотношение в виде таблицы:

Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA.

Иными словами, Quality Assurance обеспечивает правильность и предсказуемость процесса, в то время как Quality Control предполагает контроль соблюдения требований. Тестирование же, в свою очередь, обеспечивает сбор статистических данных и внесение их в документы, созданные в рамках QC-процесса.

Если провести аналогию с процессом конструирования, скажем, велосипеда, то получим такую картину:

С помощью тестирования мы можем определить, работают ли все детали и сам велосипед в целом так, как мы ожидаем. Из правильных ли материалов он сделан, с применением нужных методик и инструментов или нет. То есть подразумевается, что тестируемый объект уже существует.
Задачей же QA является обеспечение соответствия всех этапов конструирования нашего велосипеда определенным стандартам качества, начиная с планирования и создания чертежей и заканчивая сборкой уже готового велосипеда. То есть качеству объекта внимание уделяется еще до создания самого объекта.

results matching » «

No results matching » «

Про Тестинг

Добрый день, Рад, что наконец смогу поделиться со всеми, тем что давно уже изучаю, исследую и обдумываю. А именно это вопрос определений Обеспечение качества (Quality Assurance), Контроль качества (Quality Control), Тестирование ПО (Software Testing). Казалось бы все просто и ясно, но на самом деле эти понятия связаны между собой, переплетены и запутаны. И как оказывается, нет единого мнения о том, что они представляют из себя.

В течении недели я проводил небольшой опрос среди своих коллег, занимающих разные позиции в разных компаниях, связанных и не связанных с тестированием и обеспечением качества и разработкой ПО. Было опрошено 15 человек: 3 тест менеджера, 1 руководитель группы тестирования, 2 ведущих тестировщика, 6 тестировщиков, 2 разработчика, 1 человек не имеющий отношения к разработке и тестированию вообще. Цифра конечно не большая, но уже из нее видно, что более менее адекватное и правильное определение этих понятий имеют не более половины опрошенных, что само по себе ужасно. Получается что половина опрошенных не понимают что такое качество, и как его достигать, а так как в основном отвечали на вопросы люди отвечающие за качество, то получается, что половина из них не до конца понимает, чем занимается.

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

Не буду вдаваться в подробности темы обучения тестировщиков, так как она часто поднимается и уже, я думаю, что достаточно раскрыта. Речь идет о понятих Обеспечение качества (Quality Assurance), Контроль качества (Quality Control), Тестирование ПО (Software Testing).

До проведения опроса мое понимание данных определений было следущим:
Тестирование (Testing) — совокупность действий проводимых над объектом тестирования, а именно применение различных видов тестирования, для получения результата о его соответствии поставленным требованиям.
Контроль качества (Quality Control) — совокупность мероприятий проводимых в процессе разработки, для постоянного получения исчерпывающей информации о соответствии объекта тестирования поставленным требованиям. Сюда входят Test Management, Test Analysis, Test Design, Testing and etc.
Обеспечение качества (Quality Assurance) — совокупность мероприятий, охватывающих все подразделения компании, предпринимаемых на разных стадиях разработки, для улучшения качества выпускаемого продукта. Сюда входят, оптимизация имеющихся процессов: бизнес-анализа, проектирования, разработки, тестирования и т.п.

Но, проанализировав все полученные ответы, а также посоветовавшись с авторитентными людьми, я пришел к выводу, что понятие тестирования, представленное выше, слишком узко и сводится к банальному исполнению тестов (Test Execution). Немного переосмыслив могу резюмировать следующее:

QA (Quality Assurance, Обеспечение качества) — совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации ПО информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения качества выпускаемого продукта.
QC (Quality Control, Контроль качества) — совокупность действий проводимых над объектом тестирования в процессе разработки для получения информации об актуальном состоянии объекта тестирования в разрезах: «готовность Продукта к выпуску«, «Соответствие зафиксированным требованиям«, «Соответствие заявленному уровню качества продукта«.
Software Testing является одной из техник контроля качества и включает в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

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

Как все мы знаем: «Истина где-то рядом.» Поэтому буду рад получить от вас комментарии и дополнения, которые приблизят нас еще на один шаг к правде о том, чем мы всетаки занимаемся. И кто знает, может нас ждет еще одна статья, в которой придется дополнить сделанные выводы.

Большое спасибо, всем, кто участвовал в опросе, а так же отдельное спасибо, Славе Панкратову, за качественные комментарии к предыдущей статье о разнице между QA, QC, Testing, которые сподвигли меня к проведению опроса и написанию этого материала.

Оригиналы ответов на опрос о разнице между Quality Assurance, Quality Control и Testing, можно найти здесь

5 комментариев:

я прочитал обе статьи. Считаю что данные определения вполне пригодны. Хороший шаг для определения собственой «системы координат», в отношение которой в дальнейшем можно строить теории или практики. Мне кажется, что нельзя дать единственно правильного и неоспоримого определения для этих терминов. Почему? Приведу аналогию с физическими системами измерений. Нельзя сказать, что измерять длину в метрах правильно, а в дюймах нет. И даже если вдруг получится сформулировать «идеальное» определение того что такое тестирование, QA итд., вовсе не факт, что оно будет принято и пониматься всеми одинаково.
Подавляющее большинство людей работающих в ИТ считают, что QA==Testing. Это все-равно, что говорить что системный архитектор и программист — одно и тоже. Еще это показатель общей безграмотности кадров, работающих в ИТ. Причем такие люди зачастую занимают руководящие посты в разных компаниях. Ужас. Так что проблемы с образованием не только в области обеспечения качества.

Мое мнение, что та или иная специализация, может характеризоваться обязанностями и действиями. Но, к сожалению, а может быть и к счастью, в области обеспечения качества некоторые активности могут относится к нескольким специализациям. Например, такая активность, как планирование тестирования, может быть как частью тестирования(IEEE Std 829 — Test Plan), так и частью QA(IEEE Std 730 — Software QA Plan). Но есть и такие, которые нельзя попутать, например, формализацию процесса работы с дефект-трекером — к активностям тестирования отнести сложно.

Я полностью согласен с картинкой из первой статьи. Где QA включает QC включает Testing. Это логически понятно из самих названий. Рассуждения таковы: чтобы обеспечивать качество продукта, нужно постоянно контролировать это качество (например от билда к билду, от версии к версии). В свою очередь для того чтобы проконтролировать качество, нужно сделать какие-то акции, провести эксперименты.

Теперь попробую дать определения так, как я это вижу в своей «системе координат».

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

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

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

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

Еще я склонен согласится с тем, что все три роли могут быть объеденены в одну. Хотя бы потому что я сейчас сижу на всех трех стульях — я тестирую (провожу эксперименты), я контролирую качество (оцениваю, что билд номер N — есть релиз, т.к. он удовлетворяет критериям) и обеспечиваю качество (формализую процессы, участвую в обсуждениях архитектуры проекта). Конечно, хотелось бы больше сосредоточиться на последних двух областях, но. Ответить Удалить

В целом я согласен и с материалом статьи, и с предыдущим комментарием.
Но у меня есть некоторые замечания, которые я и хочу изложить:
1. В определении QC, на мой взгляд,»готовность Продукта к выпуску» как раз и определяется на основании «Соответствия зафиксированным требованиям» и «Соответствия заявленному уровню качества продукта».
2. Не согласен с тем что Test Management есть планирование тестирования и является частью Testing. Планирование тестирования — это планирование тестирования, и ни что иное и в мировой практике зовется как Software Test Planning (STP). А Test Management — скорее часть QA поскольку включает и контроль качества самих тестов, и оценку достаточности покрытия тестами тестируемой области (соответствие тестплану), и контроль версий тестов, а также контроль документирования результатов тестирования (фиксирование статуса выполнения отдельно взятого теста).
3. Не согласен с формулировкой о том, что планирование тестирования «может быть» частью тестирования и частью QA. Скорее хошее планирование тестирования позволяет решить и задачи тестирования, и задачи QC и QA. Поясню. Тестплан, это не просто статический документ написанный один раз перед тем как начать тестирование и после этого благополучно забытый. К ранее написанным тестпланам возвращаешься и в процессе тестирования и после рализа. Пока тестирование не закончено, тестплан может изменяться.
Грамотно составленный тестплан позволяет:
— провести анализ дизайна продукта (в глобальном смысле, а не GUI) с точки зрения того что уже воплощено, что еще предстоит воплотить и какие проблемы возникли уже на данном этапе, при этом оценить вероятность появления изменений к требованиям и, по возможности, сами эти изменения, обсудить эти изменения с разработчиками и продуктменеджером (это нужно продолжать делать и тогда, когда тестирование уже идет полным ходом, давая новую пищу для анализа);
— оценить проектные риски с точки зрения качества в момент когда разработка уже начата, а значит когда уже появилась динамика рисков;
— определить интеграционные моменты смежных продуктов или компонентов которые требуется учесть при тестировании, а значит и методы и степень взаимодействия смежных подразделений внутри проекта и за его пределами;
— определить методы и подходы к тестированию;
— предъявить требования к минимальному покрытию тестами;
— предъявить требования к лабораторному оборудованию, необходимому для тестирования;
— определить критерии готовности продукта к выпуску, включая требования к уровню качества.
— определить сроки тестирования.
4. Далее, цитата: «QA, это превентивные действия, попытка недопустить появление дефектов.» — Красиво и наивно. Попробуйте недопустить нашествие саранчи. Будьте готовы к тому, что дефекты так или иначе будут.
Скорее задача QA состоит в следующем:
— сократить разницу во времени между началом разработки и началом тестирования
— сократить время обнаружения дефектов
— сократить время исправления дефектов
— минимизировать количество ложных обнаружений дефектов и сократить время идентификации таких ложных дефектов
а в нескольких словах: сократить стоимость исправления дефектов (чем раньше дефект найден — тем дешевле он нам обошелся) и как следствие — суммарную стоимость проекта!
5. В больших и средних проектах разница между QC и Testing проявляется в том, что трекинг готовности продукта осуществляют не те кто его непосредственно тестирует, а их менеджеры, опираясь на отчеты о готовности отдельных фич, приемочного тестирования и прочие критерии готовности продукта, такие, например, как допустимый процент неисправленных дефектов, отсутствие дефектов блокирующих релиз.
6. Цитата: «Еще я склонен согласится с тем, что все три роли могут быть объеденены в одну.» — Очень неблагодарное допущение. Точно так же как не стоит доверять контроль качества продукта программисту, не стоит доверять и контроль качества тестирования продукта инженеру, выполняющему тестирование. А в сколь-нибудь большом проекте это просто невозможно.

А еще, я не нашел явного упоминания об одной, жизненно важной для продукта роли QA, которую не осуществить средствами одного QC.
Это экспертная оценка продукта силами департамента QA или независимыми экспертами (хотя-бы бэта тестерами, но так или иначе квалифицированный департпмент QA принимает в этом участие с самого начала разработки).
Что имеется ввиду? — Неформальная оценка способности продукта решить те бизнес задачи, которые на него возлагает отдел маркетинга или заказчик.
Она на, мой взгляд, должна включать, как минимум:
— оценку качества технических требований к продукту и их соответствие бизнес требованиям (осуществляется до начала разработки);
— оценку способности продукта обеспечить те бизнес процессы потенциального покупателя или заказчика которые достаточны для того, чтоб продукт был востребованным и конкурентноспособным;
— оценку удобства использования продукта для целевой группы пользователей (равно как и оценку правильности выбора целевой группы). Ответить Удалить

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

1. «готовность Продукта к выпуску» может и связана с «Соответствия зафиксированным требованиям» и «Соответствия заявленному уровню качества продукта», но это никак не одно и тоже, а одни из его составляющих.

2. Тест менеджмент и планирование это по существу одно и тоже, если включить в понятие планирования то что вы написали, а именно:
— контроль качества тестов,
— оценку достаточности покрытия тестами тестируемой области,
— контроль версий тестов,
— контроль документирования результатов тестирования
и т.д.
Все эти активности должны быть спланированы. А вот QA уже должно убедиться в том, что это было сделано 🙂 Так что я упорно продолжаю разделять тест менеджмент и QA.

3. Ну если для вас тестинг это просто кликинг, то вы можете не включать планирование в него. А по поводу тест плана у меня вопросов нет и быть не может — это другая тема, которую можно начать в моей статье по планированию тестирования.

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

5. Да не важно кто все это делает. В маленьких конторах есть 1 тестер, который и QC и QA одновременно. Да и вообще мы не конкретизируем здесь, а смотрим на вопрос в общем.

6. без комментариев, опять конкретика.

————
И теперь по поводу экспертной оценки.
Все что вы говорите подпадает под определенны виды тестирования:
— Requirements Testing
— Business Cycle Testing
— User Interface Testing / Usability Testing
А это уже тестирование, и значит тестировщики этим должны заниматься.

А по поводу экспертной оценки, хотите ее получить, наймите людей со стороны 🙂

Спасибо за ваши комментарии.
Алексей. Ответить Удалить

Алексей, то что у каждого своя точка зрения — это абсолютно нормально 🙂
Благодаря этому QA и дает столь ценный результат.
Проблема не в том что «Мы говорим практически об одних и тех же вещах. «, а в том что мы понимаем их по-разному. Многие могут похвастаться знанием формального RUP и бесконечно долго говорить о нем, но на практике у всех получаются разные результаты. Мое мнение таково, что уже время не просто обобщать теоретические знания, а анализировать и систематизировать практический опыт нарабатывая так называемые «Best Practices», которые позволили бы отобразить RUP на реальные проблемы, с которыми сталкиваются современные проекты.

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

1. Здесь я абсолютно того же мнения, но хотел подчеркнуть связь между составляющими, и именно такую, как я указал.

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

3. Здесь я имел ввиду как раз противоположное 🙂 а именно, насколько важно планирование и для тестирования, и для QC, и для QA, и какие задачи оно решает именно для них. И уделил специально для для этого особое место перечислению этих задач, чтоб показать, насколько тесно они связаны в тестплане. Если принадлежность какой-либо задачи какому-то из понятий не очевидна —
это, возможно, мое упущение.

4. Может вам покажется странным, но это скорее я смотрю на задачу QA шире чем вы.
То, о чем говорите вы:
— взаимодействие между командами
— планирование выполняемых работ
— разработка шаблонов
— и многое-многое другое о чем еще можно упомянуть.
скорее точки воздействия на процесс для достижения конечной цели, но не сами цели.
Однако не зная конечной цели, вы не можете знать как нужно эффективно воздействовать на процесс.
Приглядитесь, все 3 пункта что вы назвали, так или иначе способны внести свой вклад в дело сокращения стоимости
исправления дефектов:
— взаимодействие между командами — быстрый и прозрачный обмен информацией, четкие формулировки, свободное и четко
регламентированное общение, минимум шума в информации позволят быстро идентифицировать дефекты и находить их причины
— планирование выполняемых работ — и так все ясно, планируйте наиболее трудоемкие и рискованные задачи на более ранние этапы, ставьте задачам на исправление критических дефектов максимальный приоритет, и т.д.
— разработка шаблонов — если речь идет о шаблонах документов — выносите место для наиболее важной информации вперед, предоставьте удобный способ описания деталей.
Так ваши воздействия приобретут направленный вектор подчиненный единой цели, что и обеспечит эффективность воздействия.
Есть такая поговорка: «О чем бы не говорилось — это всегда о деньгах». Возможно это и банально звучит, но бюджет коммерческого проекта не будет тратиться на то, что не помогает получить
прибыль или сэкономить деньги. поскольку коммерческие проекты тратят деньги на QA (и даже больше чем некоммерческие), то стоит предположить, что заслугу QA можно
оценить в денежном эквиваленте. Ответьте сначала на такие вопросы, прежде чем размышлять об этом дальше:
— Что в вашем понимании есть «качество» (самоцель или инструмент для достижения другой цели)? Если инструмент, то достижению какой цели он служит?
— Как вы измеряете качество в общем?
— Как вы оцениваете суммарную эффективность своих методов достижения качества?
Что, озадачил.
Так вот, на Западе есть такое понятие: «Удельная Стоимость Дефекта». Чем раньше дефекты обнаруживаются и исправляются, тем затраты на их исправление меньше, а значит меньше и удельная стоимость этих затрат. Чем меньше удельная стоимость, тем эффективнее, считается, QA в проекте.
Как можно измерить затраты на исправление? — если дефект повлиял на сроки проекта, что повлекло дополнительные затраты на продление проекта, или, еще хуже, понизил имидж проекта будучи обнаруженным после релиза, что привело к потерям продаж,
то очевидно, что стоимость его исправления обошлась в эти дополнительные затраты и непредвиденные убытки; любой другой дефект обошелся в суммарные (и запланированные) человекочасы тех инженеров, которые были задействованы при его обнаружении и исправлении, чем они меньше — тем затраты меньше (и тем больше запланированных человекочасов у нас осталось для выполнения других задач проекта, в том числе, и не связанных с QC и QA вовсе). Как вы думаете, здесь связь с показателем успешности проекта в целом не прослеживается.
Может это сразу и не очевидно, но связь между удельной стоимостью дефекта и эффективностью QA прямая.
Как? — примерно вот так:
Чего мы ждем от QA?
Качества выполнения всех этапов необходимых для получения конечного конкурентноспособного продукта в сроки, установленные проектным планом.
Что нам дает качество?
Гарантию того, что вероятность обнаружения недопустимых дефектов после релиза или сдвига сроков
релиза ввиду обнаружения недопустимых дефектов в предрелизный период будет минимальной.
Отсюда, чем меньше удельная стоимость дефекта, тем надежнее эта гарантия.
Зачем нам нужна такая гарантия?
Мы рассчитываем получить ожидаемую прибыль от продажи продукта и не получить неожиданных потерь этой прибыли.
По сути, это показатель успешности проекта.
Скажите, кто-нибудь станет заявлять что в успешном проекте неэффективный QA? — никогда.

5. В предыдущем комментарии зашла речь о том, что на практике Тестирование и QC совмещаются — я лишь отметил что на самом
деле все зависит от размеров департамента QA и в своей практике частенько наблюдал иное, о чем и написал.
А то, о чем говорите вы — это не совмещение в 1м тестере и QC и QA. Это полное отсутствие QA. Опять таки, исхожу из своего опыта и информации получаемой о QA в разных компаниях. Я частенько общаюсь с тестерами других компаний и знаю специфику
работы тестера-одиночки.

6. Тоже было высказывание в предыдущем комментарии. Я категорически не согласен что роль QC и QA можно совмещать.
Это не только вредно для QA, но еще и практически невозможно охватить одному человеку при грамотном QA. Это я тоже
заявляю исходя из своей практики.

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

Как вы это сделаете без экспертной оценки представителей целевой группы пользователей?
А теперь, представьте, что продукт гораздо более сложен и специфичен и ваши тестеры вообще не эксперты в предметной области, и что целевых групп пользователей несколько, они перекрываются, и специфика их задач очень различна в рамках предметной области, а ваши тестеры де-факто не попадают ни в одну из них, кроме того ваш продукт предназначен не для всех групп пользователей в рамках предметной области.
Вы все еще считаете что экспертная оценка всего лишь моя прихоть.
Я вам больше скажу, у ваших тестеров не будет достаточно знаний даже для того чтобы выполнить те формальные RUPовские
типы тестирования, что вы назвали (которые кстати, едва покрывают треть поднятых мною проблем):
— Requirements Testing — покрывают качество описания самих ребований, но не полноту согласно бизнес требованиям, это вообще делается
не формальным тестированием, а аналитикой, а часто Requirements Testing на практике вообще не применяется, потому что сами требования изначально не выдерживают никакой критики или просто отсутствуют, а оценить потенциальную конкурентноспособность продукта все равно надо.
— Business Cycle Testing — часто выполняются именно третьей стороной (экспертами, заказчиком, бэта тестерами) на ее оборудовании, включают набор use-case’ов, которые обеспечиваются функциональностью продукта, выполняются в течении длительного времени со съемом
множества метрик включая контроль стабильности, а так же Capacity (или по RUPовски Volume) базы данных если речь идет о клиент-серверной системе, могут быть частично автоматизированы. Но при этом сама полнота набора use-case’ов согласно RUP никак не оценивается, что опять таки — минус.
— User Interface Testing / Usability Testing — эти 2 понятия вообще недопустимо смешивать. Это разные вещи. Usability не имеет ничего общего с тестированием функциональности пользовательского интерфейса, оно лишь проводится на пользовательском интерфейсе равно как и на многих других возможных компонентах продукта, но тип тестирования и тесткейсы совсем другие, и не всегда человек не разбирающийся в предметной области
способен провести его самостоятельно, а тем более написать к нему тесты. Здесь речь также об удобстве использования невизуальных компонентов,
если таковые имеются и администрирования, например, распределенного клиент-серверного продукта и т.д. А удобство пользовательского интерфейса —
лишь часть этого типа тестирования. А теперь представьте что вам нужно протестировать Usability стратегического бомбардировщика.
Все тестируйте: удобство ведения боя, навигации, пилотирования, обслуживания, наземной транспортировки, и т.д. Сильно это будет связано с User Interface Testing. А без эксперта в выполнении тестов только Usability вы сами справитесь? А сколько экспертов вам понадобятся?

Так вот, исходя из вышеизложенного, как вы считаете, попадают ли в область ответственности QA взаимодействия со структурами внешними по отношению к проекту, такими как например, бэта тестеры, представители заказчика (если таковые имеются), ваш собственный техсаппорт?
Отвечу сам — ДА!
Это как то имеет отношение к Quality Control?
Тоже отвечу сам — напрямую — вообще никак, ведь продукт и проект продолжают в этом случае изменяться и получать новые задания даже тогда, когда все требования по Quality Control формально уже соблюдены.

Это я и имел ввиду говоря об экспертной оценке.

Обеспечение качества. Фундаментальная теория

Обеспечение качества — основные понятия и определения

1) Качество программного обеспечения (Software Quality) — это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [1061-1998 IEEE Standard for Software Quality Metrics Methodology]
2) Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [ISO 8402:1994 Quality management and quality assurance]

Обеспечение качества (Quality Assurance — QA) — это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта.

Контроль качества (Quality Control — QC) — это совокупность действий, проводимых над продуктом в процессе разработки, для получения информации о его актуальном состоянии в разрезах: «готовность продукта к выпуску«, «соответствие зафиксированным требованиям«, «соответствие заявленному уровню качества продукта«.

Тестирование программного обеспечения (Software Testing) — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].