Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Выполнимость (feasibility 90 ). Требование должно быть технологически вы- полнимым и реализуемым в рамках бюджета и сроков разработки проекта. Типичные проблемы с выполнимостью: • Так называемое «озолочение» (gold plating) — требования, которые крайне долго и/или дорого реализуются и при этом практически бесполезны для ко- нечных пользователей (например: «настройка параметров для подключе- ния к базе данных должна поддерживать распознавание символов из же- стов, полученных с устройств трёхмерного ввода»). • Технически нереализуемые на современном уровне развития технологий требования (например: «анализ договоров должен выполняться с примене- нием искусственного интеллекта, который будет выносить однозначное корректное заключение о степени выгоды от заключения договора»). • В принципе нереализуемые требования (например: «система поиска должна заранее предусматривать все возможные варианты поисковых запросов и кэшировать их результаты»). Способы обнаружения проблем Способы устранения проблем Увы, здесь есть только один путь: максимально нарабатывать опыт и исходить из него. Невозможно по- нять, что некоторое требование «стоит» слишком много или вовсе невыполнимо, если нет понимания процесса разработки ПО, понима- ния предметной области и иных со- путствующих знаний. При обнаружении невыполнимости требования не остаётся ничего дру- гого, как подробно обсудить ситуа- цию с заказчиком и/или изменить требование (возможно – отказаться от него), или пересмотреть условия выполнения проекта (сделав выпол- нение данного требования возмож- ным). Обязательность, нужность (obligatoriness 91 ) и актуальность (up-to-date). Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета (см. «проранжирован- ность по…»). Также исключены (или переработаны) должны быть требования, утра- тившие актуальность. Типичные проблемы с обязательностью и актуальностью: • Требование было добавлено «на всякий случай», хотя реальной потребности в нём не было и нет. 90 It must be possible to implement each requirement within the known capabilities and limitations of the system and its operating environment, as well as within project constraints of time, budget, and staff. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 91 Each requirement should describe a capability that provides stakeholders with the anticipated business value, differentiates the product in the marketplace, or is required for conformance to an external standard, policy, or regulation. Every requirement should originate from a source that has the authority to provide requirements. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 45/298 • Требованию выставлены неверные значения приоритета по критериям важ- ности и/или срочности. • Требование устарело, но не было переработано или удалено. Способы обнаружения проблем Способы устранения проблем Постоянный (периодический) пере- смотр требований (желательно – с участием заказчика) позволяет за- метить фрагменты, потерявшие ак- туальность или ставшие низкоприо- ритетными. Переработка требований (с устране- нием фрагментов, потерявших акту- альность) и переработка фрагмен- тов, у которых изменился приоритет (часто изменение приоритета ведёт и к изменению формулировки требо- вания). Прослеживаемость (traceability 92 , 93 ). Прослеживаемость бывает вертикаль- ной (vertical traceability 94 ) и горизонтальной (horizontal traceability 95 ). Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, ар- хитектурными решениями и т.д. Для обеспечения прослеживаемости часто используются специальные ин- струменты по управлению требованиями (requirements management tool 96 ) и/или матрицы прослеживаемости (traceability matrix 97 ). Типичные проблемы с прослеживаемостью: • Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрёстных ссылок. • При разработке требований не были использованы инструменты и техники управления требованиями. • Набор требований неполный, носит обрывочный характер с явными «пробе- лами». Способы обнаружения проблем Способы устранения проблем Нарушения прослеживаемости ста- новятся заметны в процессе работы с требованиями, как только у нас возникают остающиеся без ответа вопросы вида «откуда взялось это требование?», «где описаны сопут- ствующие (связанные) требова- ния?», «на что это влияет?». Переработка требований. Воз- можно, придётся даже менять струк- туру набора требований, но всё точно начнётся с расстановки мно- жества перекрёстных ссылок, позво- ляющих осуществлять быструю и прозрачную навигацию по набору требований. 92 Traceability. The ability to identify related items in documentation and software, such as requirements with associated tests. [ISTQB Glossary] 93 A traceable requirement can be linked both backward to its origin and forward to derived requirements, design elements, code that implements it, and tests that verify its implementation. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 94 Vertical traceability. The tracing of requirements through the layers of development documentation to components. [ISTQB Glos- sary] 95 Horizontal traceability. The tracing of requirements for a test level through the layers of test documentation (e.g. test plan, test design specification, test case specification and test procedure specification or test script). [ISTQB Glossary] 96 Requirements management tool. A tool that supports the recording of requirements, requirements attributes (e.g. priority, knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and violations to predefined requirements rules. [ISTQB Glossary] 97 Traceability matrix. A two-dimensional table, which correlates two entities (e.g., requirements and test cases). The table allows tracing back and forth the links of one entity to the other, thus enabling the determination of coverage achieved and the assess- ment of impact of proposed changes. [ISTQB Glossary] Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 46/298 Модифицируемость (modifiability 98 ). Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований. Можно гово- рить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а её изменение не приводит к нарушению иных описанных в этом перечне свойств. Типичные проблемы с модифицируемостью: • Требования неатомарны (см. «атомарность») и непрослеживаемы (см. «про- слеживаемость»), а потому их изменение с высокой вероятностью порождает противоречивость (см. «непротиворечивость»). • Требования изначально противоречивы (см. «непротиворечивость»). В такой ситуации внесение изменений (не связанных с устранением противоречиво- сти) только усугубляет ситуацию, увеличивая противоречивость и снижая прослеживаемость. • Требования представлены в неудобной для обработки форме (например, не использованы инструменты управления требованиями, и в итоге команде приходится работать с десятками огромных текстовых документов). Способы обнаружения проблем Способы устранения проблем Если при внесении изменений в набор требований, мы сталкиваемся с проблемами, характерными для ситуации потери прослеживаемо- сти, значит – мы обнаружили про- блему с модифицируемостью. Также модифицируемость ухудша- ется при наличии практически лю- бой из рассмотренных в данном раз- деле проблем с требованиями. Переработка требований с перво- степенной целью повысить их про- слеживаемость. Параллельно можно устранять иные обнаружен- ные проблемы. Проранжированность по важности, стабильности, срочности (ranked 99 for importance, stability, priority ). Важность характеризует зависимость успеха про- екта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования. Типичные проблемы с проранжированностью состоят в её отсутствии или не- верной реализации и приводят к следующим последствиям. • Проблемы с проранжированностью по важности повышают риск неверного распределения усилий проектной команды, направления усилий на второ- степенные задачи и конечного провала проекта из-за неспособности про- дукта выполнять ключевые задачи с соблюдением ключевых условий. • Проблемы с проранжированностью по стабильности повышают риск выпол- нения бессмысленной работы по совершенствованию, реализации и тести- рованию требований, которые в самое ближайшее время могут претерпеть кардинальные изменения (вплоть до полной утраты актуальности). • Проблемы с проранжированностью по срочности повышают риск нарушения 98 To facilitate modifiability, avoid stating requirements redundantly. Repeating a requirement in multiple places where it logically belongs makes the document easier to read but harder to maintain. The multiple instances of the requirement all have to be modified at the same time to avoid generating inconsistencies. Cross-reference related items in the SRS to help keep them synchronized when making changes. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 99 Prioritize business requirements according to which are most important to achieving the desired value. Assign an implementation priority to each functional requirement, user requirement, use case flow, or feature to indicate how essential it is to a particular product release. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] Свойства качественных требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 47/298 желаемой заказчиком последовательности реализации функциональности и ввода этой функциональности в эксплуатацию. Способы обнаружения проблем Способы устранения проблем Как и в случае с актуальностью и обяза- тельностью требований, здесь лучшим способом обнаружения недоработок яв- ляется постоянный (периодический) пе- ресмотр требований (желательно – с участием заказчика), в процессе кото- рого можно обнаружить неверные значе- ния показателей срочности, важности и стабильности обсуждаемых требований. Прямо в процессе обсуждения требований с заказчиком (во время пересмотра требований) стоит вносить правки в значе- ния показателей срочности, важности и стабильности об- суждаемых требований. Корректность (correctness 100 ) и проверяемость (verifiability 101 ). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно ска- зать, что они не выполняются, если нарушено хотя бы одно из вышеперечислен- ных). В дополнение можно отметить, что проверяемость подразумевает возмож- ность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответ- ствует требованию. К типичным проблемам с корректностью также можно отнести: • опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну осмысленную аббревиатуру в другую также осмысленную, но не имеющую отношения к некоему контексту; такие опечатки крайне сложно заметить); • наличие неаргументированных требований к дизайну и архитектуре; • плохое оформление текста и сопутствующей графической информации, грамматические, пунктуационные и иные ошибки в тексте; • неверный уровень детализации (например, слишком глубокая детализация требования на уровне бизнес-требований или недостаточная детализация на уровне требований к продукту); • требования к пользователю, а не к приложению (например: «пользователь должен быть в состоянии отправить сообщение» — увы, мы не можем влиять на состояние пользователя). Способы обнаружения проблем Способы устранения проблем Поскольку здесь мы имеем дело с «интегральной» проблемой, обнару- живается она с использованием ра- нее описанных способов. Отдель- ных уникальных методик здесь нет. Внесение в требования необходи- мых изменений – от элементарной правки обнаруженной опечатки, до глобальной переработки всего набора требований. Хорошее краткое руководство по написанию качественных требований представлено в статье «Writing Good Requirements — The Big Ten Rules » 102 100 Each requirement must accurately describe a capability that will meet some stakeholder’s need and must clearly describe the functionality to be built. [ «Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty] 101 If a requirement isn’t verifiable, deciding whether it was correctly implemented becomes a matter of opinion, not objective analysis. Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable. [ «Software Requirements (3rd edition) », Karl Wiegers and Joy Beatty] 102 «Writing Good Requirements — The Big Ten Rules», Tyner Blain [ http://tynerblain.com/blog/2006/05/25/writing-good-require- ments-the-big-ten-rules/ ] Техники тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 48/298 2.2.6. Техники тестирования требований Тестирование документации и требований относится к разряду нефункцио- нального тестирования (non-functional testing 103 ). Основные техники такого тестиро- вания в контексте требований таковы. Взаимный просмотр (peer review 104 ). Взаимный просмотр («рецензирова- ние») является одной из наиболее активно используемых техник тестирования тре- бований и может быть представлен в одной из трёх следующих форм (по мере нарастания его сложности и цены): • Беглый просмотр (walkthrough 105 ) может выражаться как в показе автором своей работы коллегам с целью создания общего понимания и получения обратной связи, так и в простом обмене результатами работы между двумя и более авторами с тем, чтобы коллега высказал свои вопросы и замечания. Это самый быстрый, дешёвый и часто используемый вид просмотра. Для запоминания: аналог беглого просмотра — это ситуация, когда вы в школе с одноклассниками проверяли перед сдачей сочинения друг друга, чтобы найти описки и ошибки. • Технический просмотр (technical review 106 ) выполняется группой специали- стов. В идеальной ситуации каждый специалист должен представлять свою область знаний. Тестируемый продукт не может считаться достаточно каче- ственным, пока хотя бы у одного просматривающего остаются замечания. Для запоминания: аналог технического просмотра — это ситуация, когда не- кий договор визирует юридический отдел, бухгалтерия и т.д. • Формальная инспекция (inspection 107 ) представляет собой структурирован- ный, систематизированный и документируемый подход к анализу документа- ции. Для его выполнения привлекается большое количество специалистов, само выполнение занимает достаточно много времени, и потому этот вари- ант просмотра используется достаточно редко (как правило, при получении на сопровождение и доработку проекта, созданием которого ранее занима- лась другая компания). Для запоминания: аналог формальной инспекции — это ситуация генераль- ной уборки квартиры (включая содержимое всех шкафов, холодильника, кла- довки и т.д.). Вопросы. Следующей очевидной техникой тестирования и повышения каче- ства требований является (повторное) использование техник выявления требова- ний, а также (как отдельный вид деятельности) — задавание вопросов. Если хоть что-то в требованиях вызывает у вас непонимание или подозрение — задавайте вопросы. Можно спросить представителей заказчика, можно обратиться к справоч- ной информации. По многим вопросам можно обратиться к более опытным колле- гам при условии, что у них имеется соответствующая информация, ранее получен- ная от заказчика. Главное, чтобы ваш вопрос был сформулирован таким образом, чтобы полученный ответ позволил улучшить требования. 103 Non-functional testing. Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability and portability. [ISTQB Glossary] 104 Peer review. A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection, technical review and walkthrough. [ISTQB Glossary] 105 Walkthrough. A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content. [ISTQB Glossary] 106 Technical review. A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. [ISTQB Glossary] 107 Inspection. A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure. [ISTQB Glossary] Техники тестирования требований Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 49/298 Поскольку здесь начинающие тестировщики допускают уйму ошибок, рас- смотрим подробнее. В таблице 2.2.a приведено несколько плохо сформулирован- ных требований, а также примеров плохих и хороших вопросов. Плохие вопросы провоцируют на бездумные ответы, не содержащие полезной информации. Таблица 2.2.a — Пример плохих и хороших вопросов к требованиям |