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

Техники локализации плавающих дефектов
онлайн, начало 19 апреля
Тестирование безопасности
онлайн, начало 21 апреля
Тестирование мобильных приложений
онлайн, начало 21 апреля
Автоматизатор мобильных приложений
онлайн, начало 21 апреля
Фотография

Идеальная работа отдела тестирования


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

#1 kukolev

kukolev

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

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Александр Куколев

Отправлено 02 декабря 2013 - 16:19

Коллеги, нужен ваш совет!

Есть острое желание организовать процесс тестирования примерно следующим образом:

1. Программист отдает задачу на тест
2. Тестировщик тестирует
3. Программист правит баги, снова отдает задачу
4. Тестировщик тестирует
... повторяются шаги 3-4
N. Тестировщик убедившись, что все баги исправлены и новые не выявлены закрывает задачу

Собственно вопросы - возможно ли добиться такой четкости с предсказуемым временем всего процесса?

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

Как изжить такую ситуацию?
  • 0

#2 Petrov.Sergey

Petrov.Sergey

    Опытный участник

  • Members
  • PipPipPipPip
  • 446 сообщений
  • ФИО:Petrov Sergey
  • Город:МО, Лобня


Отправлено 02 декабря 2013 - 16:40

Коллеги, нужен ваш совет!

Есть острое желание организовать процесс тестирования примерно следующим образом:

1. Программист отдает задачу на тест
2. Тестировщик тестирует
3. Программист правит баги, снова отдает задачу
4. Тестировщик тестирует
... повторяются шаги 3-4
N. Тестировщик убедившись, что все баги исправлены и новые не выявлены закрывает задачу

Собственно вопросы - возможно ли добиться такой четкости с предсказуемым временем всего процесса?

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

Как изжить такую ситуацию?

1) Достичь описанного процесса можно и нужно.
Предсказуемости времени, имхо, можно достичь только при соответствующей квалификации каждого участника описанного цикла.
Ну, по крайней мере, существуют программисты, которые правят одно и ломают другое. Или вместо исправления N багов по одному тесту правят K (< N) и добавляют L багов.
Впрочем, существуют тестеры, которые, не проверив со всех сторон, считают задачу выполненной. То есть описанный цикл по конкретной задаче приходит к завершению. Но в таком случае возможна ситуация, когда что-нибудь критическое не проверено.

2) А это как раз второй Ваш вопрос: "Как изжить такую ситуацию?"
Имхо, ответ в долгосрочной перспективе тут один: повышать квалификацию тестера.
В краткосрочной возможен следующий вариант: писать для горе-тестера каждый раз чеклисты (как минимум) и полный набор тест-кейсов (как максимум). Далее по каждому "пункту" требовать от него простановки "ОК" / "не ОК". Если перед релизом или (ой-ой-ой) после релиза обнаружится баг по хотя бы одному из "пунктов", нужно начинать серьёзный разговор с тестером о его желании работать и работать честно (ведь по сути он наврал, написав "ОК" там, где есть баг). И отмазка: "Не догадались проверить," - уже не прокатит, т.к. за него уже догадался "проверить" тот, кто написал чек-лист.
  • 0
Форум читаю набегами. По возникшим вопросам можно в скайп (в профиле).

#3 kukolev

kukolev

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

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Александр Куколев

Отправлено 02 декабря 2013 - 16:47

2) А это как раз второй Ваш вопрос: "Как изжить такую ситуацию?"
Имхо, ответ в долгосрочной перспективе тут один: повышать квалификацию тестера.
В краткосрочной возможен следующий вариант: писать для горе-тестера каждый раз чеклисты (как минимум) и полный набор тест-кейсов (как максимум). Далее по каждому "пункту" требовать от него простановки "ОК" / "не ОК". Если перед релизом или (ой-ой-ой) после релиза обнаружится баг по хотя бы одному из "пунктов", нужно начинать серьёзный разговор с тестером о его желании работать и работать честно (ведь по сути он наврал, написав "ОК" там, где есть баг). И отмазка: "Не догадались проверить," - уже не прокатит, т.к. за него уже догадался "проверить" тот, кто написал чек-лист.


