Нажимаем на кнопку – получаем ошибку

      Расскажу про еще одну довольно-таки часто встречающуюся ошибку: использование для срабатывания кнопки метода keyDown вместо keyUp. Обычно такие ошибки появляются, когда программисты не понимают, как разница этих методов повлияет на поведение программы.
      В результате, нажав на странице на кнопку, которая срабатывает по keyDown и удерживая ее, действие будет выполняться до тех пор пока мы не отпустим кнопку. То есть вместо одного запроса будет выполнено несколько, или форма будет сохранена несколько раз и т.п.
      Найти такую ошибку довольно просто: наводим на кнопку указатель мыши, нажимаем и удерживаем кнопку. Или переходим к кнопке, нажимаем на Enter и удерживаем некоторое время. Если в результате страница не зависла, в базе не создались дубликаты, не начали открываться миллионы одних и тех же окон, то критичного бага тут нет)))
      Однако, если проверяемое приложение требует особой надежности, и есть сомнения в том, какой метод срабатывания был использован, то все же нужно привлекать программистов и смотреть код.

Ограничение длины поля: считайте правильно!

      Эта ошибка встречается довольно-таки часто, поэтому я решила, что о ней стоит написать.

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

      Вроде бы всё.  Кажется, что проблем с сохранением этого поля быть не должно… Но тут все же может оставаться ошибка. Дело в том, что программисты зачастую при проверке введенного значения считают, что максимальная длина поля равна длине колонки в базе данных. Но ведь длина в базе указывается в байтах, а в поле вводятся символы, которые могут занимать от 1 до 3 байт! То есть реально возможное значение, которое нужно сохранить, будет примерно вдвое меньше длины колонки.

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

      Будьте внимательны, проверяйте правильно. Ну а «Ё» нам поможет)))

Слайдкаст «10 принципов Agile тестировщика»

       Замечательный вдохновляющий слайдкаст от Андрея Дзыни «10 принципов Agile тестировщика». Вроде бы все перечисленные правила очевидны сами по себе, но к каждому пункту даются хорошие советы и рекомендации (где прочитать про техники тест-дизайна, как задавать вопросы программистам...). Все очень хорошо и по существу.

       Вот сами правила:

1. Быть смелым и решительным
2. Задавать неудобные вопросы
3. Обладать техническими знаниями
4. Дружить с программистом
5. Знать все практики тест дизайна
6. Исследовать и экспериментировать
7. Смотреть по сторонам
8. Заряжать духом тестирования
9. Приносить ценность продукту
10. Постоянно улучшаться

Экономическая выгода от автоматизации тестирования

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

      При определении необходимости автоматизации может быть предложен следующий алгоритм:
 

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

      2. Необходимо разбить функциональность системы на небольшие функциональные модули. Разбиение должно быть как можно более детальным – чем меньше подмодули, тем оптимальнее будет оценено покрытие автотестами.

      3. Для каждого из модулей оценивается время как на ручное тестирование, так и на автоматизированное:

            Tdev - время, необходимое для разработки автоматического теста.
            Tman – время, затрачиваемое на ручное тестирование.
            Tref – среднее время, необходимое для изменения автоматического скрипта после изменения функциональности.
            Tref_manual - среднее время, необходимое для изменения автоматического скрипта после изменения функциональности
            nregression - относительное количество тестов, прогоняемых без изменений
            Ntotal – общее количество итераций тестирования функционала за предполагаемое время жизни функционала (системы).
      Тогда для расчета общего количества времени, затрачиваемого на ручное и автоматическое прохождение тестов на всех итерациях жизненного цикла системы, могут быть применены формулы:

            Tmanual_total = Ntotal * Tman + Ntotal * (1-nregression)* Tref_manual  

            Tautomated_total = Tdev + Ntotal *(1- nregression )* Tref

      Автоматизация будет выгодной (при использовании бесплатных инструментов тестирования) при выполнении условия

            Tmanual_total ≤ Tautomated_total

      Для расчёта выгоды автоматизированного тестирования с использованием коммерческих инструментов тестирования, необходимо рассчитать стоимость ручного и автоматизированного тестирования:
           ∑(Tmanual_total ) – сумма трудозатрат на ручное тестирование частей функционала, которые предполагается тестировать автоматически.
            ∑(Tmanual_total ) – сумма трудозатрат на автоматическое тестирование частей функционала, которые предполагается тестировать автоматически.
            St – себестоимость тестировщика.
            Stesting_tool – себестоимость инструмента тестирования
            Npart – удельный вес трудозатрат на тестируемый продукт среди продуктов, которые тестируются соотвествующим коммерческим инструментом тестирования.
      Расчет стоимости ручного и автоматизированного тестирования производится по формулам:

            Cmanual = ∑(Tmanual_total ) * St

            Cautomated = ∑(Tautomated_total ) * St + Stesting_tool*Npart

      Критерий выгоды автоматизации при использовании коммерческих инструментов тестирования:
            Сmanual ≤ Сautomated

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

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

