Тестирование GUI или сферический конь в вакууме
среда, октября 07, 2009Тестирование GUI (graphical user interface) очень редко проходит отдельно от основного функционального тестирования. Конечно:
- бывают большие проекты, где этому уделяется внимание;
- бывают пропущены серьезные проблемы, после которых все тестировщики проекта некоторое (зачастую недолгое) время тестируют ГУЙ / ГУИ / УЙ / УИ / UI / GUI
Вот скажите мне, разве можно тестировать то, принципы чего сам до конца не понимаешь? Разве можно найти ошибки в калькуляторе, если не знаешь таблицы умножения?
Многие менеджеры считают, что можно! И тогда все тестировщики становятся не только ГУИтестерами, они сразу ещё и ГУИтворители (ведь программисты исправят ровно так, как это скажет тестировщик).
Такая ситуация очень похожа на историю возникновения самих тестировщиков: программисты (или их начальники) поняли, что писать код и выпускать ПО без ошибок не одно и то же!
Я понимаю, должно пройти время, когда всем станет более-менее понятно: функциональное тестирование и тестирование графического интерфейса пользователя - должны делать разные по своей профессиональной подготовке люди!
Ладно, от теории перейдем к практике.
Предположим, что у нас есть окошко, где нужно выбрать период выпуска на прогулку сферического коня из вакуума. У нас есть два поля для ввода даты: Date From и Date To и кнока Submit.
Кроме дизайно-цветового решения всё выглядит даже ничего: можем задать даты и нажать кнопку Сабмит.
Умный тестировщик проверит эти поля на ввод разных значений: прошлый век, наше время, будущее время, (возможно) проверит ситуацию From >To и т.д. А вот когда этим начнет пользоваться конюх сферического коня в вакууме и реально захочет настроить даты выгула этого животного, он встретит реальные проблемы.
Одна из них - как мне настроить выгул коня только на один день? Поставить Date From = 10/07/2009 и Date To = 10/07/2009? Такое правило зачастую не сработает, ведь мудрые девелоперы сохраняют в базу данных ещё и время, а для обоих дат это будет 00:00:00. Можно поставить Date From = 10/07/2009 и Date To = 11/07/2009, но откуда мне как пользователю знать, что мой конь не будет гулять два дня, вместо одного?
Только методом проб и ошибок, запросов на изменение и приперательств с поставщиком ПО.
А вот если бы тестировщик посмотрел заранее в книгу про ГУИ тестирование, на минуту представил себя конюхом в штанах с кожей на жопе коленях, подумал о ежедневном выгуле любимого коня - все могло бы быть совсем иначе.
Не буду продолжать сей короткий опус, но скажу лишь одно - я сам попался на такое - мне не понравилось, и теперь буду представлять себя ковбоем/конюхом/или другим пользователем тестрируемого софта.
"Одна из них - как мне настроить выгул коня только на один день? Поставить Date From = 10/07/2009 и Date To = 10/07/2009? Такое правило зачастую не сработает, ведь мудрые девелоперы сохраняют в базу данных ещё и время, а для обоих дат это будет 00:00:00. Можно поставить Date From = 10/07/2009 и Date To = 11/07/2009, но откуда мне как пользователю знать, что мой конь не будет гулять два дня, вместо одного?" А причем тут GUI?
Андрей,
поправьте меня, если я не прав, но если то, что видит пользователь на экране вводит его в заблуждение или не дает ясного ответа на его вопросы - есть ошибки проектирования интерфейса.
В данном случае было бы здорово, если бы прямо в этом контроле было:
- либо возможность выбора времени
- либо заранее захардкоженное значение, например, Date From могло бы иметь такое значение /выбранная дата 00:00/, а поле Date To - /выбранная дата 23:59/.
В данном случае нет ничего, что могло бы ввести пользователя в заблуждение (в нашем контексте). Если при выборе одинаковых дат не отрабатывает корректная подстановка времени (например, ваш второй вариант) ни на клиенте, ни на сервере- то это ошибка проектирования (архитектурная, не гуи).
Частично вы правы, но ведь без указания времени я (только посмотрев на окошко) не могу быть точно уверен, как сработает это приложение:
- будет ли конь гулять один день, если я укажу одну и ту же дату?
- будет ли конь гулять один день, если я укажу два рядом стоящих дня?
ЕСли выгул коня - это для меня критический момент, рисковать которым у меня нет ни желания, ни возможности - однозначность ГУИ - первостепенная задача и мне как пользователю важно правильно понимать то, что я вижу.
Максим, у нас тут вчера были жаркие спроры на эту тему :) Пришли к выводу, что все-таки можно в таком варианте добиться корректной работы, без бага GUI. (например, автозаполнением поля2 значением поле1+сутки, при необходимом большем интервале- забиваем ручками. При меньшем- должно быть время.) Но в общем случае, конечно, это не выход и такие ситуации должны быть исключены. Такая ситуация видится при невыполнении, нереализации требований, которые просто обязаны быть в таком случае, когда критичны сроки, время и т.д.
О обязанности существования требований - вообще отдельный разговор. Ведь они могут быть совершенно разными: "Хочу, чтобы была два поля для выбора дат, когда я хочу выводить своего коня из вакуума".
А что даст автоматическое забивание +сутки. Мне, как конюху, всё равно не понятно:
- один день гуляет мой конь?
- или минимальный выгул коня - два дня?
На мой взгляд, в любом случае должно быть указано время: сутки ли это или неделя. Пользователь должен быть однозначно информирован о том, что он делает и что его действия значат.
Кроме того, меня порадовало, что данный пост подстрекнул на жаркие споры.. Надеюсь никого не побили?? Все живы-здоровы?
Я имел ввиду корректные требования, исключающие неоднозначность.
зы: в споре пытались истину родить)) Думаю теперь написать о классификации багов отдельно у себя в блоге. Так что велкам.
Андрей,
ок.. будет интересно почитать. Только линк дай.
anairguru.blogspot.com