Привет, Хабр! Меня зовут Иван, третий год в тестировании, веду тг канал QAtoDev. Сегодня поговорим о тестовом задании на позицию тестировщика в мобильное приложение. Лично я не раз проходил такие тестовые при поиске работы. На просторах интернета очень мало об этом пишут, казалось бы сравни левую картинку с правой, об этом даже говорить смешно. Вы меня извините, я нашел 17 багов из 24 и меня не пригласили на следующий этап… Почему? А все просто, нашел баги с низким приоритетом, а с высоким упустил.
Ты самостоятельно решишь тестовое задание, не забудь поделиться своим результатом в комментариях. Чтобы ничего не упустить необходимо написать чек-лист проверок, которые разобьют экран на блоки. Напишем с учетом имеющихся UI элементов на картинке выше.
Проверка логотипа «Яндекс Музыка»
1. Общий цвет лого — белый (в темной теме)
2. Шрифт текста «Яндекс» — Yandex Sans Music
3. Отображение иконки «Импульс» (расположена между «Яндекс» и «Музыка»)
4. Шрифт текста «Музыка» — Yandex Sans Music
Проверка иконки «Плюс»
5. Иконка «Плюс» — цветной вариант (не адаптируется под тему системы)
Проверка кнопки «Поиск»
6. Кнопка «Поиск» — белый цвет (в темной теме)
Проверка Анимации «Моя волна»
7. Движения анимации при паузе — спокойное, равномерное
8. Движения анимации при проигрывании — активное, адаптируется под бит трека
9. Набор цветов в анимации не меняются в момент проигры вания трека (меняется зона заполнения, размер цвета)
10. Цвета меняются при смене трека (или остаются прежними т.к. тема трека схожа)
11. Активное движение анимации только при проигрывании трека из «Моей волны»
12. Активное движение анимации недоступно для треков из поиска и в избранных
13. Проверка лонг‑тапа в область анимации — скрытие всех элементов на экране (кроме анимации, логотипа ЯМ и плеера)
14. Проверка тапа на экран при скрытии всех элементов — пауза трека
15. Проверка нажатия и свайпа — белый акцент на анимации (адаптируется под свайп)
Проверка элементов «Моя волна»
16. Цвет кнопки — белый (в темной теме)
17. Кнопка Пауза/Играть — по тапу меняет иконку (проверка синхронности в плеере)
18. По тапу ставит трек на паузу/продолжает воспроизведение
19. Цвет текста «Моя волна» — белый (в темное теме)
20. Шрифт текста «Моя волна» — Yandex Sans Music
Проверка плашки «Настроить»
21. Цвет иконки — белый (в темной теме)
22. Шрифт текста «Настроить» — Yandex Sans Text
23. Цвет плашки — прозрачный с размытием (блюр)
Проверка плашки «Для вас»
24. Цвет текста «Для вас» — белый (в темной теме)
25. Шрифт текста «Для вас» — Yandex Sans Music
26. Цвет плашки — прозрачный с размытием (блюр)
27. Расположение обложки исполнителей (первый автор трека расположен слева)
28. Расположение обложки исполнителей (второй автор трека расположен справа)
29. Цвет текста наименования исполнителей — серый (не адаптируется под тему)
30. Шрифт текста наименования исполнителей — Yandex Sans Text
Проверка плашки «Тренды»
31. Цвет текста «Тренды» — белый (в темной теме)
32. Шрифт текста «Тренды» — Yandex Sans Music
33. Цвет плашки — прозрачный с размытием, но не акцентный в сравнении с «Для Вас»
34. Расположение обложки исполнителей (первый автор трека расположен слева)
35. Расположение обложки исполнителей (второй автор трека расположен справа)
36. Цвет текста наименования исполнителей — серый (не адаптируется под тему системы)
37. Шрифт текста наименования исполнителей — Yandex Sans Text
Проверка карточки «Мне нравится»
38. Цвет текста «Мне нравится» — белый (в темной теме)
39. Шрифт текста «Мне нравится» — Yandex Sans Text
40. Проверка наложения двух обложек треков
Проверка карточки «История»
41. Цвет текста «История» — белый (в темной теме)
42. Шрифт текста «История» — Yandex Sans Text
43. Проверка наложения двух обложек треков
Проверка плеера (свернутый вид)
44. Цвет индикатора прогресса — желтый (deadline)
45. Цвет прогресс‑бара — серый (линия всего трека)
46. Отображение обложки трека
47. Цвет текста наименования песни — белый (в темной теме)
48. Шрифт текста наименования песни — Yandex Sans Text
49. Цвет текста исполнителей — серый
50. Шрифт текста исполнителей — Yandex Sans Text
51. Проверка неполного отображения имени, если более 28 символов
52. Отображение кнопки «Нравится» — цвет белый
53. Трек добавлен в избранное — красный цвет (светлая тема)
54. Трек добавлен в избранное — желтый цвет (темная тема)
55. Отображение кнопки Пауза/Играть — цвет белый
56. Кнопка Пауза/Играть — по тапу меняет иконку (проверка синхронности в «Моя волна»)
57. По тапу ставит трек на паузу/продолжает воспроизведение
58. По свайпу плашки следующий/предыдущий трек
Проверка «НавБара»
59. Отображение иконки «Главная экран»
60. Отображение иконки «Подкасты»
61. Отображение иконки «Избранное»
62. Акцентный цвет иконки — белый (в темной теме)
63. По умолчанию цвет иконки — серый
В данном чек-листе я многое пропустил, например размер шрифта, закругление элементов, процент прозрачности и т.д. Все потому, что в мобильном приложении достаточно сложно проверить данные параметры, без использования сторонних инструментов. Проще наложить скрин макета на скрин экрана и выставить прозрачность для проверки размера, формы и расположения элементов.
Благодаря такому чек-листу мы многое найдем, но также есть не мало багов, которые мы упустим без наложения и сравнения. В проверках также содержится функциональное тестирование, ведь без действий не проверить переходы элементов. Если углубиться в полное сравнение, то на выходе у нас должно получится от 14 до 19 различий (смотря как объедините).
Жду самых внимательных в комментариях!
Как вы считаете, написание данных проверок исчерпывающе или в этом есть смысл, с учетом дефицита времени у QA инженеров?
Ответ на вопрос заключается в следующем: на этапе проектирования задачи баг поправить можно, но уже после внесения всех правок с высоким приоритетом никто вам исправлять процент прозрачности на плашке не будет. Все ваши находки упадут в бэклог и останутся там навсегда. Поэтому все UI капризы нужно отлавливать на первом этапе заведения баг-репортов. Если у разработки нет времени т.к. чинят что-то блокирующее, то увы придется пожертвовать низким приоритетом.
И что же делать? Можно как вариант объединить баги шрифтов, размеров и прозрачности с одного экрана в одну задачу на исправление, и тогда приоритет у правки возрастет. Дополнительно хочу подсветить, что мы можем столкнуться с изменением одного экрана, который влияет на связанный функционал в остальных частях МП (если это старый UI баг).
ссылка на оригинал статьи https://habr.com/ru/articles/862232/
Добавить комментарий