Недостатки автоматизации тестирования

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

1. Может быть неправильно оценён масштаб возможного покрытия системы автоматическими тестами, например, при попытке автоматизации того, что не должно быть автоматизировано. В таком случае процесс автоматизации становится неоправданно долгим и дорогим.
2. Очевидно, что наибольший эффект можно получить при автоматизации регрессионного тестирования, однако именно этот вид автоматизации имеет наибольшее количество минусов. Регрессионное тестирование используется для проверки новых версий, часто содержащих в себе большое количество дополнений и исправлений по сравнению с предыдущими версиями. При изменении в программе, тест уже не понимает, где произошло улучшение, дополнение, нововведение, а где ошибка. Поэтому всегда необходимо проверять актуальность используемого автоматического теста. 
3. При автоматизации регрессионного тестирования может случиться так, что вследствие изменений функциональности разработанный тест не может быть использован в дальнейшем. Поэтому прежде чем заниматься автоматизацией, необходимо четко представлять план дальнейшего развития проверяемого программного продукта, чтобы избегать подобных ситуаций. 
4. Еще одним недостатком автоматизации тестирования может стать отсутствие необходимой квалификации у сотрудников. Этот факт приводит к значительному увеличению времени при автоматизации и в дальнейшем при использовании автоматических тестов. Оператор теста должен обладать соответствующими знаниями: как использовать тест, как его конфигурировать, как его анализировать. Если оператора сменить, то результат автоматизации получится совсем другой.
5. Следствием из предыдущего пункта может стать наличие ошибок в тестовом скрипте. Например, если ошибка неверно определяется в автоматическом тесте, тогда она влечет за собой другие «ошибки», которые на самом деле ошибками не являются. Это может внести значительную сумятицу в процесс тестирования.
6. Также не стоит забывать про экономическую эффективность автоматизации. Возможна ситуация, что стоимость лицензий на инструменты для автоматизации превысят экономическую выгоду от использования автоматизированного тестирования в проектах. Кроме того, необходимо учитывать, что использование инструментов автоматизации может потребовать дополнительных расходов на необходимое оборудование: для их установки зачастую требуются отдельные сервера, и, возможно, потребуется их покупка.

Преимущества автоматизации тестирования

      Говоря о преимуществах автоматизации тестирования, чаще всего упоминают сокращение времени, затрачиваемого на проверку разработанного программного продукта. Однако существует и много других преимуществ:

1. Снижение стоимости итерации тестирования.
2. Увеличение скорости тестирования без ущерба для результата.
3. Повышение надежности систем за счет улучшения качества тестирования.
4. Обеспечение возможности многократного использования разработанных тестовых сценариев без увеличения стоимости тестирования.
5. Обеспечение прозрачности информации о качестве принимаемых изменений к программному обеспечению.
6. Усиление контроля процесса обеспечения качества.
7. Прозрачность и простота планирования времени для проведения тестирования программного обеспечения.
8. Автоматическое формирование отчётов о тестировании.
9. Рациональное использование рабочего времени команды тестирования: один тестировщик может параллельно осуществлять тестирование нескольких систем, автоматические тесты могут выполняться в нерабочее время (ночь, выходные).
10. Использование передовых технологий в сфере обеспечения качества.
11. Сокращение времени на проведение тестирования программного обеспечения.
12. Набор тестов ограничивается в первую очередь производительностью системы, а не доступным резервом времени тестировщиков.
13. Минимизация влияния человеческого фактора на процесс тестирования.
14. Нельзя упускать и психологический аспект автоматизированного тестирования. Не секрет, что во многих компания инженеры-тестировщики ставятся ниже разработчиков, как по престижу, так и по зарплате. С точки зрения построения эффективных проектных команд это совершенно неправильно, так как тестировщики, вместо того, чтобы развиваться в профессиональном плане, стремятся переквалифицироваться в разработчики. Такие тестировщики обычно слабо мотивированы на качественное ручное тестирование. Участие в создании автоматических тестов даёт таким сотрудникам ощущение повышения престижности в команде, профессиональный рост, повышает заинтересованность и мотивацию в обеспечении качества проектов. Тестировщик перестает восприниматься «глупее» программиста, ведь разработчик автотестов по сути тоже программист.

