Сколько раз можно наступать на одни и те же грабли!!! Как часто, бывает произносит программист эту фразу очередной раз исправляя одну и ту же ошибку в коде или поправляя элементы пользовательского интерфейса, которые очередной раз куда то расползлись в самый неподходящий момент — за 10 минут до демонстрации начальнику.

Или тестер бьется в истереке и готов всех разорвать, так как 150 раз уже тыкал носом в одну и ту же ошибку, но она повторяется с завидным постоянством у каждого из членов команды разработчиков…

Сегодня я хочу рассказать об одном очевидном, при этом часто недооцениваемом средстве избавления от мелких досадных и при этом часто возникающих ошибок.

А решение совершенно очевидное: Нужно всего лишь собрать список этих повторяющихся проблем, задокументировать, назвать его красивым именем «Check List» и положить каждому разработчику и тестеру на стол. Перед тем, как отдавать свой код на тестирование разработчик обязуется пройти по каждому пункту в списке и проверить, что все, что он только что сделал соответствует принятым договоренностям. Чтобы быть более конкретным приведу пару примеров, близких к тому, что мы используем в своей работе.

Процесс сдачи работы на проверку

Сначала опишу в двух словах процесс сдачи выполеннной задачи на тестирование. Для того, чтобы получить качественный продукт, проверка работы у нас осуществляется в два этапа. Первый этап — тестирование системы с точки зрения ее пользователей.

Проверяется

• функциональность системы,
• работоспособность интерфейсных элементов,
• единство стиля затронутых при выполнении задачи форм, отчетов и т.п

Второй этап — проведение инспекции исходных текстов приложения опытным разработчиком, часто лидером проекта

• с целью выявления потенциально слабых мест
• для проверки соответствия написанного кода принятым в команде соглашениям по его оформлению
• для проверки на наличие необходимых проверок значений и вызовов процедур аудита
• для выявления пробелов в знаниях исполнителя задачи (с целью сбора компромата планирования обучения)

Для того, чтобы подготовить выполненую задачу к такой проверке исполнитель имеет под рукой даже не один а два документа, у нас они называются Programming CheckList и Testing CheckList соответственно.

Тестер тоже использует такой же документ Testing CheckList как и разработчик и не начинает собственно тестирование выполенной задачи до того, как пройдет по пунктам CheckList. Программист получает строгое взыскание за систематическую сдачу работы, не соответствующей списку правил в документе.

Примеры документов

Сразу скажу, что документы мы готовим для каждого проекта свои, так как специфика работы может отличаться. Примеры ниже призваны лишь донести их суть а для работы можно легко разработать свой вариант под конкретную задачу.

Testing CheckList

1. Метки и поля ввода должны быть выровнены относительно друг друга
2. Для вывода текста меток должен использоваться шрифт «<Font>», цвет «<Color>», размер «<Size>»
3. Для текста в полях ввода должен использоваться шрифт «<Font>», цвет «<Color>», размер «<Size>»
4. Проверить, сохраняются ли данные при попытке сохранения текста максимально возможной длины в полях ввода
5. После сохранения формы, в полях ввода которой введены специальные символы (если по соображениям логики допускается их вводить в эти поля) введенные значения должны сохраняться в точности такими какми они были введены
6. Убедиться, что значения в полях ввода проверяются на корректность и в случае ошибки ввода пользователь видит внятное сообщение об ошибке
7. При изменении размера окна приложения содержимое в окне выглядит корректно
8. Расположение и внешний вид элементов интерфейса выполнен в едином стиле и соответствует общей концепции дизайна приложения
9. Попробовать выполнить основные типовые действия в разных браузерах (для случая разработки сайтов) чтобы убедиться в корректности работы и правильности верстки страниц
10. Проверить работу горячих клавиш
11. Убедиться, что правильно задан TabOrder

Programming CheckList

1. При работе с датами учитывается текущие локальные настройки
2. В коде присутствуют конструкции, позволяющие проводить диагностику выполнения программы
3. В коде для решения типовых задач применяются типовые шаблоны проектирования
4. Производится проверка данных на NULL везде, где такое значение может быть получено
5. «Проглатывание» исключений в большинстве случаев недопустимо
6. Вычисления, особенно в циклах, не должны без необходимости повторяться
7. Для выполения действий, автоматизация которых предусмотрена применяемым Framework должны применяться средства этого Framework, если нет весомых причин использовать самодельные решения ( a) не нужно изобретать велосипед; б)возможно разработчик просто недостаточно хорошо знает используемый инструмент
8. Разумное использование комментариев
9. Использование методов, снижающих нагрузку на сервер
10. Слова, из которых состоят названия переменных имеют правильное написание

Применение подобных документов уже помогло нам сэкономить массу времени и нервов и я надеюсь что помог кому то начать использовать этот полезный инструмент в своей работе