Тестирование программного обеспечения. Базовый курс. 3-е издание


Плохое оформление вопросов и комментариев



Pdf көрінісі
бет81/307
Дата03.07.2023
өлшемі5,03 Mb.
#179304
1   ...   77   78   79   80   81   82   83   84   ...   307
Байланысты:
Software Testing - Base Course (Svyatoslav Kulikov) - 3rd edition - RU

Плохое оформление вопросов и комментариев.
Старайтесь сделать 
ваши вопросы и комментарии максимально простыми для восприятия. Помните не 
только о краткости формулировок, но и об оформлении текста (см., например, как 
на рисунке 2.2.j вопросы структурированы в виде списка — такая структура воспри-
нимается намного лучше, чем сплошной текст). Перечитайте свой текст, исправьте 
опечатки, грамматические и пунктуационные ошибки и т.д. 
Описание проблемы не в том месте, к которому она относится.
Класси-
ческим примером может быть неточность в сноске, приложении или рисунке, кото-
рая почему-то описана не там, где она находится, а в тексте, ссылающемся на со-
ответствующий элемент. Исключением может считаться противоречивость, при ко-
торой описать проблему нужно в обоих местах. 
Ошибочное восприятие требования как «требования к пользователю».
Ранее (см. «Корректность» в «Свойства качественных требований») мы говорили, 
что требования в стиле «пользователь должен быть в состоянии отправить сооб-
щение» являются некорректными. И это так. Но бывают ситуации, когда проблема 
намного менее опасна и состоит только в формулировке. Например, фразы в стиле 
«пользователь может нажать на любую из кнопок», «пользователю должно быть 
видно главное меню» на самом деле означают «все отображаемые кнопки должны 


Типичные ошибки при анализе и тестировании требований
Тестирование программного обеспечения. Базовый курс. 
© EPAM Systems, 2015–2023
 
Стр: 66/301 
быть доступны для нажатия» и «главное меню должно отображаться». Да, эту недо-
работку тоже стоит исправить, но не следует отмечать её как критическую про-
блему. 
Скрытое редактирование требований.
Эту ошибку можно смело отнести к 
разряду крайне опасных. Её суть состоит в том, что тестировщик произвольно вно-
сит правки в требования, никак не отмечая этот факт. Соответственно, автор доку-
мента, скорее всего, не заметит такой правки, а потом будет очень удивлён, когда 
в продукте что-то будет реализовано совсем не так, как когда-то было описано в 
требованиях. Потому простая рекомендация: если вы что-то правите, обязательно 
отмечайте это (средствами вашего инструмента или просто явно в тексте). И ещё 
лучше отмечать правку как предложение по изменению, а не как свершившийся 
факт, т.к. автор исходного документа может иметь совершенно иной взгляд на си-
туацию. 


Достарыңызбен бөлісу:
1   ...   77   78   79   80   81   82   83   84   ...   307




©engime.org 2024
әкімшілігінің қараңыз

    Басты бет