Недостатки автоматизации тестирования

Этапы процесса автоматизации тестирования

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

      В процессе автоматизации можно выделить три основных этапа:

• начальный этап - этап подготовки и планирования;
• этап активной разработки;
• этап поддержки автоматических тестов. 

 

Регрессионное тестирование

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

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

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

      Виды
    Основные виды тестов регрессии в порядке их важности (обычно в таком порядке их и выполняют).
     1. Тесты верификации версии (Build Verification Test). Нужны эти тесты для проверки основной функциональности каждой версии программы. Только будучи уверенным в том, что основная функциональность программы не нарушена. При нахождении ошибки с помощью таких тестов необходимо пересмотреть соответствующую часть кода на предмет ошибок.
    2. Тесты верификации ошибок (Bug Verification Test). Если некоторый тест выявил наличие ошибки, необходимо после исправления провести этот тест еще раз. Хотя проведение этих тестов и является логичным, многие разработчики пренебрегают такого вида тестированием.
    3. Тесты регрессии (Regression Test Pass). К этим тестам относятся те, которые уже проводились с предыдущими версиями программы и не выявляли ошибок. Иногда при отсутствии времени некоторые из тестов можно пропустить (желательно только тогда, когда не были внесены изменения в соответствующие участки кода). Если ранее такие тесты уже проводились более 3 раз и предполагается их выполнение в дальнейшем, то данный процесс неплохо было бы автоматизировать.
      4. Тесты регрессии на исправленных ошибках (тесты на закрытых ошибках). Что такое закрытые ошибки можно понять из примера. Пусть некоторый тест нашел ошибку. После исправления этот же тест ошибки не обнаружил. В этом случае ошибка и называется “закрытой”. Ошибка может проявиться снова по ряду причин (особенно при модификации кода). Поэтому время от времени нужно возвращаться к этому месту программы.

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

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

Характеристики и атрибуты качества программного обеспечения по ISO 9126

    Стандарт ISO 9126 предлагает использовать для описания внутреннего и внешнего качества ПО многоуровневую модель. На верхнем уровне выделено 6 основных характеристик качества ПО. Каждая характеристика описывается при помощи нескольких входящих в нее атрибутов. Для каждого атрибута определяется набор метрик, позволяющих его оценить. Множество характеристик и атрибутов качества согласно ISO 9126 показано на рисунке.


    

    1. Функциональность (functionality) - способность ПО в определенных условиях решать задачи, нужные пользователям. Определяет, что именно делает ПО, какие задачи оно решает.

• Функциональная пригодность (suitability) - способность решать нужный набор задач.
• Точность (accuracy) - способность выдавать нужные результаты.
• Способность к взаимодействию (interoperability) - способность взаимодействовать с нужным набором других систем.
• Соответствие стандартам и правилам (compliance) - соответствие ПО имеющимся индустриальным стандартам, нормативным и законодательным актам, другим регулирующим нормам.
• Защищенность (security) - способность предотвращать неавторизированный, т.е. без указания лица, пытающегося его осуществить, и неразрешенный доступ к данным и программам. 

  2. Надежность (reliability)  -  способность  ПО  поддерживать  определенную  работоспособность в заданных условиях. 

• Зрелость, завершенность (maturity) - величина, обратная частоте отказов ПО. Обычно измеряется средним временем работы без сбоев и величиной, обратной вероятности возникновения отказа за данный период времени.
• Устойчивость к отказам (fault tolerance) - способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением. 
• Способность к восстановлению (recoverability): Способность восстанавливать определенный уровень работоспособности и целостность данных после отказа, необходимые для этого время и ресурсы. 
• Соответствие стандартам надежности (reliability compliance).

    3. Удобство использования (usability) или практичность - способность ПО быть удобным в обучении и использовании, а также привлекательным для пользователей.

• Понятность (understandability) - показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач.
• Удобство обучения (learnability) - показатель, обратный усилиям, затрачиваемым пользователями на обучение работе с ПО. 
• Удобство работы (operability) - показатель, обратный усилиям, предпринимаемым пользователями для решения своих задач с помощью ПО. 
• Привлекательность (attractiveness) - способность ПО быть привлекательным для пользователей. 
• Соответствие стандартам удобства использования (usability compliance).

    4. Производительность (efficiency) или эффективность - способность ПО при заданных условиях обеспечивать необходимую работоспособность по отношению к выделяемым для этого ресурсам. Можно определить ее и как отношение получаемых с помощью ПО результатов к затрачиваемым на это ресурсам всех типов.

