Сколько раз можно наступать на одни и те же грабли!!! Как часто, бывает произносит программист эту фразу очередной раз исправляя одну и ту же ошибку в коде или поправляя элементы пользовательского интерфейса, которые очередной раз куда то расползлись в самый неподходящий момент — за 10 минут до демонстрации начальнику.
Или тестер бьется в истереке и готов всех разорвать, так как 150 раз уже тыкал носом в одну и ту же ошибку, но она повторяется с завидным постоянством у каждого из членов команды разработчиков…
Сегодня я хочу рассказать об одном очевидном, при этом часто недооцениваемом средстве избавления от мелких досадных и при этом часто возникающих ошибок.
А решение совершенно очевидное: Нужно всего лишь собрать список этих повторяющихся проблем, задокументировать, назвать его красивым именем «Check List» и положить каждому разработчику и тестеру на стол. Перед тем, как отдавать свой код на тестирование разработчик обязуется пройти по каждому пункту в списке и проверить, что все, что он только что сделал соответствует принятым договоренностям. Чтобы быть более конкретным приведу пару примеров, близких к тому, что мы используем в своей работе.
Процесс сдачи работы на проверку
Сначала опишу в двух словах процесс сдачи выполеннной задачи на тестирование. Для того, чтобы получить качественный продукт, проверка работы у нас осуществляется в два этапа. Первый этап — тестирование системы с точки зрения ее пользователей.
Проверяется
- функциональность системы,
- работоспособность интерфейсных элементов,
- единство стиля затронутых при выполнении задачи форм, отчетов и т.п
Второй этап — проведение инспекции исходных текстов приложения опытным разработчиком, часто лидером проекта
- с целью выявления потенциально слабых мест
- для проверки соответствия написанного кода принятым в команде соглашениям по его оформлению
- для проверки на наличие необходимых проверок значений и вызовов процедур аудита
- для выявления пробелов в знаниях исполнителя задачи (с целью сбора компромата планирования обучения)
Для того, чтобы подготовить выполненую задачу к такой проверке исполнитель имеет под рукой даже не один а два документа, у нас они называются Programming CheckList и Testing CheckList соответственно.
Тестер тоже использует такой же документ Testing CheckList как и разработчик и не начинает собственно тестирование выполенной задачи до того, как пройдет по пунктам CheckList. Программист получает строгое взыскание за систематическую сдачу работы, не соответствующей списку правил в документе.
Примеры документов
Сразу скажу, что документы мы готовим для каждого проекта свои, так как специфика работы может отличаться. Примеры ниже призваны лишь донести их суть а для работы можно легко разработать свой вариант под конкретную задачу.
Testing CheckList
- Метки и поля ввода должны быть выровнены относительно друг друга
- Для вывода текста меток должен использоваться шрифт «<Font>», цвет «<Color>», размер «<Size>»
- Для текста в полях ввода должен использоваться шрифт «<Font>», цвет «<Color>», размер «<Size>»
- Проверить, сохраняются ли данные при попытке сохранения текста максимально возможной длины в полях ввода
- После сохранения формы, в полях ввода которой введены специальные символы (если по соображениям логики допускается их вводить в эти поля) введенные значения должны сохраняться в точности такими какми они были введены
- Убедиться, что значения в полях ввода проверяются на корректность и в случае ошибки ввода пользователь видит внятное сообщение об ошибке
- При изменении размера окна приложения содержимое в окне выглядит корректно
- Расположение и внешний вид элементов интерфейса выполнен в едином стиле и соответствует общей концепции дизайна приложения
- Попробовать выполнить основные типовые действия в разных браузерах (для случая разработки сайтов) чтобы убедиться в корректности работы и правильности верстки страниц
- Проверить работу горячих клавиш
- Убедиться, что правильно задан TabOrder
Programming CheckList
- При работе с датами учитывается текущие локальные настройки
- В коде присутствуют конструкции, позволяющие проводить диагностику выполнения программы
- В коде для решения типовых задач применяются типовые шаблоны проектирования
- Производится проверка данных на NULL везде, где такое значение может быть получено
- «Проглатывание» исключений в большинстве случаев недопустимо
- Вычисления, особенно в циклах, не должны без необходимости повторяться
- Для выполения действий, автоматизация которых предусмотрена применяемым Framework должны применяться средства этого Framework, если нет весомых причин использовать самодельные решения ( a) не нужно изобретать велосипед; б)возможно разработчик просто недостаточно хорошо знает используемый инструмент
- Разумное использование комментариев
- Использование методов, снижающих нагрузку на сервер
- Слова, из которых состоят названия переменных имеют правильное написание
Применение подобных документов уже помогло нам сэкономить массу времени и нервов и я надеюсь что помог кому то начать использовать этот полезный инструмент в своей работе