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

Фотография

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


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 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
  • 527 сообщений
  • ФИО:Ермолаева Ольга
  • Город:Москва


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

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

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


#7 Vasiliy

Vasiliy

    Профессионал

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

Отправлено 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


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

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