• Временная эффективность (time behaviour) - способность ПО выдавать ожидаемые результаты, а также обеспечивать передачу необходимого объема данных за отведенное время.
• Эффективность использования ресурсов (resource utilisation) - способность решать нужные задачи с использованием определенных объемов ресурсов определенных видов. Имеются в виду такие ресурсы, как оперативная и долговременная память, сетевые соединения, устройства ввода и вывода и пр. 
• Соответствие стандартам производительности (efficiency compliance).

    5. Удобство сопровождения (maintainability) - Удобство проведения всех видов деятельности, связанных с сопровождение программ.

• Анализируемость (analyzability) или удобство проведения анализа - удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа необходимости изменений и их возможных последствий.
• Удобство внесения изменений (changeability) - показатель, обратный трудозатратам на выполнение необходимых изменений. 
• Стабильность (stability) - показатель, обратный риску возникновения неожиданных эффектов при внесении необходимых изменений. 
• Удобство проверки (testability) - показатель, обратный трудозатратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным результатам. 
• Соответствие стандартам удобства сопровождения (maintainability compliance).

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

• Адаптируемость (adaptability) - способность ПО приспосабливаться различным окружениям без проведения для этого действий, помимо заранее предусмотренных.
• Удобство установки (installability) - способность ПО быть установленным или развернутым в определенном окружении. 
• Способность к сосуществованию (coexistence) - способность ПО сосуществовать с другими программами в общем окружении, деля с ними ресурсы. 
• Удобство замены (replaceability) другого ПО данным - возможность применения данного ПО вместо других программных систем для решения тех же задач в определенном окружении. 
• Соответствие стандартам переносимости (portability compliance).

    Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126:2001 определяет наборы метрик для оценки каждого атрибута. Вот некоторые примеры таких метрик.

1. Полнота реализации функций — процент реализованных функций по отношению к перечисленным в требованиях. Используется для измерения функциональной пригодности.
2. Корректность реализации функций — правильность их реализации по отношению к требованиям. Используется для измерения функциональной пригодности. 
3. Отношение числа обнаруженных дефектов к прогнозируемому. Используется для определения зрелости. 
4. Отношение числа проведенных тестов к общему их числу. Используется для определения зрелости. 
5. Отношение числа доступных проектных документов к указанному в их списке. Используется для измерения удобства проведения анализа. 
6. Наглядность и полнота документации. Используется для оценки понятности.

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

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

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

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

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

Проверка внешнего вида web-приложений

0. Проверить соответствие макету, спецификации, ТЗ...
- в принципе достаточно просто глянуть намётанным глазом, если расхождения заметные — они будут бросаться в глаза

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

2. Проверить переход на страницу:
- переход на страницу по ссылке с другой страницы/по прямому URL
- обновить страницу F5
- свернуть/развернуть окно
- изменение размеров окна (корректное отображение при наличии полосы прокрутки)

3. Проверить верстку страницы:
- корректный title для страницы (в идеале – у каждой страницы уникальный)
- наличие alt у картинок

4. Корректное отображение в процессе работы:
- выбор значений, выпадающие списки
- ввод реального текста (очень длинный текст – полоса прокрутки?)
- отображение ошибок

5. Работоспособность при выключенных картинках
- проверяется в FF через плагин Web Developer https://addons.mozilla.org/ru/firefox/addon/web-developer/ →Images→Replace Images With Alt Attributes.

6. Работоспособность при выключенном JavaScript
- проверяется в FF через плагин Web Developer https://addons.mozilla.org/ru/firefox/addon/web-developer/ →Disable→Disable JavaScript→All JavaScript

7. Работоспособность при выключенном Flash
- проверяется в FF отключением flash-плагина: Tools→Add-ons→Plugins→Shockwave Flash→disable.

8. Проверить скорость загрузки.
- скорость загрузки страницы можно посмотреть в панели Net в Firebug https://addons.mozilla.org/ru/firefox/addon/firebug/ Необходимо проверять, как отображается страница при загрузке на малых скоростях.

9. Для проектов, где это оговорено:
- версия для печати
- мобильная версия

