Как проверить сортировку списка сотрудников?
Что проверяют
Умеете ли вы подобрать тестовые данные так, чтобы неправильная сортировка сломалась у вас на глазах. Проверка «список выглядит упорядоченным» на пяти разных фамилиях ничего не доказывает. Следом обычно спрашивают, как автоматизировать проверку и откуда взять эталонный порядок.
Как отвечать
Сначала уточните требования: по каким полям сортировка, какое направление по умолчанию, куда попадают пустые значения, сортирует ли фронтенд текущую страницу или сервер весь набор.
Затем данные, на которых ломается большинство реализаций:
- регистр и алфавиты: «иванов» и «Иванов», кириллица вперемешку с латиницей, «Ё» и «Е». Порядок должен соответствовать русской локали, а не кодам символов;
- числа в строках: табельные номера 2, 10, 100. При строковом сравнении 10 окажется раньше 2;
- даты: если дата хранится строкой
дд.мм.гггг, строковая сортировка ставит 01.12.2024 раньше 02.01.2023; - дубли: два Иванова. Порядок между ними задаёт вторичный ключ, иначе он прыгает от запроса к запросу;
- пустые значения: сотрудник без отдела или без даты увольнения окажется там, где сказано в требованиях;
- пагинация: сортируется весь список, а не только текущая страница. Сравните последний элемент первой страницы и первый элемент второй.
Плюс поведение: переключение направления, сохранение сортировки после фильтра, обновления страницы и возврата назад.
В автотесте берёте значения колонки из UI и сравниваете с копией, отсортированной по тем же правилам, например через Intl.Collator("ru") в JavaScript. Ещё надёжнее сверять с ответом API или запросом к базе с явным ORDER BY.
Где спотыкаются
Сортируют эталон в тесте стандартным sorted() или .sort() без учёта локали. Тест тогда либо падает на правильной выдаче, либо подтверждает неверную.
Проверяют на данных без повторов и пустых значений, и самые частые баги остаются незамеченными.
Смотрят только первую страницу. Сортировка на клиенте внутри страницы выглядит правильно, пока не перелистнёшь дальше.