Прошлая часть: Еще немного про жизненный цикл и методологии разработки
Всем доброго времени суток. Давайте продолжим обучение тестированию с нуля.
Вот мы и добираемся до самого тестирования. Из предыдущих частей понятно, что будут вполне конкретные задачи с не менее конкретными требованиями. Разумеется, ваша задача будет заключаться в тестировании этих конкретных задач, но с чего же начать. Надо понимать следующие моменты:
- Задачи ставятся не устно и не пересылаются по почте. Для этого существуют так называемые «Task management system» или по-русски «Системы для управления задачами». В этих системах оформляются доработки и переводятся с одного исполнителя на другого. (Например, с разработчика на тестировщика). Свои задачи необходимо отслеживать, чтобы не потратить время впустую.
- Задачи надо где-то тестировать. Для тестирования организуются специальные «тестовые стенды» (или тестовые контуры) на которые каким-либо образом (обычно через специализированное ПО) устанавливается конкретная версия программного обеспечения (или по-простому «сборка»). Велика вероятность ситуации, что исполнителем по задаче вы стали (читать как «задачу можно тестировать»), но на тестовом стенде стоит сборка, в которой вы не обнаружите функциональность нужной вам задачи. Происходит это из-за того, что код попал в сборку более высокой версии и вам необходимо организовать процесс установки новой версии на тестовый стенд.
- Нельзя просто так взять и начать тестировать задачу. Нет, ну можно, конечно, но задумайтесь каким будет качество вашей работы. Вы же, покупая новую стиральную машину, не начинаете жать на все кнопки подряд в надежде на то, что получите постиранные вещи. Вы читаете инструкцию, подключаете стиральную машину к канализации и подаче воды. В тестировании всё аналогично. Хотите сделать работу качественно – хорошо подготовьтесь.
Так как мы хотим протестировать задачу качественно, а иначе кто если не мы – надо идти в требования. К слову, мы можем туда идти заранее, если знаем, что рано или поздно задача достанется на тестирование именно нам. Чем раньше мы попадём в требования – тем лучше, потому что проблема, выявленная на самом раннем уровне (пока она не попала в написанный код), является самой «дешевой» для команды и для бизнеса. Согласитесь, проще предотвратить проблему, чем её устранять. Что нам дают требования:
- Понимание «Что», а главное «Зачем» будет разрабатываться. Вы должны понимать какую из текущих или будущих проблем пользователей решает доработка системы. Постарайтесь понять потребность будущего пользователя. Чем лучше вы поставите себя на место будущего пользователя системы – тем лучше у вас получится протестировать функционал.
- Понимание «Как будет устроена будущая часть ПО». На простом примере – пользовательский интерфейс. Названия кнопок, расположение кнопок, описание ожидаемого результата после нажатия кнопок, расположения полей ввода, допустимые для ввода значения, ожидаемый результат при вводе недопустимых значений.
- Понимание «какие входные данные нужны для работы с будущей частью системы». Как говорится – «предупрежден, значит вооружен», «береги честь смолоду» и «готовь тестовые данные заранее». Бывают случаи, когда для тестирования необходим целый перечень специфических условий, чтобы тест прошел. Мой личный рекорд – необходимость наличия данных в 60+ таблицах базы данных, чтобы просто приступить к тестированию.
- Понимание «что не учел системный аналитик» или «какие моменты необходимо уточнить». Читая любой текст, вы можете его трактовать по-разному. Если вы видите какую-то неоднозначность в тексте – самое время выяснить точную и однозначную формулировку. Мой вам совет – старайтесь избегать вопросов, которые дают системному аналитику выбор из ваших вариантов ответа. На мой взгляд, вопрос «Поле ввода даты должно заполняться в формате дд.мм.гггг?» намного хуже вопроса «В каком формате должно заполняться поле ввода даты?», потому что вы даёте опцию принять ваш вариант без дополнительного анализа «А как на самом деле надо?».
- Понимание «какой список проверок необходимо провести», чтобы вынести решение о возможности внедрения доработки в промышленную эксплуатацию. Тут всё просто – каждое утверждение в требованиях надо проверить. Ну, а если не каждое (например, вы ограничены во времени), то наиболее критичные проверки.
В целом, к требованиям со стороны аналитики также предъявляются критерии качества. Обратимся к статье Натальи Желновой на хабре. Требования должны обладать следующими характеристиками:
- Полнота (отдельного требования и системы требований) — требование должно содержать всю необходимую информацию для его реализации. В него включается вся информация об описываемом параметре, известная на момент описания. Система требований также не должна содержать невыявленных и неопределенных требований. Причины неполноты описания следует явно объявлять.
- Однозначность — требование должно быть внутренне непротиворечиво и все работающие с ним должны понимать его одинаково. Требования следует выражать просто, кратко и точно, используя известные термины. Обычно базовые знания читателей спецификации требований к ПО различаются. Поэтому в ее состав нужно включить раздел с определением понятий прикладной области, используемых при определении требований. Пример, неоднозначного требования. «Период обновления экрана должен быть не менее 20 сек.»
- Корректность отдельного требования и согласованность (непротиворечивость) системы требований — требование не должно содержать в себе неверной, неточной информации, а отдельные требования в системе требований не должны противоречить друг другу.
- Необходимость — требование должно отражать возможность или характеристику ПО, действительно необходимую пользователям, или вытекающую из других требований.
- Осуществимость — включаемое в спецификацию требование должно быть выполнимым при заданных ограничениях операционной среды. Осуществимость требований проверяется в процессе анализа осуществимости разработчиком. В частности, для нефункциональных требований проверяется возможность достижения указанных численных значений при существующих ограничениях.
- Проверяемость — проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того, что ПО удовлетворяет этому требованию. Каждое требование (особенно нефункциональное) должно содержать достаточно информации для однозначной проверки его реализации. Иначе, факт реализации будет основываться на мнении, а не на анализе, что приведет к проблемам при сдаче готового ПО. Для атрибутов качества (как мы помним, отдельной разновидности нефункциональных требований) критерием проверямости можно считать наличие численных значений характеристик качества продукта или системы
Если коротко – читая требования вы должны: понимать «Зачем разрабатывается функционал»; понимать, что «Логика работы конкретной части системы не противоречит логике работы остальных частей системы»; понимать, что «В текущих реалиях системы реализовать доработку возможно»; понимать, что «Часть системы реально проверить конечным перечнем проверок»; понимать, что «Все члены команды будут трактовать требования одинаково».
Пример тестирования требований
Давайте уже хоть что-то протестируем. В качестве примера я, как теоретический системный аналитик, набросал требования для формы регистрации на каком-то абстрактном сайте. Требования выглядят следующим образом:
Ну и что тут тестировать? Вроде бы всё как обычно – вводишь свой логин, вводишь свой пароль, регистрируешься, входишь в систему и пользуешься. Давайте запасемся вопросами «Что будет если … ?», «Какая минимальная / максимальная длина поля … ?», «Какие допустимые символы для ввода в поле …?», «Является ли поле … обязательным для заполнения?». Уже наводит на какие-то мысли, не правда ли?
Давайте пойдем по порядку.
Поле ввода «логин». Его разберем подробно, далее будет уже интуитивно понятно:
- «Что будет если пользователь вводит логин, который уже существует в системе?». Да, у нас указано, что логин должен быть уникален, но не указано однозначно как система должна реагировать на неуникальный логин. Будь то «Поле подсвечивается красным, а под полем отображается подсказка «Введенный логин уже существует в системе, выберите другой»» или что-то в этом стиле. Конечно, разработчик сделает проверку на уникальность, только ошибка с сервера в виде «Login field should be unique» менее понятна для пользователя, чем читаемая ошибка в пользовательском интерфейсе
- «Что будет, если пользователь введет логин, который уже существует в системе, но в другом регистре». Т.е. в системе существует логин «superuser», а пользователь регистрируется как «SuPeRuSeR». Очевидно, что логин не должен быть чувствительным к регистру, а разработчик должен добавить на это соответствующие проверки.
- «Какая минимальная / максимальная допустимая длина поля ввода «Логин»?». Странный вопрос, но уверен, что существуют «специфические» пользователи с крайне длинными логинами. Вполне реальна ситуация, когда пользователь может получить ошибку в стиле «… ORA-01401: Inserted value too large for column…» просто по причине того, что он вводил логин длиной 31 символ, а в базе данных вашей системы для поля «логин» максимальная длина 30 символов. С минимальной длиной в данном конкретном случае проще, но лучше уточнить, на всякий случай.
- «Является ли поле ввода «Логин» обязательным для заполнения?». Вопрос не менее странный, чем предыдущий, но мы же делаем требования «Однозначными». Откуда вы знаете, что в голове у разработчика Васи, который недавно закончил онлайн курсы и готов штамповать по 15 задач за двухнедельный спринт? «Разработчик» человек простой – как ему написали – так он и сделал. Стоит отметить, что немало разработчиков также тестируют требования при написании кода, за что им плюсик в карму.
- «Что будет, если пользователь не заполнит поле ввода «Логин» и нажмет на кнопку зарегистрироваться?». Вопрос аналогичен вопросу «Что будет если пользователь вводит логин, который уже существует в системе?». Лучше подсветить недалекому пользователю, что поле логин является обязательным. И дополнительно отобразить текст «Поле «Логин» является обязательным для регистрации. Пожалуйста, заполните его»
- «Какие допустимые символы для ввода в поле «Логин»?». Очевидно – «английские буквы и цифры», скажете вы. А что, если заказчик вашего ПО – шейх из эмиратов и вам надо предусмотреть для ввода арабские символы? А что на счет знаков « !»№;%:?*()_+=-., »? Что должно происходить, в случае если в поле введен неразрешенный символ? На все эти вопрос нужно получить ответы.
Поле ввода «Пароль»:
- «Какая минимальная / максимальная допустимая длина поля ввода «Пароль»?»
- «Какие символы допустимы для ввода в поле «Пароль»?»
- «Является ли поле ввода «Пароль» обязательным для заполнения?»
- «Что будет, если пользователь оставит поле ввода «Пароль» пустым и нажмет на кнопку «Зарегистрироваться»?
И вопросы со «звездочкой», которые вы черпаете из своего пользовательского опыта:
- «Должна ли в поле ввода «Пароль» быть кнопка, по нажатию на которую будет отображаться введенный пароль?». Удобно ведь перепроверить свой введенный пароль, иногда.
- «Должна ли быть какая-то дополнительная проверка на «надежность» пароля?». Под надежностью мы понимаем, что «qwerty123456» это ненадежный пароль, а «SuPeR_PaSs_912%3%*» это надежный пароль.
Поле ввода «Повторите пароль»:
- «Какая минимальная / максимальная допустимая длина поля ввода «Повторите пароль»?»
- «Какие символы допустимы для ввода в поле «Повторите пароль»?»
- «Является ли поле ввода «Повторите пароль» обязательным для заполнения?»
- «Что будет, если пользователь оставит поле ввода «Повторите пароль» пустым и нажмет на кнопку «Зарегистрироваться»?
- «Должна ли в поле ввода «Повторите пароль» быть кнопка, по нажатию на которую будет отображаться введенный пароль?».
- «Что будет, если пароль, введенный в поле «Повторите пароль» не соответствует паролю, введенному в поле «Повторите пароль»?»
Кнопка «Зарегистрироваться»:
- «Что будет с кнопкой «Зарегистрироваться» если одно из обязательных полей ввода не заполнено?». Зачем нам отправлять на сервер целую кучу запросов, которые заранее обречены на неудачу?
- «Что будет, если пользователь заполнит все поля ввода корректно, но будет регистрироваться во время недоступности сервера?». Например, вы обновляете ПО на сервере и он временно недоступен. Согласитесь, что текст «Сервер на данный момент недоступен, попробуйте зарегистрироваться позднее» намного понятнее пользователю, чем ошибка «503 Service Unavailable».
- «Что должно произойти при успешной регистрации пользователя?» Его должно перенаправить на какой-то другой экран? Как-то уведомить об успешности его действий?
Давайте резюмируем, что сегодня узнали.
- Требования тестировать надо. Чем больше вы уточните на этапе требований – тем более качественным получится итоговое ПО.
- Не стесняйтесь задавать вопросы, даже если они кажутся вам глупыми. Ваш вопрос может сэкономить команде от пары часов до пары недель работы. Хороший системный аналитик вам скажет «спасибо».
- Используйте свой жизненный опыт пользователя, если он применим. Общее впечатление о продукте строится, в том числе, на основании удобных/неудобных мелочей. В ваших силах сделать продукт ориентированным для пользователей.
- Старайтесь задавать вопросы в общем виде, не давайте выбор из своих предположений. Вполне возможно, что ваш вариант хорошо звучит, но он далёк от потребностей заказчика.
Следующая часть: Составление проверок или первые шаги к тест-дизайну
Поддержать или поблагодарить можно здесь:
Поддержать или поблагодарить можете:
Лайком;
Комментарием;
Подпиской на канал;
#Блог_тестировщика #QA #Тестирование_ПО #Тестирование_с_нуля