10. Проверить в разных браузерах:
- Firefox (последняя версия)
- IE (последняя версия + предыдущая)
- Chrome (последняя версия)
- Opera (последняя версия)
- Safari (последняя версия)

11. Проверить в разном разрешении (Проверяется в FF через плагин https://addons.mozilla.org/ru/firefox/addon/web-developer/ Web Developer→Resize). Список классических разрешений:
- 1024x600
- 1024x768
- 1152x864
- 1280x800
- 1280x1024
- 1440x900
- 1680x1050
- 1920x1080

12. Дополнительные проверки:
- логотип на странице ведет на главную страницу
 - возможность навигации по различным страницам приложения
- проверить битые ссылки
- ссылки в тексте должны быть выделены + :hover, :active и :focus
- копирайт должен быть написан правильно http://habrahabr.ru/post/23812/
- проверить favicon.ico
- проверить орфографию http://www.artlebedev.ru/tools/orfograf/
- проверить переход по Tab, возможность работы с приложением только при помощи клавиатуры
 - проверить работу «горячих» клавиш

Должны ли тестировщики самостоятельно исправлять найденные ошибки?

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

      Преимущество подхода «сам нашел – сам исправил» в том, что ошибки правятся гораздо быстрее (практически сразу же после обнаружения!), и для этого не нужно привлекать программистов, которым для исправления бага нужно будет отвлекаться от выполнения текущих задач и вникать в суть ошибки. Замечательно, не так ли? Так почему же все-таки стоит отказаться от такого подхода?

      Если исправить баг слишком быстро, то программист, который допустил эту ошибку, может не заметить, что эта ошибка вообще была и будет делать ее снова и снова.
      Спустя какое-то время программисты привыкнут, что тестировщики сами исправляют ошибки, и станут менее серьезно относиться к качеству кода. «Зачем самостоятельно проверять? Можно отдать для тестирования и код с ошибками. Все равно тестировщики все исправят…».
      Еще одна проблема в самостоятельном исправлении багов в том, что со стороны может казаться, что тестировщики не находят ошибок в программе или же этих ошибок просто нет.
      Следующая проблема связана с тем, что у тестировщика может быть недостаточно квалификации для исправления бага.
      Или, неправильно разобравшись в причинах возникновения ошибки, тестировщик начнет исправлять не то, что нужно.
      Или при исправлении тестировщик может не учесть некоторые соглашения по разработке, принятые среди программистов, просто потому что он не в курсе этих соглашений. Он же не программист, а тестировщик.
      К тому же, когда тестировщики перестают сообщать о багах программистам, резко уменьшается количество коммуникаций в команде. Программистам необходимо получать фидбэк о своей работе, и положительный, и отрицательный!

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

Стандартизация качества ПО

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

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

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

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

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

      Основой регламентирования показателей качества программных средств является международный стандарт ISO 9126 (ГОСТ Р ИСО / МЭК 9126) "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению". Проект состоит из следующих частей под общим заголовком "Информационная технология - характеристики и метрики качества программного обеспечения":

      "Часть 1. Характеристики и субхарактеристики качества",

      "Часть 2. Внешние метрики качества",

      "Часть 3. Внутренние метрики качества",

      "Часть 4. Метрики качества в использовании".

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

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

      Вторая и третья части стандарта - ISO 9126-2 и ISO 9126-3 - посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств. Все таблицы содержат унифицированную рубрикацию, где отражены имя и назначение метрики; метод ее применения; способ измерения, тип шкалы метрики; тип измеряемой величины; исходные данные для измерения и сравнения; а также этапы жизненного цикла программного средства (по ISO 12207), к которым применима метрика.

      Четвертая часть стандарта - ISO 9126-4 - предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества программных средств. В ней обосновываются и комментируются выделенные показатели сферы (контекста) использования программных средств и группы выбранных метрик для пользователей.

     

      Дополнительно могут быть использованы стандарты ISO серии 9000, в которых описаны общие принципы обеспечения качества процессов производства во всех отраслях экономики.

Классификация тестирования. Уровни, виды и типы

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

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

      - по объектам (элементам) тестирования, часто разделение на виды тестов по данному критерию называют разделением тестирования на уровни;

      - по глубине тестирования, то есть разделение тестовых испытаний на типы проводится в зависимости от количества времени и объема тестируемых компонент программного продукта;

      - в соответствие с традиционными показателями качества, которые проверяются с их помощью.

      Уровни тестирования

      Модульное тестирование (Автономное или Unit-тестирование). На данном уровне тестируются по отдельности небольшие элементы системы, максимально отделенные от других элементов и, в то же время, пригодные для тестирования.

      Комплексное тестирование (Сборочное тестирование, integration testing или interface testing). На данном уровне тестируются объединенные элементы (компоненты или подсистемы) общей системы, чаще всего некоторая взаимодействующая между собой группа элементов. Комплексное тестирование направлено не на проверку функционирования каждого из компонентов, а на проверку взаимодействия компонентов в соответствии с архитектурой системы.

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

      Приемочное тестирование (Приемо-сдаточное тестирование или acceptance testing). На данном уровне завершенное приложение (система) тестируется заказчиком, конечными пользователями или соответствующими уполномоченными с целью определения соответствия системы требованиям заказчика и готовности системы к внедрению. Приемосдаточные испытания оформляют процесс передачи продукта от разработчика заказчику. В зависимости от особенностей продукта и от требований Заказчика они могут проводиться в различной форме.

      Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения – критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО.

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

      Виды тестирования

      Инсталляционное тестирование (Installation testing). В процессе такого тестирования проверяется корректность установки и деинсталляции программного продукта в среде максимально приближенной к эксплутационной. Проверка правильности установки программного продукта должна быть обязательным элементом проекта по тестированию любого продукта.

      Дымовое тестирование (проверка на дым, Smoke testing). Первый прогон программы (после написания или после внесения существенных изменений). Как правило, используется для определения, готова ли программа для проведения более обширного тестирования. Основная цель такого тестирования - выявление проблем «лежащих на поверхности» – тестируется чаще всего основная бизнес логика программы.

      Функциональное тестирование (Functional testing). Под данным типом тестирования подразумевается проверка соответствия продукта функциональным требованиям и спецификациям.

      Регрессионное тестирование (Regression testing). Повторное тестирование после внесения изменений в программное обеспечение или в его окружение (в новой версии приложения), которое используется длятого чтобы убедиться в том, что функции, которые работали в предыдущей версии системы, по-прежнему работоспособны, а найденные дефекты успешно. Целью регрессионного тестирования является выявление проблем, которые могли возникнуть в результате изменений и проверка исправления найденных ранее дефектов.

      Интеграционное тестирование (Integration testing). Проверка скомбинированных компонентов прикладной программы с целью определения корректности их совместного функционирования

      Тестирование графического интерфейса пользователя (User Interface testing). Тестирование интерфейса – экранов, кнопок и т.д. Большая часть функциональности ПО реализуется, как правило, через пользовательский интерфейс. Цель - обнаружение ошибок в интерфейсе и поиск ошибок в функциональности посредством интерфейса

      Тестирование производительности (Performance testing). Проверка скорости работы системы (время отклика, частота транзакций и другие зависящие от времени) в имитационной и реальной средах.

      Нагрузочное тестирование (Load testing). Это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»).

      Стресс тестирование (Stress testing). Является одним из разновидностей тестирования на производительность, при которой проверяется, что система адекватно реагирует нате или иные стрессовые ситуации, например при недостатке ресурсов (дискового пространства, обрывов сети и т.д.).

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

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

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

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

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

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

