Ранее я спрашивал о том как начать тестировать тут
Работаю тестировщиком в контакт-центре. Тестирую десктопное приложение для сдачи отчетности в электронном виде. Как правило все ошибки регистрируются второй линией тех-поддержки. Затем я перевожу эти ошибки как репорты разработчику
У нас намечается переход на новый интерфейс и требуется составить план перехода. В связи с отсутствием опыта в планировании подобных вещей, обращаюсь к вам за помощью. Мой руководитель пока предложил такую структуру :
План должен учитывать:
1. Нужно прикинуть какие главные шаги нужно пройти
2. Обсудить и решить, как будет выбираться тестовая группа клиентов
3. Учесть вероятность того, что клиенты будут не готовы к новому интерфейсу (не поймут, не захотят, не разберутся):
Обсудить с разработчиком возможность перехода на новый интерфейс по желанию и предложить варианты реализации этой возможности
Обсудить с разработчиком возможности отката к старому виду и предложить варианты реализации этой возможности
4. Учесть возможность информирования клиентов об особенностях работы в новом интерфейсе:
Гайд при первом запуске.
Изменение инструкции
5. Возможно придумать какую-либо форму обратной связи на период перехода, чтобы учесть мнения клиентов
Описать порядок работы с такими возражениями клиентов
6. Определить ключевые показатели успешности перевода базы на новый ИПК
Может кто что-нибудь подскажет или подкинет полезные ссылки или какую-либо другую информацию. Буду благодарен за любую помощь.
Все ли вы знаете о техниках поиска багов? Как найти то, что мелькнуло лишь раз? Как воспроизвести проблему по невнятному описанию пользователя «У меня все сломалось»? Какие предположения строить? Что уточнять?
В рамках курса мы создали специальный «бажный» сайт для тестирования. Внедрили туда 20 разных по типу ошибок. Чтобы их найти, придется применять разные техники и инструменты:
— Собрать логи.
— Проверить консоль JS.
— Найти граничные значения.
— Пройтись по туру, отмененному из-за дождя.
— Проверить разные браузеры.
— Убрать ограничение, установленное на клиенте.
— …
Сервер поднят на linux-е, куда у студентов есть доступ на чтение логов. Это позволяет применить полезные в будущем инструменты:
Putty — снять статистику, последить за логом
WinSCP — забрать лог с сервера
Grep — найти нужный стек в логе (linux)
Cygwin — найти нужный стек в логе (windows)
Еще на курсе будут использоваться:
Postman — послать POST-запрос на сервер
Perlclip — сгенерить большую строку текста
Курс запускался в два этапа — год назад вышла первая версия на 4 занятия. Мы рассказывали только то, что не зависит от “веб — не веб, линукс — не линукс” итд. Как искать, локализовывать и оформлять задачи. Материала было много! По отзывам студентов:
Ого, сколько материалов и заданий! Скучать не придется. А текст задания: "Меня обманули и обесчестили, я разворачиваюсь и ухожу." развеселил))
Но курс должен не только веселить, но и учить. Общаясь с ребятами, мы поняли просто “найти и локализовать” неинтересно. Это ведь все умеют, мы занимаемся этим каждый день.
Интересно другое:
— Как понять, кто именно сломался, если системы интегрированы?
— Как доказать подрядчику, что проблема именно на его стороне?
— Что делать, если ошибку уже пропустил?
Или технические штуки, которые пригодятся в дальнейшем:
— Залезть на сервер linux, найти нужный лог, изучить стек-трейс.
— Перехватить сообщение в консоли разработчика.
— Прочитать ответ, пришедший с сервера.
— Найти баг кеширования на сервере.
Все это теперь есть! Мы расширили курс, теперь там девять уроков вместо четырех. И 27 домашних задания — чтобы как следует закрепить материал. Приходите к нам, если хотите взглянуть на “обычный” процесс поиска и локализации багов по новому.