Краткий ответ

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

Исторический контекст

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

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

Постановка проблемы

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

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

Подробное решение

Подготовьте минимум три элемента с одинаковым именем и уникальными идентификаторами, например А, Б и В.
Разместите их в заведомо заметном порядке: В, А, Б.
Добавьте элементы с другими именами, чтобы проверить саму сортировку по имени.
Зафиксируйте исходный порядок равных элементов.
Выполните сортировку по имени.
Проверьте две вещи: разные имена расположены в требуемом порядке, а элементы с одинаковым именем сохранили взаимный порядок В, А, Б.

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

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

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

Ситуация из практики

В каталоге товары сортировались по названию. Тестировщик создал три товара с одинаковым названием, различающиеся артикулом, затем отсортировал каталог. Названия располагались правильно, но товары с одинаковым названием меняли порядок после каждого обновления страницы.

Рассматривались два варианта. Можно было проверять только общую последовательность названий: это быстро, но не выявляет нестабильность. Можно было добавить уникальные артикулы, фиксировать исходный порядок и проверять его после сортировки: подготовка сложнее, зато результат объективен и воспроизводим.

Выбран второй вариант. Анализ требований показал, что каталог должен сохранять порядок добавления товаров при равных названиях. Дефект был подтверждён, а после исправления повторная проверка показала сохранение порядка при сортировке и обновлении списка.

Что кандидаты часто упускают

Всегда ли изменение порядка элементов с одинаковым ключом является дефектом?

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

Тестировщик не должен подменять отсутствующее правило личным ожиданием. Нужно уточнить спецификацию либо зафиксировать неопределённость как вопрос к ответственному за продукт.

Зачем нужны уникальные идентификаторы, если имена элементов одинаковы?

Без идентификаторов невозможно надёжно определить, какой именно элемент переместился. Видимый список может выглядеть неизменным, хотя записи внутри него переставились.

Артикул, номер, цветовая метка или другой уникальный признак превращает визуальное наблюдение в проверяемое утверждение: относительный порядок конкретных элементов до сортировки должен совпасть с порядком после неё.

Почему стабильность особенно важна при сортировке по страницам?

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

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