Классификация тестирования. Технологии и методы

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

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

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

      Технологии тестирования используются при применении различных методов тестирования. Среди методов тестирования обычно выделяют два самых распространенных: метод «черного ящика» («black-box» testing) и метод «белого ящика» («white-box» or «glass-box» testing). Различие этих методов заключается в том, имеет ли разработчик тестов и тестировщик доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

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

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

Цикл тестирования

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

      1) планирование тестов: определение требований к тестам; оценка рисков; разработка стратегии тестирования; определение ресурсов; создание последовательностей выполнения тестов; разработка плана тестирования.

      2) дизайн тестов: анализ объёма работ; определение и описание тестовых случаев; определение и структурирование тестовых процедур; обзор и оценка тестового покрытия.

      3) разработка тестов: запись или программирование тестовых сценариев; создание и подготовка внешних наборов данных.

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

      5) оценка тестов: оценка покрытия тестовыми случаями; оценка покрытия кода; анализ дефектов; определение критериев завершения и успешности тестирования.

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

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

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

      В соответствии со стандартом ISO 9126 принято следующее определение тестирования:

      Тестирование — это наблюдение за функционированием ПО в специфических условиях с целью определения степени соответствия ПО требованиям к нему.

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

      По ГОСТ Р ИСО МЭК 12207 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора. В сумме эти процессы и составляют то, что обычно называют тестированием.

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