Тестування збережених пошуків
Збережені пошуки - зручний інструмент, за допомогою якого можна зберегти необхідний запит і знати про нові надходження. Це зручно, оскільки:
не потрібно щоразу виставляти параметри та фільтри пошуку заново, ви відразу переходите до потрібних результатів;
ви отримуєте повідомлення про нові оголошення відразу після їх публікації.
Збереження пошукового запиту неавторизованим та авторизованим користувачами
Зрозуміло є два види користувачів: авторизований та неавторизований. Якщо ми зберігаємо пошуковий запит, будучи неавторизованим користувачем, у такому разі перевіряємо, що здійснюється перехід на екран авторизації та після авторизації або реєстрації користувача, пошуковий запит додається до розділу "вибране". Кейси, на які варто звернути увагу, якщо користувач новий, йому повинні відобразитися всі необхідні поп-апи, тул-тіпи, онбординги. Є велика ймовірність, що про них могли забути.** **При збереженні пошукового запиту авторизованим користувачем все набагато простіше - пошук зберігається, а збережений пошук може виявити на екрані зі збереженими пошуками (про нього ми поговоримо трохи пізніше).
Текстовий пошук
Не завжди користувач хоче задавати фільтри для пошукового запиту, а бажає обмежитися, наприклад, тільки одним текстовим пошуком. При збереженні текстового пошуку необхідно перевірити, що бек з клієнта йде коректний запит, у якому передається параметр з пошуковим запитом. Також варто врахувати кейси, коли значення параметра, що містить пошуковий запит, виявилося порожнім, а також кейси, коли в параметрі міститься емодзі.
Пошук із вибраними фільтрами
Найпоширеніший кейс, коли користувач задає специфічний пошуковий запит і хоче зберегти його. Наприклад, користувач шукає автомобіль з безліччю фільтрів.
У цьому кейсі необхідно перевірити збереження при різних комбінаціях фільтрів, а також, що всі фільтри коректно передаються з клієнта на бек. Надалі, зрозуміло, при відкритті збереженого запиту з безліччю комбінацій фільтрів, варто перевірити, що всі фільтри, що прийшли з бека, коректно відображаються у користувача пошукова видача відповідає запиту.
Налаштування частоти сповіщень при збереженні
Користувач може налаштувати частоту повідомлень про нові надходження. Ми вибираємо певний параметр, який у разі передається на бэк. А вже надалі, відповідно до заданих параметрів, надходитиме push-повідомлення клієнту. Як і в попередніх кейсах, варто перевірити, чи передається коректне значення параметра частоти повідомлень, а також це обране значення відображається на клієнті.
Відображення збереженого пошукового запиту
Користувач зберіг пошуковий запит. А тепер розглянемо кейси, які варто врахувати під час тестування екрану, де відображаються усі збережені пошукові запити.
Текстовий пошуковий запит (довгий текст)
Варто врахувати, що користувач може зберегти пошуковий запит з абсолютною різною кількістю символів, тому звертаємо увагу на перевірки, коли символи, що залишилися, повинні ховатися під трьома крапками (...).
Збережений пошук із вибраними фільтрами
Як ми вже говорили вище, коли шукаємо той чи інший товар, ми задаємо певні фільтри. Це може бути певна вартість, наявність доставки, віддаленість від нас, наявність знижки та багато іншого. Фільтрів може бути багато, тому не завжди вони можуть поміститися в осередку. В даному випадку, фільтри, які не помістилися, повинні ховатися також під крапку.
Пошуковий запит з emoji
Користувач може висловити свої емоції та додати до пошукового запиту, наприклад емодзі. Варто перевірити як коректне збереження пошукового запиту, так і відображення товарів за цим пошуком.
Карусель товарів у збереженому пошуку
За певним запитом може бути багато товарів. Згруповані товари за категорією розташовуються в каруселі. Природно не всі товари розміщуватимуться, тому користувач повинен мати можливість переглянути стрічку з усіма товарами з каруселі. Для початку, варто перевірити відображення різної кількості товарів (мінімальне та максимальне значення). Слід перевірити скролл товарів у каруселі. Також перевіряємо переходи з каруселі на стрічку із товарами. Для цього може бути реалізована кнопка в кінці каруселі, наприклад "Переглянути всі оголошення", або активна назва каруселі, наприклад, при тапі на заголовок "телефони", у нас відкриється стрічка з товарами, вибраними відповідно до заданих фільтрів.
Збережений пошук без відповідних товарів
Припустимо, користувач запитав такий пошуковий запит, за яким у видачі на даний момент немає відповідних товарів? У такому разі він може зберегти такий запит, а на екрані збережених пошуків каруселі з товарами вже не буде. Коли товари, відповідні запиту з'являться на сервісі, вони відобразяться користувачеві в каруселі товарів.
Необхідно врахувати, що може бути як один товар, так і n-кількість товарів, відповідно скролл товарів у каруселі повинен працювати коректно, а також усі атрибути прев'ю картки товару (вартість, назва, "серце" обраного) відображаються на картці.
Налаштування частоти повідомлень про нові надходження
Пошук може бути цікавий нам по-різному. Наприклад, ми дуже хочемо не пропустити появу нового товару, в такому випадку виберемо "Сповіщення одразу", або не хочемо отримувати повідомлення часто і віддамо перевагу "Сповістки раз на день". У будь-якому обраному нами випадку, ми повинні отримувати сповіщення рівно стільки разів, скільки ми вибрали в налаштуванні.
Налаштування частоти сповіщень, якщо повідомлення вимкнено
А якщо користувач відключить у налаштуваннях сповіщення? У такому разі підписатися на пошук і налаштувати повідомлення не вдасться. Однак можна перейти в налаштування та увімкнути сповіщення. Тут важливо перевірити перехід між програмою та екраном налаштувань сповіщень.
Видалення пошуку
Користувачеві може бути не цікавий пошуковий запит і захоче його видалити. В даному випадку, видалити пошук можна з боттомшиту "Підписка до пошуку". Після видалення перевіряємо те, щоб пошук зникав з екрана "Пошуки", а також верстку стрічки зі збереженими пошуками. Вона не має ламатися. Також варто врахувати кейси з відключеним з'єднанням з Інтернетом.
Каунтери пошуків
Каунтери - лічильники, які служать для інтерактивного відображення якоїсь кількості: нові товари, повідомлення, обране та багато іншого. Зрозуміло, з появою нового товару у збереженому пошуку, інформація про цей товар прийде до нас з бека. Каунтери приходять також із бека. Основні кейси при тестуванні лічильників будуть пов'язані з видаленням товарів та перевірки, що значення каунтера змінилося у менший бік, а також, що при надходженні нового товару каунтер змінюється у більшу сторону. Але це не все. Варто перевірити максимальне значення (в гуртку) для каунтера, наприклад, якщо товарів буде більше 100. У такому випадку реалізація може бути різною, наприклад відображатися значення 99+. Також може повністю відображатися значення лічильника, наприклад 115,
Повідомлення про нові товари у збереженому пошуку
При тестуванні push-повідомлень щодо нових товарів варто виконувати перевірки, характерні для тестування пушкою. У цій статті не будемо зачіпати всі кейси при тестуванні push-повідомлень, оскільки вони описані в одній статті.
Додаткові перевірки
Залежно від реалізації можуть бути додані тултіпи, попапи, тоасти - це, зрозуміло, вимагає додаткових перевірок. Також не варто забувати і про базові кейси під час тестування.
Джерела:
Last updated