Тестирование поискового движка можно разделить на 2 части:
Первичное создание индекса. Полное построение индекса нужно осуществлять в двух случаях. Во-первых, если Вы подключили поисковый движок к вашему проекту не с самого начала его существования и в базе уже есть данные. Во-вторых, Вы изменили структуру данных, и поэтому данные в индексе не соответствуют действительности. Тестировщик обязан знать, как запустить процесс полного построения индекса. Обычно в рамках проекта пишется скрипт, который делает это автоматически.
После построения индекса проверьте, как работает поиск по терму. Также проверьте, действительно ли используются данные из индекса, а не из базы. Делайте это по аналогии с тестированием кэширования данных в выпадающих списках – измените данные в базе вручную и проверьте, что данные в результатах поиска не изменились. Обычно индекс не обновляется при ручном изменении данных в базе, поэтому наше тестирование будет валидным. Если же на Вашем проекте индекс обновляется даже при ручном изменении данных, то временно отключите обновление индекса. По завершении тестирования не забудьте построить индекс заново, чтобы убрать все несоответствия и включить обновление индекса, если Вы его отключали.
Обновление индекса. После каждого изменения данных в базе нужно обновлять индекс. Проанализируйте, какие есть в вашем проекте способы изменения данных. Ниже приведен список наиболее распространённых из них:
Создание
Проверьте, что новые сущности ищутся по всем индексируемым полям
Удаление
Удалённые сущности не должны находиться при поиске по терму и без терма. Такое бывает, если индекс не обновился, а удаление произошло только в базе данных.
Обновление
Сущность не ищется по старым значениям, но ищется по новым. При обновлении данных из индекса нужно удалить старые значения и добавить новые.
Копирование
Ищется не только копия, но и оригинал. На картинке снизу изображено файловое дерево. Очень часто при копировании родителя (папки) забывают проиндексировать дочерние элементы (файлы).
Клонирование (Sharing)
Клонирование – повторное использование одной и той же сущности в двух местах. Например, на вашем сайте Вы позволяете пользователям создавать документы. Вы хотите, чтобы одни и те же документы были добавлены в два места. При этом также хотите, чтобы при изменении документа он обновлялся во всех местах. Для этого делают операции клонирования. Сначала создают документ в одном месте, а затем добавляют его в другое через специальное меню. Для проверки обновления индекса, как и при копировании, проверьте, что клон и оригинал ищутся. Также обновите документ в одном месте и проверьте, что индекс обновляется для него и для клона
Дополнительные кнопки
Кроме [Submit] на форме могут быть и другие кнопки (например, кнопка выбора файла). Файл загружается на сервер автоматически после его выбора. По окончанию загрузки данные в базе будут обновлены. Не забудьте проверить, что индекс также обновляется;
Перестановка (Drag and Drop)
Перетаскивание и перестановка элементов в дереве (drag&drop and reorder in tree) – этот кейс актуален, если Вы индексируете данные, которые хранятся в дереве. Проверьте, что при изменении порядка и взаимного расположения элементов в дереве они не выпадают из индекса.
Версионирование (Versioning)
Предположим, что сущности на вашем сайте могут иметь несколько версий. Поиск осуществляется только среди активных версий. Проверьте, что индекс обновляется при добавлении новой версии и установке ее как основной (той, по которой идет поиск).
Пример дерева:
Баг-Репорт
Баг-репорт – это текстовое описание ошибки и главный результат труда тестировщика. О качестве работы тестировщика судят по качеству его баг-репортов и по количеству пропущенных багов.
Вы нашли баг и хотите сообщить о нем программисту. Прежде всего, Вам нужно найти все кейсы, в которых он воспроизводится. Например, мы тестируем программу для создания и управления тест-планами. Тест-план может содержать тестовые наборы (Test Suite), а те в свою очередь содержат тестовые случаи (тест-кейс, Test Case).
Допустим, Вы видите проблему с обновлением тестового случая. Вы конечно можете завести баг типа "откройте тест-кейс номер 123 и попытайтесь обновить его описание". В этом случае программист может всего лишь исправить данные в базе, которые не позволяют выполнить обновление. Он исправит некорректные данные, но не код. Ошибка может повториться вновь. Также программист может попытаться найти источник проблемы сам, но тогда Вы отнимете его время и не заслужите должного авторитета. Поэтому постарайтесь самостоятельно выяснить шаги, которые ломают тестовый случай. Это может быть, к примеру, копирование тестового случая или ввод специфичных данных в его поля и т.д.
Найдя точные шаги для воспроизведения бага, нужно перейти к уточнению, в какой среде воспроизводится этот баг. Под средой подразумевается браузер пользователя, устройство (мобильный телефон, планшет и т.д.), операционная система и т.д. Нередко попадаются баги, которые видны только в специфичных условиях, поэтому не забывайте пробовать воспроизвести их в другой среде. Если он воспроизводится, например, не во всех браузерах, то обязательно об этом сообщите. По иронии судьбы программист будет пытаться воспроизводить его не в том браузере, в котором Вы его нашли. Обычно баг-трекеры имеют отдельное поле в описании бага для среды. Как показывает практика, если баг браузеро-зависимый, то лучше еще и в описании бага сделать на это акцент.
И так, Вы убедились, что нашли стабильные шаги для воспроизведения, и знаете, в каких условиях воспроизводится баг. Теперь можно переходить к его описанию. Для этого Вы должны придумать название, дать шаги для воспроизведения проблемы, описать текущее поведение программы и ожидаемое.
Заголовок
Заголовок должен кратко отражать суть проблемы. По хорошему заголовку можно понять, как воспроизвести баг и что должно быть в итоге. Но прежде всего заголовок должен облегчать поиск бага. Баги приходится искать очень часто, например, при заведении нового бага, Вы должны убедиться, ни завел ли уже его кто-то из ваших коллег. Например, Вы видите такую проблему: Модератор может закрывать темы на форуме даже в тех разделах, которые ему не назначены. Все потому что ему показана кнопка [Закрыть тему]. Наверняка Вы будете пытаться найти этот баг по слову модератор или по названию кнопки, поэтому эти слова обязательно должны быть включены в заголовок.
Хороший пример:
Кнопка [Закрыть тему] должна быть доступна модератору только в темах его раздела
Плохие примеры:
Модератор может закрыть любую тему
Кнопка [Закрыть тему] должна быть скрыта
Лишние кнопки доступны модератору
Существует хорошая практика добавлять в заголовок бага название той области, где он был найден. Это также облегчает поиск и позволяет программистам скорее распределять баги между собой. Например:
Права пользователей: Закрытие темы -Кнопка [Закрыть тему] должна быть доступна модератору только в темах его раздела
После того, как фича будет отдана на тестирование клиенту, в ней делают небольшие изменения/улучшения. Иногда информацию об этих изменениях забывают внести в документацию. Допустим, спустя некоторое время Вам потребуется тестировать эту фичу вновь. Вы откроете документ и обнаружите, что он отличается от того, что Вы видите на деле. Единственным источником актуальной информации для Вас будет баг-трекер. Просмотрев заголовки багов, Вы сможете понять, что было сделано. В этом случае Вам будет удобнее, если заголовки будут написаны в повелительном наклонении, то есть в них будет описание того, что должно быть, а не то, что видит тестировщик. Такой подход также облегчает программисту жизнь – он точно знает, чего от него хотят.
Хорошие примеры:
Ширина кнопки [Like] должна быть 50 px
Фон домашней страницы должен быть синим
Диалог "Создание нового пользователя" должен быть показан при нажатии на кнопку [Регистрация]
Плохие примеры:
Кнопка [Like] слишком узкая
Фон домашней страницы не должен быть красным
Кнопка [Регистрация] не работает
Программисты одобряют такой подход. Им становится легче понять то, чего от них хотят.
Предусловия
Иногда при заведении бага Вы можете обнаружить, что описание включает очень большое количество шагов (больше 5). Это делает баг трудным для понимания и воспроизведения. Очень часто это случается, если тестировщик пытается описать то, как он создавал какие то данные, необходимые для воспроизведения бага.