Online QADay 2024 #1 НАТАЛІЯ ТРОЙНІЧ «Редизайн всього продукту, коли на проекті залишилось два мануальних тестувальника» https://linktr.ee/qadayua

1. “Редизайн всього продукту, коли на проекті залишилось всього
два мануальних тестувальники”
- Досвід роботи тестувальником більше 4-х років
- Працюю QA Engineer у мюнхенській EdTech компанії
- Тестую веб/мобайл додатки та вебсайт “StudySmarter”
- У вільний час люблю гуляти містом, плавати та читати

2. StudySmarter - інтелектуальна навчальна платформа для учнів та
студентів

3. - Стартап заснований 6 років тому у Мюнхені
- №1 навчальна платформа
- 22+ мільйона користувачів
- локазілована для 5-ох мов

4. Зробили повну реструктуризацію компанії із суттєвим
зменшенням штату, а тепер почнемо редизайн всього продукту

5. Чому Редизайн зараз?
- залучення нових користувачів
- збільшення доходу
- виправити
- технічний+дизайнерський борг
- змінити UX підхід для певного
функціоналу
- досягти більш стабільного продукту

6. - не було прототипу редизайну
- інтерв’ю проводилися для врахування нових
трендів, потреб користувача та виявлення
недоліків в існуючому функціоналі
- питайте користувача про проблему,
а не її рішення
Підготовчі роботи та інтерв’ю з користувачами

7. Початок та розробка UI/UX частини
- створення скелету дизайну
- продумування нового юзер флоу
- обговорення менеджментом створення додаткових фіч
- на цьому етапі
QA ще активно
не залучені, але
вже відвідують
зустрічі щодо
всього концепту

8. Бекенд та Фронтенд розробка
- робота по Канбану
- розробка розділена за функціональністю
- усі зміни одразу зливаються у головну гілку
- на цьому етапі QA вже можуть поступово долучатися

9. Redesign Progress Traffic Lights Check
- червоний, якщо не встигаєш по таймлайну
- жовтий при невеликій затримці
- зелений колір, коли все йде за планом

13. Основна функціональність продукту

14. Принцип “Ділити кита на частини”
- задачі в JIRA були розділені за
функціональністю продукту
- кожен баг заводився як підзадача до
конкретної задачі
- той самий принцип можна застосувати для
тестової документації

15. Редизайн - це командна робота
- до тестингу були залучені продуктовий та інженерний відділи
- усі “майбутні фічі” репортились в редизайн Slack канал
- якийсь фікси робились одразу і позначались готовими у треді
- всі інші баги заносились у JIRA

16. Оновлення механізму сповіщень
- залучити користувача проводити більше часу у
додатку
- адаптувати сповіщення під нову
функціональність (Task List)
- спростити та оптимізувати логіку існуючих
сповіщень
- нагадувати про майбутні іспити та підготовку до
них

17. Відкрита комунікація з існуючими користувачами щодо змін у
продукті

18. Основні виклики та труднощі для QA команди
- відсутність покриття автотестами
- забагованність рекламного функціоналу
- тестування tracking events

19. Графік релізів
Повний rollout був запланований до Різдва

21. Моніторинг та виправлення критичних багів після повного
роллауту
- після релізу одразу проводилося опитування у додатку
- скарги, побажання приходили у спеціально створений канал
- QA плідно працювали із командною підтримки та перевіряли баги, які
репортилися користувачами
Критична проблема після повного роллауту:
Перфоманс-проблеми на веб-сайті

22. Підсумки редизайну
- це був виклик для всієї компанії
- редизайн завжди ризиковане бізнес-рішення
- отримали позитивні відгуки від багатьох користувачів
- вважаємо успішною зміною у продукті
- не жалкуємо про рішення робити та зробили б це знову
- код рефакторинг чи редизайн неминучі у певний момент

23. Q&A > QA

24. Дякую за увагу!
QR-CODE на мій профіль у LinkedIn