Тестирование не техписательство,

Что такое тестирование

Сначала попробуем понять, чем тестирование НЕ является.

Тестирование не разработка,

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

Тем не менее, тестирование — это не деятельность по разработке программного обеспечения.

Тестирование не анализ,

и не деятельность по сбору и анализу требований.

Хотя, в процессе тестирования иногда приходится уточнять требования, а иногда приходится их анализировать. Но эта деятельность не основная, скорее, это приходится делать просто по необходимости.

Тестирование не управление,

несмотря на то, что во многих организациях есть такая роль, как «тест-менеджер». Конечно же, тестировщиками надо управлять. Но само по себе тестирование управлением не является.

Тестирование не техписательство,

однако тестировщикам приходится документировать свои тесты и свою работу.

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

Деятельность значима только тогда, когда она востребована, то есть тестировщики должны что-то производить «на экспорт». Что они делают «на экспорт»?

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

Это наивно.

Хотя частично это правда.

Но это не вся правда.

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

· проверка соответствия программы требованиям,

· осуществляемая путем наблюдения за ее работой

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

Отсюда и далее будем считать это рабочим определением «тестирования».

Общая схема тестирования примерно следующая:

1. Тестировщик на входе получает программу и/или требования.

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

3. На выходе он получает информацию о соответствиях и несоответствиях.

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

Это весьма близко к определению, данному в SWEBOK, хотя есть несколько отличий. Например, в нашем определении нет слова «тест».

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

звучит следующим образом:

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

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

Определение по SWEBOK плохо по-следующей причине: оно говорит нам, что набор тестов должен быть КОНЕЧНЫМ. А он конечным будет всего лишь по определению. Он не может быть бесконечным, потому что у нас есть только ограниченное количество времени, ограниченные ресурсы, объем памяти компьютера конечен, поэтому это слово «конечный» ничего нам не дает осмысленного, правильно использовать термин «ограниченный», на ограниченный набор тестов. Мы его сами некоторым образом ограничиваем.

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

Что такое тест

· Это специальная, искусственно созданная ситуация, выбранная определенным образом,

· и описание того, какие наблюдения за работой программы нужно сделать

· для проверки ее соответствия некоторому требованию.

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

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

1.Во-первых, он управляет выполнением программы и создает эти самые искусственные ситуации, в которых мы собираемся проверять поведение программы.

2.И, во-вторых, он наблюдает за поведением программы и сравнивает то, что он видит с тем, что ожидается.

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

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

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

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

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

Вот эти 6 аспектов качества верхнего уровня:

· функциональность,

· надежность,

· практичность,

· эффективность,

· сопровождаемость

· переносимость.

Функциональность

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

Во-вторых, она должна делать это правильно (accuracy). Она должна вычислять с определенной точностью, она должна правильно конвертировать данные и так далее.

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

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

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

Надежность

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

К нему относятся такие подхарактеристики, как зрелость (maturity), которая является обратной величиной к частоте отказов, и устойчивость к отказам(faulttolerance), то есть способность системы не реагировать на какие-то внутренние проблемы. В том числе сюда относится транзакционная целостность и способность к восстановлению работоспособности при отказах (recoverability). То есть если у вас сервер упал, то он должен самостоятельно восстановиться, вернуть все нужные данные, ничего не потерять, и продолжить работу.

Практичность

Это понятность программы (understandability) то есть пользователь должен понять, как воспользоваться ею для достижения своих целей.

Это удобство обучения (learnability) или изучения. В частности, у программы, наверное, должна быть какая-то документация.

Это работоспособность (operability) или управляемость, то есть пользователь должен иметь возможность управлять поведением программы, она должна реагировать на его действия.

И привлекательность (attractiveness), эстетическая привлекательность, что тоже, конечно же, немаловажно.

Эффективность

Она же – производительность, четвертый аспект качества.

Сюда относятся временные характеристики (timebehaviour), время отклика, скорость работы программы, скорость обработки определенных данных и так далее.

И использование ресурсов (resourceutilisation), использование дисковых ресурсов, использование ресурсов процессора, использование оперативной памяти, использование сетевых ресурсов.

Сопровождаемость

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

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

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

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

Подразумевает анализируемость кода (analyzability), изменяемость(changeability), то есть удобство внесения изменений в программный код,риск возникновения неожиданных эффектов после того, как мы эти изменения внесли (stability), а также контролируемость (testability), или же – удобство тестирования программы.

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

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

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

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

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

И вот это как раз и есть разница между тестированием методом черного ящика и тестированием методом белого ящика.

При тестировании методом черного ящика мы не видим, что внутри ящика, мы не принимаем во внимание внутреннее устройство программы.

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

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

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

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

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

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

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

Спасибо за внимание».

 

Что такое тестирование

Сначала попробуем понять, чем тестирование НЕ является.

Тестирование не разработка,

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

Тем не менее, тестирование — это не деятельность по разработке программного обеспечения.

Тестирование не анализ,

и не деятельность по сбору и анализу требований.

Хотя, в процессе тестирования иногда приходится уточнять требования, а иногда приходится их анализировать. Но эта деятельность не основная, скорее, это приходится делать просто по необходимости.

Тестирование не управление,

несмотря на то, что во многих организациях есть такая роль, как «тест-менеджер». Конечно же, тестировщиками надо управлять. Но само по себе тестирование управлением не является.

Тестирование не техписательство,

однако тестировщикам приходится документировать свои тесты и свою работу.

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

Деятельность значима только тогда, когда она востребована, то есть тестировщики должны что-то производить «на экспорт». Что они делают «на экспорт»?

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

Это наивно.

Хотя частично это правда.

Но это не вся правда.