Запомните, что валидация ПО заключается в гарантировании, что мы создаем правильное программное обеспечение; другими словами, убеждаемся, что создаем то, что хотят пользователи и/или потребители. Для того чтобы провалидировать программу, мы должны знать, что она должна делать, по мнению пользователей, и эта задача может оказаться гораздо более сложной, чем вы думаете. Пользователи часто не способны четко сформулировать, что именно они хотят. Они могут думать, что знают точно свои желания, но когда они видят реализацию, то сразу же понимают, что это не то. Или у них может вообще не быть никакой идеи — они просто хотят от вашей команды, чтобы вы создали "что-то вроде социальной сети, но для покупок и продаж. Что именно? Что-то типа хот-догов. А для кошек можно?". Одним из способов определить, какое ПО создавать, является определение требований к программному обеспечению. Требования являются формулировками, определяющими, что именно эта часть программы должна делать в определенных условиях. Так более или менее принято в зависимости от области работы и вида создаваемого программного обеспечения. Например, при создании программы для мониторинга ядерного реактора должны быть очень точные и хорошо проработанные требования. Если вы работаете для социально-медийного стартапа (надеюсь, не того, который "продажа и покупка, типа того, например, хот-догов... для кошек", потому что среди них конкуренция), тогда ваши "требования" могут быть нацарапаны вашим CEO на салфетке после нескольких бутылок вина и после нескольких встреч с реальными потребителями. Требования гарантируют, что разработчики знают, что создавать, а тестировщики знают, что тестировать. Хотя требования очень важны, они не являются священными! Здравый смысл должен преобладать при изучении требований, и требования могут быть изменены. Обратите внимание, что помимо требований существуют другие способы определения, какое ПО создавать, например пользовательские истории (user stories). В нашем примере с датчиком давления колес из главы по основам тестирования у нас были сравнительно простые требования, хотя мы не оговаривали, чем именно они являются: 1. Сигнал "ОШИБКА" включается для PSI, равного –1 или меньше. 2. Сигнал "НЕДОСТАТОЧНОЕ ДАВЛЕНИЕ" включается для PSI от 0 до 20. 3. Сигналы не включаются для PSI от 21 до 35 (нормальные рабочие условия). 4. Сигнал "ИЗБЫТОЧНОЕ ДАВЛЕНИЕ" включается для PSI от 36 и выше. Эти "неформальные требования" показывают, что должно происходить с системой при определенных входных значениях. Классический способ написания требований заключается в том, чтобы сказать, что система "должна" сделать. При тестировании вы можете мысленно перевести "должна" как "обязана". То есть если требование говорит, что система должна сделать что-то, значит, система обязана сделать что-то для того, чтобы вы как тестировщик могли сказать, что система соответствует требованию. Требования должны быть написаны точно, и следует избегать неоднозначности любой ценой. Давайте переведем эти неформальные требования в нечто, больше соответствующее требованиям, которые пишутся в реальном мире. REQ-1. Если дисплейным датчиком получено значение давления, равное –1 или меньше, тогда сигнал "ОШИБКА" должен быть включен, а все остальные сигналы должны быть отключены. REQ-2. Если дисплейным датчиком получено значение давления, лежащее в пределах от 0 до 20 (включительно), тогда сигнал "НЕДОСТАТОЧНОЕ ДАВЛЕНИЕ" должен быть включен, а все остальные сигналы должны быть отключены. REQ-3. Если дисплейным датчиком получено значение давления, лежащее в пределах от 21 до 35 (включительно), тогда все сигналы должны быть отключены. REQ-4. Если дисплейным датчиком получено значение давления, равное 36 или больше, тогда сигнал "ИЗБЫТОЧНОЕ ДАВЛЕНИЕ" должен быть включен, а все остальные сигналы должны быть отключены. Обратите внимание, насколько подробными эти требования стали по сравнению с приведенными выше неформальными. Инжиниринг требований является настоящей инженерной дисциплиной, и может оказаться очень сложно описать большую и/или сложную систему. Также обратите внимание, насколько более плотным и бóльшим стал текст в попытке избежать неоднозначности. Определенно, на написание формальных требований уйдет гораздо больше времени, чем накалякать общий набросок программы на салфетке. Теперь и изменения вносить станет сложнее. Компромисс может быть найден, а может и нет, в зависимости от области работы и тестируемой системы. Гарантирование того, что авиационное программное обеспечение при всех условиях правильно контролирует полет самолета, вероятно, потребует тщательно проработанной спецификации требований (списка всех требований системы), в то время как для упомянутого выше медийно-социального сайта подобное может не понадобиться. Жесткость может обеспечить очень хорошее определение системы, но ценой гибкости. Кстати, если вы задумывались, почему адвокатам платят так много, то можно сказать, что описанное выше применимо к тому, чем они занимаются каждый день. Можно представить, что законы — это набор требований, которые человек должен соблюдать, чтобы быть законопослушным; представить, какие наказания применяются в случае, если человек нарушает закон, как создаются законы и т. д.: 1. Если нарушитель переходит оживленную дорогу не по пешеходному переходу, и имеются приближающиеся машины, и по крайней мере одной машине необходимо затормозить, то нарушитель должен быть обвинен в нарушении "Пешеход не уступил дорогу". 2. Если человек переходит оживленную дорогу, когда на светофоре пешеходного перехода не горит зеленый свет и нет приближающихся машин, нарушитель должен быть обвинен в нарушении "Пешеход не соблюдает сигналы светофора". И в законе, и в тестировании возможно "спуститься в кроличью нору", стараясь определить, что именно означает текст. Английский язык полон неоднозначностей. Например, возьмем совершенно разумное требование, которое может быть прочитано различными способами, один из которых: UNCLEARREQ-1. Основная сигнализационная система должна звучать, если обнаружен нарушитель с помощью визуального дисплейного модуля. Должно ли это означать, что сигнализация должна зазвучать, если нарушитель пользовался помощью визуального дисплейного модуля? Или сигнализация должна звучать, если нарушитель обнаружен благодаря визуальному дисплейному модулю системы? Старайтесь избегать такой неоднозначности при написании требований. Хотя тестировщики редко пишут требования самостоятельно, их частенько просят просмотреть их. Гарантирование того, что вы понимаете требование и это требование может быть протестировано, сохранит время и позволит позднее избежать головной боли в процессе разработки. При написании требований важно держать в голове, что требования обозначают, что системе следует делать, но не как ей это следует делать. Другими словами, не надо определять детали реализации, а лишь как система или подсистема взаимодействует c окружающим миром и воздействует на него. Это легче понять на примерах из новой межзвездной космической игры. Хорошие требования: GOOD-REQ-1 — когда пользователь нажимает кнопку Скорость, текущая скорость космического корабля должна быть отображена на главном экране; GOOD-REQ-2 — система должна быть способна поддерживать скорость 0,8с (80% скорости света) по крайней мере в течение трех дней (7200 часов) без потребности в техобслуживании; GOOD-REQ-3 — система должна сохранять последние 100 координат мест, в которых брались образцы. Плохие требования: BAD-REQ-1 — когда пользователь нажимает кнопку Скорость, система должна обратиться к памяти по адресу 0x0894BC50 и отобразить ее значение на экране; BAD-REQ-2 — система должна моделировать реакцию "антивещество — вещество" для того, чтобы достигать скорости 0,8с; BAD-REQ-3 — система должна использовать реляционную базу данных, чтобы сохранять последние 100 координат мест, в которых брались образцы. Обратите внимание, что все плохие требования говорят о том, как что-то должно быть выполнено, а не что система должна делать. Что произойдет, если изменится расположение памяти? BAD-REQ-1 должен измениться, как и другие требования, в которых данные зависят от расположения в определенной области памяти. Почему важно использовать именно реактор антиматерии-материи? В конце концов, ключевым моментом является то, что космический корабль может двигаться с определенной скоростью. И в итоге, важно ли то, что нужно использовать реляционную базу данных для хранения координат? Если посмотреть с точки зрения пользователя, то беспокоить его должно лишь то, что координаты должны быть сохранены. Для сложных или критически важных с точки зрения безопасности систем (таких как реальный космический звездолет) требования могут определять реализацию. В этих случаях не только важно, что система делает нечто, но и то, что она делает это проверенным и определенным способом. Для большинства систем, однако, такие требования являются излишними и значительно ограничат гибкость в процессе разработки программного обеспечения. Также станет более сложным тестировать эти требования, поскольку тестировщику надо определять не только соответствие наблюдаемого поведения ожидаемому, но и как наблюдаемое поведение происходило. Создавая требования по особенностям реализации, вы исключаете возможность тестирования черного ящика. Не зная программного кода, как вы можете быть уверены, что система отображает содержимое памяти по адресу 0x0895BC40? Это невозможно (по крайней мере, если у вас нет невообразимой суперсилы, позволяющей заглянуть внутрь чипа памяти и понять, что там хранится и где). Все тесты окажутся тестами белого ящика.
Будни тестировщика
:Олег Петухов
Требования.
Запомните, что валидация ПО заключается в гарантировании, что мы создаем правильное программное обеспечение; другими словами, убеждаемся, что создаем то, что хотят пользователи и/или потребители. Для того чтобы провалидировать программу, мы должны знать, что она должна делать, по мнению пользователей, и эта задача может оказаться гораздо более сложной, чем вы думаете. Пользователи часто не способны четко сформулировать, что именно они хотят. Они могут думать, что знают точно свои желания, но когда они видят реализацию, то сразу же понимают, что это не то. Или у них может вообще не быть никакой идеи — они просто хотят от вашей команды, чтобы вы создали "что-то вроде социальной сети, но для покупок и продаж. Что именно? Что-то типа хот-догов. А для кошек можно?".
Одним из способов определить, какое ПО создавать, является определение требований к программному обеспечению. Требования являются формулировками, определяющими, что именно эта часть программы должна делать в определенных условиях. Так более или менее принято в зависимости от области работы и вида создаваемого программного обеспечения. Например, при создании программы для мониторинга ядерного реактора должны быть очень точные и хорошо проработанные требования. Если вы работаете для социально-медийного стартапа (надеюсь, не того, который "продажа и покупка, типа того, например, хот-догов... для кошек", потому что среди них конкуренция), тогда ваши "требования" могут быть нацарапаны вашим CEO на салфетке после нескольких бутылок вина и после нескольких встреч с реальными потребителями.
Требования гарантируют, что разработчики знают, что создавать, а тестировщики знают, что тестировать. Хотя требования очень важны, они не являются священными! Здравый смысл должен преобладать при изучении требований, и требования могут быть изменены. Обратите внимание, что помимо требований существуют другие способы определения, какое ПО создавать, например пользовательские истории (user stories).
В нашем примере с датчиком давления колес из главы по основам тестирования у нас были сравнительно простые требования, хотя мы не оговаривали, чем именно они являются:
1. Сигнал "ОШИБКА" включается для PSI, равного –1 или меньше.
2. Сигнал "НЕДОСТАТОЧНОЕ ДАВЛЕНИЕ" включается для PSI от 0 до 20.
3. Сигналы не включаются для PSI от 21 до 35 (нормальные рабочие условия).
4. Сигнал "ИЗБЫТОЧНОЕ ДАВЛЕНИЕ" включается для PSI от 36 и выше.
Эти "неформальные требования" показывают, что должно происходить с системой при определенных входных значениях. Классический способ написания требований заключается в том, чтобы сказать, что система "должна" сделать. При тестировании вы можете мысленно перевести "должна" как "обязана". То есть если требование говорит, что система должна сделать что-то, значит, система обязана сделать что-то для того, чтобы вы как тестировщик могли сказать, что система соответствует требованию. Требования должны быть написаны точно, и следует избегать неоднозначности любой ценой. Давайте переведем эти неформальные требования в нечто, больше соответствующее требованиям, которые пишутся в реальном мире.
REQ-1. Если дисплейным датчиком получено значение давления, равное –1 или меньше, тогда сигнал "ОШИБКА" должен быть включен, а все остальные сигналы должны быть отключены.
REQ-2. Если дисплейным датчиком получено значение давления, лежащее в пределах от 0 до 20 (включительно), тогда сигнал "НЕДОСТАТОЧНОЕ ДАВЛЕНИЕ" должен быть включен, а все остальные сигналы должны быть отключены.
REQ-3. Если дисплейным датчиком получено значение давления, лежащее в пределах от 21 до 35 (включительно), тогда все сигналы должны быть отключены.
REQ-4. Если дисплейным датчиком получено значение давления, равное 36 или больше, тогда сигнал "ИЗБЫТОЧНОЕ ДАВЛЕНИЕ" должен быть включен, а все остальные сигналы должны быть отключены.
Обратите внимание, насколько подробными эти требования стали по сравнению с приведенными выше неформальными. Инжиниринг требований является настоящей инженерной дисциплиной, и может оказаться очень сложно описать большую и/или сложную систему. Также обратите внимание, насколько более плотным и бóльшим стал текст в попытке избежать неоднозначности. Определенно, на написание формальных требований уйдет гораздо больше времени, чем накалякать общий набросок программы на салфетке. Теперь и изменения вносить станет сложнее. Компромисс может быть найден, а может и нет, в зависимости от области работы и тестируемой системы. Гарантирование того, что авиационное программное обеспечение при всех условиях правильно контролирует полет самолета, вероятно, потребует тщательно проработанной спецификации требований (списка всех требований системы), в то время как для упомянутого выше медийно-социального сайта подобное может не понадобиться. Жесткость может обеспечить очень хорошее определение системы, но ценой гибкости.
Кстати, если вы задумывались, почему адвокатам платят так много, то можно сказать, что описанное выше применимо к тому, чем они занимаются каждый день. Можно представить, что законы — это набор требований, которые человек должен соблюдать, чтобы быть законопослушным; представить, какие наказания применяются в случае, если человек нарушает закон, как создаются законы и т. д.:
1. Если нарушитель переходит оживленную дорогу не по пешеходному переходу, и имеются приближающиеся машины, и по крайней мере одной машине необходимо затормозить, то нарушитель должен быть обвинен в нарушении "Пешеход не уступил дорогу".
2. Если человек переходит оживленную дорогу, когда на светофоре пешеходного перехода не горит зеленый свет и нет приближающихся машин, нарушитель должен быть обвинен в нарушении "Пешеход не соблюдает сигналы светофора".
И в законе, и в тестировании возможно "спуститься в кроличью нору", стараясь определить, что именно означает текст. Английский язык полон неоднозначностей. Например, возьмем совершенно разумное требование, которое может быть прочитано различными способами, один из которых:
UNCLEARREQ-1. Основная сигнализационная система должна звучать, если обнаружен нарушитель с помощью визуального дисплейного модуля.
Должно ли это означать, что сигнализация должна зазвучать, если нарушитель пользовался помощью визуального дисплейного модуля? Или сигнализация должна звучать, если нарушитель обнаружен благодаря визуальному дисплейному модулю системы? Старайтесь избегать такой неоднозначности при написании требований. Хотя тестировщики редко пишут требования самостоятельно, их частенько просят просмотреть их. Гарантирование того, что вы понимаете требование и это требование может быть протестировано, сохранит время и позволит позднее избежать головной боли в процессе разработки.
При написании требований важно держать в голове, что требования обозначают, что системе следует делать, но не как ей это следует делать. Другими словами, не надо определять детали реализации, а лишь как система или подсистема взаимодействует c окружающим миром и воздействует на него. Это легче понять на примерах из новой межзвездной космической игры.
Хорошие требования:
GOOD-REQ-1 — когда пользователь нажимает кнопку Скорость, текущая скорость космического корабля должна быть отображена на главном экране;
GOOD-REQ-2 — система должна быть способна поддерживать скорость 0,8с (80% скорости света) по крайней мере в течение трех дней (7200 часов) без потребности в техобслуживании;
GOOD-REQ-3 — система должна сохранять последние 100 координат мест, в которых брались образцы.
Плохие требования:
BAD-REQ-1 — когда пользователь нажимает кнопку Скорость, система должна обратиться к памяти по адресу 0x0894BC50 и отобразить ее значение на экране;
BAD-REQ-2 — система должна моделировать реакцию "антивещество — вещество" для того, чтобы достигать скорости 0,8с;
BAD-REQ-3 — система должна использовать реляционную базу данных, чтобы сохранять последние 100 координат мест, в которых брались образцы.
Обратите внимание, что все плохие требования говорят о том, как что-то должно быть выполнено, а не что система должна делать. Что произойдет, если изменится расположение памяти? BAD-REQ-1 должен измениться, как и другие требования, в которых данные зависят от расположения в определенной области памяти. Почему важно использовать именно реактор антиматерии-материи? В конце концов, ключевым моментом является то, что космический корабль может двигаться с определенной скоростью. И в итоге, важно ли то, что нужно использовать реляционную базу данных для хранения координат? Если посмотреть с точки зрения пользователя, то беспокоить его должно лишь то, что координаты должны быть сохранены.
Для сложных или критически важных с точки зрения безопасности систем (таких как реальный космический звездолет) требования могут определять реализацию. В этих случаях не только важно, что система делает нечто, но и то, что она делает это проверенным и определенным способом. Для большинства систем, однако, такие требования являются излишними и значительно ограничат гибкость в процессе разработки программного обеспечения. Также станет более сложным тестировать эти требования, поскольку тестировщику надо определять не только соответствие наблюдаемого поведения ожидаемому, но и как наблюдаемое поведение происходило.
Создавая требования по особенностям реализации, вы исключаете возможность тестирования черного ящика. Не зная программного кода, как вы можете быть уверены, что система отображает содержимое памяти по адресу 0x0895BC40? Это невозможно (по крайней мере, если у вас нет невообразимой суперсилы, позволяющей заглянуть внутрь чипа памяти и понять, что там хранится и где). Все тесты окажутся тестами белого ящика.