Тестирование сервиса заказа самокатов. Я проверил веб-форму заказа (9 полей, валидация, кроссбраузерность) и мобильное приложение (push-уведомления, офлайн-режим).
Какие проблемы решает проект?
Часто в проектах документация по тестированию либо отсутствует, либо написана хаотично. Я создал системную тестовую документацию: чек-лист на 150+ проверок, 22 тест-кейса, 42 баг-репорта с приоритетами. Это позволяет любому тестировщику продолжить мою работу без лишних вопросов. Без чек-листа легко пропустить критическую проверку. Без структурированных баг-репортов разработчики тратят время на переписку. Мой проект показывает, что я умею организовать процесс тестирования так, чтобы он был прозрачным и эффективным.
Почему я его создавал?
Чтобы показать, что ручное тестирование — это не "тыканье кнопок", а системная работа: тест-дизайн, документация, исследовательский подход, коммуникация с командой. Я умею находить дефекты даже там, где их не ждут (исследовательское тестирование).
Стек (инструменты):
- Google Sheets (тест-дизайн, баг-трекинг)
- DevTools (поиск локаторов, проверка вёрстки)
- Android Studio (эмулятор Android 9.0 для push-уведомлений)
- Чек-лист из 150+ проверок (кроссбраузерно, 2 разрешения экрана, валидация 9 полей)
- 22 тест-кейса для мобильного приложения (push-уведомления, офлайн-режим)
- 42 баг-репорта, 15 из них — критических
- Исследовательское тестирование: найдены дефекты вне документации (кнопка «GO!», неработающий Enter, дублирование заказа при отмене)
Проект демонстрирует мои навыки в ручном тестировании, работе с тестовой документацией и исследовательском подходе. Я умею не просто находить баги, а делать это системно, чтобы команде было комфортно работать с моими артефактами.