Перейти к содержимому

Popowka2

Регистрация: 18 ноя 2016
Offline Активность: 05 сен 2017 13:21
-----

Мои сообщения

В теме: С чего начать тестировать?

02 мая 2017 - 06:01

 

Здравствуйте.

 

Работаю тестировщиком в контакт-центре и тестирую десктопное приложение для сдачи отчетности в электронном виде. Из тестировщиков на этом проекте я всего один. Тестирование полностью исследовательское и даже на него времени почти нет. Вся работа сводится к тому, что я не тестирую и нахожу баги, а клиенты обращаются через тех сапорт с найденными багами и уже потом я отдаю их разрабам. Хотелось бы выстроить процесс тестирования и начать делать все как нужно. Хотелось бы узнать с чего начать? Может кто поделится опытом или кинет пару полезных ссылок.

 

Тебе нужно организовать свою работу, сделать ее удобной, воспользоваться нужными инструментами.

Из того, что ты написал, я поняла, что тебе не очень сам процесс тестирования, т.к. ты не тестируешь, а регистрируешь только обращения.

 

Сравню твой процесс работы в контакт-центре, со своей работой, в отделе качества крупной компании.

У нас есть третья линия, по простому, это люди, которые принимают звонки от клиентов и оформляют по их просьбам "дефекты". Дефекты это или нет, они обычно не выясняют, а просто регистрируют обращение, далее оно попадает сразу к разработке и так же их может промониторить тестировщик, т.е. я. По сути, эти обращения для нас являются "дефектами пром эксплуатации", что для нас очень плохо, т.к. наша задача выявить дефект раньше, чем клиенты в проме. Но данные обращения не всегда могут быть ошибкой или дефектом, поэтому мы их воспроизводим на наших стендах, далее либо подтверждаем и берем в исправление, либо отклоняем и даем ответ.

 

Поэтому, тебе нужно иметь тестовую модель, регресс, по простому, это чек лист операций, который ты должен осознанно проверять, а не проводить обычное исследовательское тестирование. Ты должен понимать, в каких местах твоего функционала есть проблемы, в каких нет, что критично, что нет.

Так же, тебе нужно наладить связь с разработкой. Я так понимаю, после исправления дефектов, ты их проверяешь сам? Значит у вас есть какой то свой портал, где разработка чекает и фиксит исправления, а ты их потом закрываешь. Но здесь нужно понимать, что любое исправление дефекта может посеять новый дефект, любое исправление кода - вносит новый дефект. А какой? ты сможешь узнать, когда заново проведешь свой регресс по чек-листам.

 

Релиз выпускается сразу, как будут пофикшены критичные баги. Если критичных нет, то разработчик старается исправить все что накопилось за период обращений. В этом случае - раз в полторы-

две недели

 

это очень частый релиз, для примера, в нашей крупной компании, чтобы релиз вышел в пром эксплуатацию, мы три месяца его тестируем у себя на различных стендах и этапах. Бывают срочные патчи, которые выпускаются экстренно, и нужно проводить быстрый короткий регресс за неделю и бывает за пару недель, но здесь нужно понимать и принимать на себя ответственность такой быстроты. Либо брать на проверку критичный функционал и часть регресса. Либо ночевать на работе и проверять больше.

 

Вообщем и целом, тебе просто нужно организовать пространство для заведения чек-листов, это может быть внутренний портал, электронная доска, на которой ты будешь ставить себе планы по прохождению регресса, рисовать какие-то идеи кейсов на будущее, показывать их разработке, т.к. они в этом процессе очень сильно завязаны (должны быть завязаны) и должны видеть ,что проверяется, что нет, т.к. на качество продукта тестировщик не влияет и не отвечает, за качество продукта в большей степени отвечает человек, который пишет и меняет код. Поэтому вам нужно плыть в одной лодке:) только так и не иначе.

 

Большое спасибо за ваш ответ, все действительно так, как вы описали. Попробую использовать такую тактику


В теме: С чего начать тестировать?

28 апреля 2017 - 13:44

Большая часть времени уходит на аналитику. В моем случае, аналитика это решение тех проблем, с которыми не смогла справиться тех. поддержка второй линии. То есть выясняю действительно ли это ошибки и уже потом завожу репорт. Пользователи не заводят баги, они обращаются с проблемой в тех сапорт на первую линию и потом уже эти баги попадают ко мне. Новый функционал делается редко, только в случае необходимости. Чаще всего он делается опять же по желанию пользователей или тогда, когда его невозможно избежать (Новый закон или приказ). Релиз выпускается сразу, как будут пофикшены критичные баги. Если критичных нет, то разработчик старается исправить все что накопилось за период обращений. В этом случае - раз в полторы-две недели


В теме: С чего начать тестировать?

28 апреля 2017 - 12:04

Стаж полгода. В данном случае тестирование без требований