Все так и устроено, за тем исключением, что ведущий тестировщик "не догадывается" написать нужные пункты в чек-лист! Получается, что нужно повышать квалификацию тестировщика, разрабатывающего чек-листы?
  • 0

#4 Vita

Vita

    Опытный участник

  • Members
  • PipPipPipPip
  • 315 сообщений
  • ФИО:Виктория
  • Город:Ярославль

Отправлено 02 декабря 2013 - 19:43

Чем больше нагружаете объемами, тем больше может быть ошибок в программах, ошибки бывают всегда, идеального тестирования не бывает. Тестировщик сам должен быть заинтересован и способен повышать квалификацию и работать над собой.
  • 0

С уважением, Vita
... you can learn from that too


#5 Petrov.Sergey

Petrov.Sergey

    Опытный участник

  • Members
  • PipPipPipPip
  • 446 сообщений
  • ФИО:Petrov Sergey
  • Город:МО, Лобня


Отправлено 03 декабря 2013 - 03:32

Все так и устроено, за тем исключением, что ведущий тестировщик "не догадывается" написать нужные пункты в чек-лист! Получается, что нужно повышать квалификацию тестировщика, разрабатывающего чек-листы?

Получается, что так.
Расскажите ему про тест-дизайн, как строить тест-анализ.
Научите строить майнд-карты для тест-анализа. С майнд-картами что-то пропустить гораздо сложнее.

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

В качестве инструмента для майнд-карт советую XMind. Есть бесплатная версия и платная.
  • 0
Форум читаю набегами. По возникшим вопросам можно в скайп (в профиле).

#6 clipsa

clipsa

    Специалист

  • Members
  • PipPipPipPipPip
  • 522 сообщений
  • ФИО:Ермолаева Ольга
  • Город:Москва


Отправлено 03 декабря 2013 - 07:50

Думаю, надо еще рассмотреть процесс разработки в целом, а не отдельно взятую работу отдела тестирования. Возможно пропуск багов происходит не по вине тестеров, а потому что тестерам, например, не предоставляется достаточная информация о разработке, некорректные требования или вообще их отсутствие. Что получают тестировщики на входе помимо ПО, которое надо протестить?
  • 0

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


#7 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 906 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 03 декабря 2013 - 08:34

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


1. В этот проверенный модуль точно не влез кто-то из разработчиков, который захотел внести улучшения для пользователей? Из добрых побуждений, в обход требований, аналитики и тестирования.

2. У вас в процессе есть такое понятие как регрессионные тесты? Если завтра релиз, а тут блокеры.
  • 0

#8 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 03 декабря 2013 - 10:21

У нас все так и работает.
Единственное, что есть нюанс.
Если времени у нас мало (а так практически всегда) то идет примерно так:
программист сделал билд и ставит задачку на тесты.
все баги в кратком формате пишутся в онлайн режиме.
примерно так:

№ бага, описание бага, критичность, время нахождения/номер билда. дополнение. статус. № билда с фиксом. регресс тест. (дальше статус и регресс повторяется до фикса)

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

Время расчитать можно исходя из сложности самого билда, из просчета времени на тестирование со стороны отдела тестирования, и видя баги программист может сказать сколько времени ушло на фиксы. Добавляем предыдущий опыт с похожими билдами и примерно на 90% знаем точное время окончания выполнения задачки.
Удобство в том что и тестировщики и программисты в данной задачке не ограничеы.
Добавляется графа с тестировщик/програмист где указывается ФИО автора.
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#9 ShortLegged

ShortLegged

    Постоянный участник

  • Members
  • PipPipPip
  • 155 сообщений
  • Город:Moscow

Отправлено 03 декабря 2013 - 10:46

При указанной Вами последовательности шагов вполне возможно получение critical дефектов перед продакшеном. Думаю, прежде всего нужно понять причину, почему подобные дефекты не находятся, недостаток квалификации тестировщика/недостаток информации/действия разработчиков и пофиксить ее.
  • 0

#10 kukolev

kukolev

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

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Александр Куколев

Отправлено 03 декабря 2013 - 16:24


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


1. В этот проверенный модуль точно не влез кто-то из разработчиков, который захотел внести улучшения для пользователей? Из добрых побуждений, в обход требований, аналитики и тестирования.

2. У вас в процессе есть такое понятие как регрессионные тесты? Если завтра релиз, а тут блокеры.


1. За это регламентировано отрывание ног депремирование или увольнение - все в курсе
2. На систематические тесты нет ресурсов. Хотя при внесении правки в модуль проверяется весь его функционал, а не только изменения. Беда в том, что после такой проверки и исправления все равно в конце кто нибудь находит ошибку
  • 0

#11 kukolev

kukolev

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

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Александр Куколев

Отправлено 03 декабря 2013 - 16:30

У нас все так и работает.
Единственное, что есть нюанс.

...


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

Бывают еще случаи "Раньше баг не фиксировали, потому что в том билде его не было". Здесь, я так понимаю, нужно хранить предыдущие билды, что пока у нас не делается.
  • 0

#12 kukolev

kukolev

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

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Александр Куколев

Отправлено 03 декабря 2013 - 16:34


Все так и устроено, за тем исключением, что ведущий тестировщик "не догадывается" написать нужные пункты в чек-лист! Получается, что нужно повышать квалификацию тестировщика, разрабатывающего чек-листы?

Получается, что так.
Расскажите ему про тест-дизайн, как строить тест-анализ.
Научите строить майнд-карты для тест-анализа. С майнд-картами что-то пропустить гораздо сложнее.

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

В качестве инструмента для майнд-карт советую XMind. Есть бесплатная версия и платная.



Вот здесь я слаб, признаюсь. Собственно и не тестировщик я по профессии - программист - с тест-дизайном знаком слабо.

Тестировщик помладше тоже пишут чек листы. В этом тоже много минусов - пишут они их похуже... со всеми вытекающими - пропусков еще больше.
  • 0

#13 Petrov.Sergey

Petrov.Sergey

    Опытный участник

  • Members
  • PipPipPipPip
  • 446 сообщений
  • ФИО:Petrov Sergey
  • Город:МО, Лобня


Отправлено 03 декабря 2013 - 18:38

Вот здесь я слаб, признаюсь. Собственно и не тестировщик я по профессии - программист - с тест-дизайном знаком слабо.

Тестировщик помладше тоже пишут чек листы. В этом тоже много минусов - пишут они их похуже... со всеми вытекающими - пропусков еще больше.

Ну, вот приблизительно так строится майнд-карта (аттач). Открывается указанной мной программой XMind

Прикрепленные файлы


  • 0
Форум читаю набегами. По возникшим вопросам можно в скайп (в профиле).

#14 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 04 декабря 2013 - 09:59

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

Данная проблема не искоренится до тех пор, пока каждый свой фикс-дополнение-улучшение не будуи фиксировать.
Зачастую разработчики не сами придумывают что-то что добавляют , чаще это на стороне ПМ - а.
и о таких фиксах-изменениях забывают предупреждать тестировщика.
В подобных случаях ПМ несет ответственность за ушедший баг. Пока не научится помнить.)
У нас эта проблема присутствует также. Разбирали буквально на прошлой неделе.


Бывают еще случаи "Раньше баг не фиксировали, потому что в том билде его не было". Здесь, я так понимаю, нужно хранить предыдущие билды, что пока у нас не делается.

Ну практически все тоже самое, что и выше.
Билды хранить нужно.
У нас в свн-е можно откатить версию на предыдущую и по конфигам посмотрет, что было на тот момент.

Но вообще это все проблема коммуникаций. В тот же скайп /вики / подойти сказать / что вот мы еще вот это изменили вроде как не сложно. Но все почему-то об этом забывают.
Последнее время я сразу пытаю разработчика о чем в очередной раз они говорили с пм-ом.
а перед сдачей билда спрашиваю и ПМ-а, что они вносили новенького кроме ... перечисляю.
Обычно что-то всплывает.
Но это тоже не всегда выход.
Поэтому, что не описано в задачке на тестирование (в вики) - если ушло на боевой - сам ПМ и бьется головой. Или убивает разработчиков что не внесли.
как -то так.
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#15 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 04 декабря 2013 - 10:09

По поводу ведущего тестиировщика и всего прочитанного выше.

Если младшие тестировщики не умеют писать чек-листы, то вы меня простите, но нафига такие тестировщики?
Пусть учатся тогда что-ли.
После работы берем того - же Савина садимся и пробуем.

Введите -летучку-
при получении ПО на тесты, соберитесь отделом, разбейте функционал на блоки, нарисуйте майнд-карту на том эе флип-чарте.
Устройте совместный мозговой штурм, выявите критичный функционал. И пусть по ним дописывают чек-листы. Это ж не сложно.

Да вы убьете на эту летучку час - два, но ведущему тестировщику потом не придеться сидеть и перепроверять каждый чек лист.(это ж с ума сойти)
На майнд карте будут отмечаться пункты проверки. И ведущему тестировщику наглядно будет видно, что происходит с тестами ПО.
Судя по описанию у ведущего тестировщика нет времени обучать команду.
Мне вообще не понять как так могут работать люди. Если они не могут написать тесты, то как они тестируют в целом? Это же 90% что будут пропущены баги. :mega_shok:

Ну или отправьте их на тренинги что-ли. Благо их даже в онлайне куча.
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#16 krukovskiy

krukovskiy

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

  • Members
  • Pip
  • 29 сообщений

Отправлено 04 декабря 2013 - 17:03

Мечта каждого менеджера - получить предсказуемый масштабируемый процесс разработки (качественного) ПО. Однако, идея сейчас недостижимая по причине разной производительности сотрудников и разного "веса" задач. Эффективный вариант планирования - скрам покер.
Предлагаю два направления для исправления критичных багов в продакшене:
1. Улучшение качества разработки (юнит тесты, ревью кода, парное программирование) - если много критичных багов, никакое тестирование не поможет. Надо копать в архитектуру и качество разработки.
2. Попробуйте бета-тестирование. Пусть менеджеры/техподдержка погоняют продукт перед релизом. Это поможет обнаружить новые юзер кейсы и добавит доверия к разработчикам.
  • 0
Тестирование с гарантией - http://qapl.net

#17 SDA13

SDA13

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

  • Members
  • Pip
  • 19 сообщений
  • ФИО:СДА


Отправлено 09 декабря 2013 - 07:09

По теме: у нас именно так и работает процесс, тобиш 3 и 4 пункты повторяются и повторяются. Ответ сему прост: кто-то умудрился задеть смежный модуль другой части системы и это зааффектило на мой кусок системы, который я тестирую.
Перед сдачей обязательно делать регресс, без него никуда.
Вот совсем недавно был казалось бы просто элемент в системе (грубо говоря скрипт который из папки подсасывал изображения и отображал их), а по нему оказалось более 2 десятков баг, начиная от юзабилити и заканчивая секьюрити, потом когда я почти что закрыть был его готов какой-то умелец в рамках иной задачи разломал пусти в системе и стали пропадать слеши в пути к папке откуда брались изображения, фактически несолько баг переоткрывались заново.
Но а если что-то прошло на продакт, то тут уже сам дурак, считаю моей ошибкой, что не усмотрел, но пока такого не было. Другое дело если баг вчера был закрыт, а сегодня воспроизвелся после билда.
  • 0

#18 jjjzmey

jjjzmey

    Постоянный участник

  • Members
  • PipPipPip
  • 248 сообщений
  • ФИО:Ян Юшин
  • Город:Питер


Отправлено 20 декабря 2013 - 08:04

Собрать статистику по причинам ненахождения багов в процессе тестирования
(забыли проверить - всего лишь один из возможных вариантов)

Обсуждать чек-листы и тест-кейсы как командой тестировщиков так и в расширенном составе с привлечением разработчиков, аналитиков. Коллективный разум лучше чем принцип "пускай конь думает, у него голова большая"
  • 1


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



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

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

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