Предисловие
К написанию этой статьи натолкнули комментарии к посту habrahabr.ru/company/infopulse/blog/170777, так сложилось что я чаще оказываюсь со стороны заказчика, а не разработчика и именно она определила тему первого поста на Хабрахабре. Меня привели в негодование комментарии по поводу того, что любой чих не описанный в ТЗ должен быть оплачен. А теперь давайте поподробнее.
ТЗ смертного
ТЗ человека не хорошо разбирающегося в веб технологиях, имеющий свой личный сайт (интернет магазин, сайт визитку), который хочет сделать калькулятор по каким-то числовым параметрам и пару текстовыми полями, как телефон, e-mail, ФИО и отправлять их на почту клиента. ТЗ примерно будет выглядеть так:
На сайт site.ru нужно сделать калькулятор, который будет рассчитывать стоимость заказа по параметрам a и b, формула "(a*b)/2", надо что бы пользователю показали стоимость заказа, после чего он бы смог заполнить ФИО, e-mail и телефон и отправить запрос для связи на почту «почта». Данные от сайта:
Скупое ТЗ, которое рождается простыми смертными и конечными клиентами, которые хотят улучшить свой ресурс, но не знают что еще написать в ТЗ, т.к. не в курсе тонких моментов.
Один час разработки
Ряд программистов на такое ТЗ, ответят, мне нужен один час и все будет готово. Что же может получить заказчик после часа ожидания? Рассортировал по степени наглости, все примеры проецировал с живых примеров:
- Клиент получит просто скрипт калькулятора на свою почту
- При некорректном вводе каких-либо данных, не будет вывода ошибки
- Отсутствие проверки на валидацию данных
- На почту прийдет полотно введенных данных без намека на форматирование информации
- Отсутствие хоть элементарных проверок полей на безопасность
И когда заказчик начинает паниковать и узнает о всех вышеперечисленных моментах, он естественно обращается к своему программисту с логичным вопросом: «Где?». На что получает логичный ответ для большинства, что это не было указано в ТЗ, а следовательно дополнительно оплачивается.
Почему все не так
Теперь подумаем почему эта ситуация ужасна. Для этого вспомним лекции «Тестирования ПО», которые наверняка преподавали у многих в ВУЗах, а именно лекцию о типизации ошибок, именно ОШИБОК:
- отсутствие у объектов пользовательского интерфейса всплывающих текстовых подсказок
- не проверяются допустимые диапазоны значений вводимых параметров данных
- не контролируется противоречивость данных
- отсутствует гибкость при индикации ошибок в данных (например: не сообщается обо всех найденных ошибках, если это возможно и разумное, а вместо этого завершает выполнение)
- неправильные или излишние сообщения; ненужные, отвлекающие сообщения
- неверно отображаются или печатаются результаты выполнения команды
То есть фактически программист отдал продукт с ошибками и согласен их исправлять только за дополнительную оплату.
Дорогие программисты, я понимаю когда заказчик наглеет и просит дополнить функционал явно выходящий за рамки стандартного качественного продукта, но не заставляйте клиентов платить за свои ошибки. Хороший программист должен думать о тех кто будет пользоваться его продуктом, какого масштаба и предназначения он бы не был.
Для интересующихся, ISO 9126, описывающая качественные характеристики ПО
А так же вырванная лекция из конспекта по тестированию