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

Аудит и оптимизация QA-процессов
онлайн, начало 29 января
Тестирование безопасности
онлайн, начало 27 января
Школа Тест-Аналитика
онлайн, начало 27 января
Тестирование мобильных приложений
онлайн, начало 27 января
Фотография

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

#junor #test#

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 6

#1 Popowka2

Popowka2

    Новый участник

  • Members
  • Pip
  • 6 сообщений
  • ФИО:Страхов Павел Александрович


Отправлено 28 апреля 2017 - 07:45

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

 

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


  • 0

#2 Molechka

Molechka

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 216 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 28 апреля 2017 - 08:50

А какой у вас стаж в тестировании и что вы понимаете под исследовательским?


  • 0
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/

#3 Popowka2

Popowka2

    Новый участник

  • Members
  • Pip
  • 6 сообщений
  • ФИО:Страхов Павел Александрович


Отправлено 28 апреля 2017 - 12:04

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


  • 0

#4 Molechka

Molechka

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 216 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 28 апреля 2017 - 13:21

Исследовательское тестирование — это не просто "хаос без требований", рекомендую статью про ошибки и заблуждения в этом тестировании.

А чего от вас хотят как от тестировщика? Может, всех все устраивает, кроме вас? Тогда вам не получится выделить время на улучшение.

 

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


  • 0
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/

#5 Popowka2

Popowka2

    Новый участник

  • Members
  • Pip
  • 6 сообщений
  • ФИО:Страхов Павел Александрович


Отправлено 28 апреля 2017 - 13:44

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


  • 0

#6 fraylina

fraylina

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Тестировщик серебра и золота
  • Город:Екб


Отправлено 01 мая 2017 - 14:20

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

 

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

 

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

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

 

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

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

 

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

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

 

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

две недели

 

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

 

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


  • 0
последняя инстанция :beach:

#7 Popowka2

Popowka2

    Новый участник

  • Members
  • Pip
  • 6 сообщений
  • ФИО:Страхов Павел Александрович


Отправлено 02 мая 2017 - 06:01

 

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

 

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

 

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

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

 

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

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

 

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

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

 

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

две недели

 

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

 

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

 

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


  • 0


Практикум по тест-дизайну 2.0
онлайн
Школа для начинающих тестировщиков
онлайн
Школа тест-аналитика
онлайн
Техники локализации плавающих дефектов
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале