[QA Team Meeting. : Автоматизация тестирования.]
{09:45} У меня есть 45 минут, чтобы подготовиться к митингу. Цель - работающие тесты. Запускать их придётся удалённо, потому что с Firefox наблюдаются проблемы, решить которые пока нет времени, а Internet Explorer на компьютере в зелёной комнате не установлен. Придётся пользоваться удалённым доступом.
{11:47} Митинг был перенесён на после обеда, но время всё равно ушло. Запустил на удалённом компьютере мои тесты, они отработали нормально. А потом обсуждали с Лёнькой его ремарки относительно моей системы тестирования. Интересный подход он выбрал.
Для анализа он использовал две роли: 1) клиент - это тот, кто будет использовать систему тестирования; 2) разработчик - это тот, кто будет поддерживать эту систему и проектировать новые тесты. Получились ремарки с точки зрения каждой из этих ролей.
Сейчас попробую преобразовать эти ремарки в требования. А потом буду их реализовывать.

---

[Автоматизация. : Система тестирования. : Концепция.]
{12:03} Документацию нужно разделить на две части. Одна - для клиента, просто пользователя этой системы. Вторая - для разработчиков, для тех кто будет залезать в код. Соответственно, нужно разные стили изложения использовать. То есть учитывать предметную область каждого.
В каждый момент нужно быть готовым к тому, что кто-то другой продолжит эту работу. Поэтому нужно писать - и документацию, и код - так, чтобы этот другой человек легко вошёл в курс дел.
{12:34} В принципе, ничего особенного не выделилось. Лёнька написал о многих вещах, которые подразумевались, но ещё не реализованы. Однако главный вывод всё же можно сделать - "Думать о будущем!" Всегда держать это в голове. Даже если ты работаешь один, пиши для другого, то есть так, чтобы любой другой быстро понял, что ты сделал и почему именно так. Может быть, получится избыточность, зато в нужный момент этот подход окупится экономией и времени, и финансов.

---

[Автоматизация. : Регистрация категории. : Тест-элемент.]
{13:11} ... {14:10} Попытался сделать шаблон для тест-элемента, но ни интерфейс, ни абстрактный класс для этого не подошли. Из-за того, что в моих тест-элементах используются статические методы. Нужно будет ещё с Лёнькой проконсультироваться.

---

[QA Team Meeting. : Автоматизация тестирования.]
{16:45} На митинге родился такой список заданий:
1) автоматизировать тест "Клиент. Создание приёма";
2) автоматизировать тест "Специалист. Создание приёма";
3) автоматизировать тест "Создание календаря";
4) автоматизировать тест "Создание типа приёма";
5) обеспечить независимость тестов от языка интерфейса;
6) обеспечить работоспособность тестов для Internet Explorer и FireFox.
Плюс к этому мне нужно организовать обработку исключений и обеспечить логирование процесса тестирования.
Интересно это всё, конечно. И как же не хочется отвлекаться на другие дела. Например, на локализацию...

[Автоматизация. : Поиск категории по названию. : Тест-элемент.]
{09:54}
Название задания не изменил ещё, хотя уже договорился сам с собой, что это никакой не тест-элемент... Теперь я рассматриваю и реализую тест-ядро.
Так и не определился ещё, в каком виде будет выдавать результат тест-ядро в моей системе. Варианта два: булевое значение и сообщение об исключительной ситуации.
...

[1]

Итак, что это за объект и чего я от него хочу.
...

Состоялся митинг по автоматизации. После него ощущаю беспокойство, пока неясное. Это означает, что его результаты меня не удовлетворяют. Попробую разобраться, что именно мне не нравится.
1. Тестирование дизайна. Имеется ввиду попиксельное сравнивание изображений - полученноо во время тестирования и эталонного. Пока что мы это импользовать не будем.
2. Сообщение о баге сопровождается Selenium-тестом. Сережа предложил. Идея, конечно, интересная. Можно попробовать. Но здесь есть вопросы, в каком именно виде этот тест должен быть представлен. Разработчик должен иметь возможность легко этот тест запустить и ясно увидеть, что именно работает не так.
3. Участвовать в форумах. Опять же, Серёжа упомянул эту возможность. Если есть проблема, ею можно поделиться с сообществом. Посмотрим...
4. Документация. Пока что у нас наблюдается пренебрежительное к ней отношение. На ней смотрят, как на какую-то ненужную обузу. У меня же другой взгляд. Документ - это в первую очередь источник идей для тестов. Чтобы что-то автоматизировать, нужно знать, что именно автоматизировать. Тесты, придуманные без анализа, не могут претендовать на полноту того же покрытия функциональности. А если проводится анализ, то документы рождаются сами собой: диаграммы, схемы, спецификации, просто заметки. Почему бы всё это не сохранять и не использовать в последующем? Я уж не говорю, что всё это должно быть готово ещё перед реализацией функциональности, а не перед её тестированием. Лично я буду продолжать создавать документы.
5. Было принято решение размещать тесты в классах, соответствующих каким-либо частям функциональности. Сначала я был против, потому что в этом случае будет происходить смешение ролей пользователей, так как очень часто функциональностью это поразумевается. А потом в разговоре с Лёнькой пришли к выводу, что это требование, в принципе, не помешает моему представлению о том, какими должны быть тесты, потому что каждый отдельный тест, в принципе, есть тест какой-то функциональности, единичной функциональности, так что каждый тест и так уже соответствует этому требованию.
6. Логирование. Использовать Selenium Logging. Эту возможность я уже реализовывал на отдельном примере, но подробно не рассматривал. Её применения нельзя назвать простым, довольно капризная штука. А вот сколько от неё будет пользы... ещё вопрос. Может быть, удобнее использовать своё собственный лог. А картинки, если в них есть необходимость, Selenium умеет делать сам. В общем, тут ещё нужны исследования.
7. Андрей Круглянко подключается ко мне в смысле написания тестов для Common Agenda. Это проблема. Как мы можем писать что-то вместе, если у меня у самого ещё не сформировалась концепция того, как это должно делаться. А если и сформируется, то совсем не факт, что Андрей захочет её поддерживать. Он привык писать тесты по-старому. Мне такой подход не нравится, а новый я ему предложить пока не могу. В общем, пока он займётся восстановлением тех тестов для Common Agenda, которые висят в проекте и которые он же и спроектировал. Если они заработают, то послужат образцом старого стиля.
8. Названия методов-тестов. test_<функциональность>_<функциональность>_...(). В общем, что-то типа такого: test_Widget_CategoriesList_Visibility().
9. Нужно почитать про метод Selenium assignedID(). Это для борьбы с длинными путями XPath. Нужно выяснить, чем это лучше обычного назначения новой переменной с коротким именем.
10. Автозапуск тестов. С Женькой нужно обеспечить ночной запуск тестов по расписанию. Для этого нужно разобраться, что именно необходимо сделать мне с кодом, чтобы это всё работало.

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