Тестирование программного обеспечения. Базовый курс. 3-е издание
жүктеу/скачать 5,03 Mb. Pdf көрінісі
|
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU
- Бұл бет үшін навигация:
- Walkthrough.
- Плохое требование Плохие вопросы Хорошие вопросы
| 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] 105 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] 106 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] 107 Technical review. A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. [ISTQB Glossary] 108 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–2023 Стр: 52/301 Поскольку здесь начинающие тестировщики допускают уйму ошибок, рас- смотрим подробнее. В таблице 2.2.a приведено несколько плохо сформулирован- ных требований, а также примеров плохих и хороших вопросов. Плохие вопросы провоцируют на бездумные ответы, не содержащие полезной информации. Таблица 2.2.a — Пример плохих и хороших вопросов к требованиям Плохое требование Плохие вопросы Хорошие вопросы «Приложение должно быстро запускаться». «Насколько быстро?» (На это вы рискуете получить ответы в стиле «очень быстро», «макси- мально быстро», «нууу… просто быстро»). «А если не получится быстро?» (Этим вы рискуете просто уди- вить или даже разозлить заказ- чика.) «Всегда?» («Да, всегда». Хм, а вы ожидали другого ответа?) «Каково максимально допусти- мое время запуска приложения, на каком оборудовании и при ка- кой загруженности этого обору- дования операционной системой и другими приложениями? На до- стижение каких целей влияет скорость запуска приложения? Допускается ли фоновая за- грузка отдельных компонентов приложения? Что является кри- терием того, что приложение за- кончило запуск?» «Опционально должен поддерживаться экспорт документов в формат ». «Любых документов?» (Ответы «да, любых» или «нет, только от- крытых» вам всё равно не помо- гут.) «В PDF какой версии должен производиться экспорт?» (Сам по себе вопрос хорош, но он не даёт понять, что имелось в виду под «опционально».) «Зачем?» («Нужно!» Именно так хочется ответить, если вопрос не раскрыт полностью.) «Насколько возможность экс- порта в PDF важна? Как часто, кем и с какой целью она будет ис- пользоваться? Является ли PDF единственным допустимым фор- матом для этих целей или есть альтернативы? Допускается ли использование внешних утилит (например, виртуальных PDF- принтеров) для экспорта доку- ментов в PDF?» «Если дата события не указана, она выбирается автоматически». «А если указана?» (То она ука- зана. Логично, не так ли?) «А если дату невозможно вы- брать автоматически?» (Сам во- прос интересен, но без поясне- ния причин невозможности зву- чит как издёвка.) «А если у события нет даты?» (Тут автор вопроса, скорее всего, хотел уточнить, обязательно ли это поле для заполнения. Но из самого требования видно, что обязательно: если оно не запол- нено человеком, его должен за- полнить компьютер.) «Возможно, имелось в виду, что дата жүктеу/скачать 5,03 Mb. Достарыңызбен бөлісу:
|