Идеальная работа отдела тестирования
#1
Отправлено 02 декабря 2013 - 16:19
Есть острое желание организовать процесс тестирования примерно следующим образом:
1. Программист отдает задачу на тест
2. Тестировщик тестирует
3. Программист правит баги, снова отдает задачу
4. Тестировщик тестирует
... повторяются шаги 3-4
N. Тестировщик убедившись, что все баги исправлены и новые не выявлены закрывает задачу
Собственно вопросы - возможно ли добиться такой четкости с предсказуемым временем всего процесса?
Достижим ли шаг N? На данный момент распространена следующая ситуация: завтра релиз, все задачи закрыты, все хорошо... как вдруг - блокирующий баг в уже проверенном модуле! На вопрос "Почему раньше не выявили?" следует ответ "Не догадались проверить..."
Как изжить такую ситуацию?
#2
Отправлено 02 декабря 2013 - 16:40
1) Достичь описанного процесса можно и нужно.Коллеги, нужен ваш совет!
Есть острое желание организовать процесс тестирования примерно следующим образом:
1. Программист отдает задачу на тест
2. Тестировщик тестирует
3. Программист правит баги, снова отдает задачу
4. Тестировщик тестирует
... повторяются шаги 3-4
N. Тестировщик убедившись, что все баги исправлены и новые не выявлены закрывает задачу
Собственно вопросы - возможно ли добиться такой четкости с предсказуемым временем всего процесса?
Достижим ли шаг N? На данный момент распространена следующая ситуация: завтра релиз, все задачи закрыты, все хорошо... как вдруг - блокирующий баг в уже проверенном модуле! На вопрос "Почему раньше не выявили?" следует ответ "Не догадались проверить..."
Как изжить такую ситуацию?
Предсказуемости времени, имхо, можно достичь только при соответствующей квалификации каждого участника описанного цикла.
Ну, по крайней мере, существуют программисты, которые правят одно и ломают другое. Или вместо исправления N багов по одному тесту правят K (< N) и добавляют L багов.
Впрочем, существуют тестеры, которые, не проверив со всех сторон, считают задачу выполненной. То есть описанный цикл по конкретной задаче приходит к завершению. Но в таком случае возможна ситуация, когда что-нибудь критическое не проверено.
2) А это как раз второй Ваш вопрос: "Как изжить такую ситуацию?"
Имхо, ответ в долгосрочной перспективе тут один: повышать квалификацию тестера.
В краткосрочной возможен следующий вариант: писать для горе-тестера каждый раз чеклисты (как минимум) и полный набор тест-кейсов (как максимум). Далее по каждому "пункту" требовать от него простановки "ОК" / "не ОК". Если перед релизом или (ой-ой-ой) после релиза обнаружится баг по хотя бы одному из "пунктов", нужно начинать серьёзный разговор с тестером о его желании работать и работать честно (ведь по сути он наврал, написав "ОК" там, где есть баг). И отмазка: "Не догадались проверить," - уже не прокатит, т.к. за него уже догадался "проверить" тот, кто написал чек-лист.
#3
Отправлено 02 декабря 2013 - 16:47
2) А это как раз второй Ваш вопрос: "Как изжить такую ситуацию?"
Имхо, ответ в долгосрочной перспективе тут один: повышать квалификацию тестера.
В краткосрочной возможен следующий вариант: писать для горе-тестера каждый раз чеклисты (как минимум) и полный набор тест-кейсов (как максимум). Далее по каждому "пункту" требовать от него простановки "ОК" / "не ОК". Если перед релизом или (ой-ой-ой) после релиза обнаружится баг по хотя бы одному из "пунктов", нужно начинать серьёзный разговор с тестером о его желании работать и работать честно (ведь по сути он наврал, написав "ОК" там, где есть баг). И отмазка: "Не догадались проверить," - уже не прокатит, т.к. за него уже догадался "проверить" тот, кто написал чек-лист.
Все так и устроено, за тем исключением, что ведущий тестировщик "не догадывается" написать нужные пункты в чек-лист! Получается, что нужно повышать квалификацию тестировщика, разрабатывающего чек-листы?
#4
Отправлено 02 декабря 2013 - 19:43
С уважением, Vita
... you can learn from that too
#5
Отправлено 03 декабря 2013 - 03:32
Получается, что так.Все так и устроено, за тем исключением, что ведущий тестировщик "не догадывается" написать нужные пункты в чек-лист! Получается, что нужно повышать квалификацию тестировщика, разрабатывающего чек-листы?
Расскажите ему про тест-дизайн, как строить тест-анализ.
Научите строить майнд-карты для тест-анализа. С майнд-картами что-то пропустить гораздо сложнее.
Плюс разгрузите ведущего тестировщика. Писать чек-листы для всех довольно тяжело и трудоёмко. Подучите тестировщиков помладше, чтобы они тоже писали чек-листы. А на первых порах пусть дают на проверку ведущему тестировщику.
Убьёте двух зайцев: 1) повышаете квалификацию братьев Ваших меньших; 2) разгружаете ведущего тестировщика.
В качестве инструмента для майнд-карт советую XMind. Есть бесплатная версия и платная.
#6
Отправлено 03 декабря 2013 - 07:50
Не следует заставлять тестировщиков тестировать быстрее. Что может быть хуже испуганных, усталых, цинично настроенных тестировщиков?
-----------------
Хорошо, когда человек заводит баги. Плохо, когда баги заводят человека (с)
-----------------
Проект для начинающих тестировщиков Хомячки
#7
Отправлено 03 декабря 2013 - 08:34
... завтра релиз, все задачи закрыты, все хорошо... как вдруг - блокирующий баг в уже проверенном модуле! На вопрос "Почему раньше не выявили?" следует ответ "Не догадались проверить..."
1. В этот проверенный модуль точно не влез кто-то из разработчиков, который захотел внести улучшения для пользователей? Из добрых побуждений, в обход требований, аналитики и тестирования.
2. У вас в процессе есть такое понятие как регрессионные тесты? Если завтра релиз, а тут блокеры.
#8
Отправлено 03 декабря 2013 - 10:21
Единственное, что есть нюанс.
Если времени у нас мало (а так практически всегда) то идет примерно так:
программист сделал билд и ставит задачку на тесты.
все баги в кратком формате пишутся в онлайн режиме.
примерно так:
№ бага, описание бага, критичность, время нахождения/номер билда. дополнение. статус. № билда с фиксом. регресс тест. (дальше статус и регресс повторяется до фикса)
соответственно, тестировщик найдя багу заполняет соответствующие поля, и тестирует дальше.
Программист видя баги и критичности, пока мы тестируем занимается фиксом задачек, и заполняет поля.
таким образом к моменту когда ты закончил тестировать билд Х, программист тебе уже заливает билд У с фиксами багов.
и поехали дальше.
Время расчитать можно исходя из сложности самого билда, из просчета времени на тестирование со стороны отдела тестирования, и видя баги программист может сказать сколько времени ушло на фиксы. Добавляем предыдущий опыт с похожими билдами и примерно на 90% знаем точное время окончания выполнения задачки.
Удобство в том что и тестировщики и программисты в данной задачке не ограничеы.
Добавляется графа с тестировщик/програмист где указывается ФИО автора.
#9
Отправлено 03 декабря 2013 - 10:46
#10
Отправлено 03 декабря 2013 - 16:24
... завтра релиз, все задачи закрыты, все хорошо... как вдруг - блокирующий баг в уже проверенном модуле! На вопрос "Почему раньше не выявили?" следует ответ "Не догадались проверить..."
1. В этот проверенный модуль точно не влез кто-то из разработчиков, который захотел внести улучшения для пользователей? Из добрых побуждений, в обход требований, аналитики и тестирования.
2. У вас в процессе есть такое понятие как регрессионные тесты? Если завтра релиз, а тут блокеры.
1. За это регламентировано
2. На систематические тесты нет ресурсов. Хотя при внесении правки в модуль проверяется весь его функционал, а не только изменения. Беда в том, что после такой проверки и исправления все равно в конце кто нибудь находит ошибку
#11
Отправлено 03 декабря 2013 - 16:30
У нас все так и работает.
Единственное, что есть нюанс.
...
У нас все в точности так-же. Проблема сохраняется - под конец кто-то находит баг в проверенном модуле. При чем зачастую баг из серии "решили сейчас вот немного по другому проверить и ..." - в общем, как будто на предыдущей стадии не было сделано нужного количества проверок
Бывают еще случаи "Раньше баг не фиксировали, потому что в том билде его не было". Здесь, я так понимаю, нужно хранить предыдущие билды, что пока у нас не делается.
#12
Отправлено 03 декабря 2013 - 16:34
Получается, что так.
Все так и устроено, за тем исключением, что ведущий тестировщик "не догадывается" написать нужные пункты в чек-лист! Получается, что нужно повышать квалификацию тестировщика, разрабатывающего чек-листы?
Расскажите ему про тест-дизайн, как строить тест-анализ.
Научите строить майнд-карты для тест-анализа. С майнд-картами что-то пропустить гораздо сложнее.
Плюс разгрузите ведущего тестировщика. Писать чек-листы для всех довольно тяжело и трудоёмко. Подучите тестировщиков помладше, чтобы они тоже писали чек-листы. А на первых порах пусть дают на проверку ведущему тестировщику.
Убьёте двух зайцев: 1) повышаете квалификацию братьев Ваших меньших; 2) разгружаете ведущего тестировщика.
В качестве инструмента для майнд-карт советую XMind. Есть бесплатная версия и платная.
Вот здесь я слаб, признаюсь. Собственно и не тестировщик я по профессии - программист - с тест-дизайном знаком слабо.
Тестировщик помладше тоже пишут чек листы. В этом тоже много минусов - пишут они их похуже... со всеми вытекающими - пропусков еще больше.
#13
Отправлено 03 декабря 2013 - 18:38
Ну, вот приблизительно так строится майнд-карта (аттач). Открывается указанной мной программой XMindВот здесь я слаб, признаюсь. Собственно и не тестировщик я по профессии - программист - с тест-дизайном знаком слабо.
Тестировщик помладше тоже пишут чек листы. В этом тоже много минусов - пишут они их похуже... со всеми вытекающими - пропусков еще больше.
Прикрепленные файлы
#14
Отправлено 04 декабря 2013 - 09:59
Данная проблема не искоренится до тех пор, пока каждый свой фикс-дополнение-улучшение не будуи фиксировать.У нас все в точности так-же. Проблема сохраняется - под конец кто-то находит баг в проверенном модуле. При чем зачастую баг из серии "решили сейчас вот немного по другому проверить и ..."
Зачастую разработчики не сами придумывают что-то что добавляют , чаще это на стороне ПМ - а.
и о таких фиксах-изменениях забывают предупреждать тестировщика.
В подобных случаях ПМ несет ответственность за ушедший баг. Пока не научится помнить.)
У нас эта проблема присутствует также. Разбирали буквально на прошлой неделе.
Ну практически все тоже самое, что и выше.Бывают еще случаи "Раньше баг не фиксировали, потому что в том билде его не было". Здесь, я так понимаю, нужно хранить предыдущие билды, что пока у нас не делается.
Билды хранить нужно.
У нас в свн-е можно откатить версию на предыдущую и по конфигам посмотрет, что было на тот момент.
Но вообще это все проблема коммуникаций. В тот же скайп /вики / подойти сказать / что вот мы еще вот это изменили вроде как не сложно. Но все почему-то об этом забывают.
Последнее время я сразу пытаю разработчика о чем в очередной раз они говорили с пм-ом.
а перед сдачей билда спрашиваю и ПМ-а, что они вносили новенького кроме ... перечисляю.
Обычно что-то всплывает.
Но это тоже не всегда выход.
Поэтому, что не описано в задачке на тестирование (в вики) - если ушло на боевой - сам ПМ и бьется головой. Или убивает разработчиков что не внесли.
как -то так.
#15
Отправлено 04 декабря 2013 - 10:09
Если младшие тестировщики не умеют писать чек-листы, то вы меня простите, но нафига такие тестировщики?
Пусть учатся тогда что-ли.
После работы берем того - же Савина садимся и пробуем.
Введите -летучку-
при получении ПО на тесты, соберитесь отделом, разбейте функционал на блоки, нарисуйте майнд-карту на том эе флип-чарте.
Устройте совместный мозговой штурм, выявите критичный функционал. И пусть по ним дописывают чек-листы. Это ж не сложно.
Да вы убьете на эту летучку час - два, но ведущему тестировщику потом не придеться сидеть и перепроверять каждый чек лист.(это ж с ума сойти)
На майнд карте будут отмечаться пункты проверки. И ведущему тестировщику наглядно будет видно, что происходит с тестами ПО.
Судя по описанию у ведущего тестировщика нет времени обучать команду.
Мне вообще не понять как так могут работать люди. Если они не могут написать тесты, то как они тестируют в целом? Это же 90% что будут пропущены баги.
Ну или отправьте их на тренинги что-ли. Благо их даже в онлайне куча.
#16
Отправлено 04 декабря 2013 - 17:03
Предлагаю два направления для исправления критичных багов в продакшене:
1. Улучшение качества разработки (юнит тесты, ревью кода, парное программирование) - если много критичных багов, никакое тестирование не поможет. Надо копать в архитектуру и качество разработки.
2. Попробуйте бета-тестирование. Пусть менеджеры/техподдержка погоняют продукт перед релизом. Это поможет обнаружить новые юзер кейсы и добавит доверия к разработчикам.
#17
Отправлено 09 декабря 2013 - 07:09
Перед сдачей обязательно делать регресс, без него никуда.
Вот совсем недавно был казалось бы просто элемент в системе (грубо говоря скрипт который из папки подсасывал изображения и отображал их), а по нему оказалось более 2 десятков баг, начиная от юзабилити и заканчивая секьюрити, потом когда я почти что закрыть был его готов какой-то умелец в рамках иной задачи разломал пусти в системе и стали пропадать слеши в пути к папке откуда брались изображения, фактически несолько баг переоткрывались заново.
Но а если что-то прошло на продакт, то тут уже сам дурак, считаю моей ошибкой, что не усмотрел, но пока такого не было. Другое дело если баг вчера был закрыт, а сегодня воспроизвелся после билда.
#18
Отправлено 20 декабря 2013 - 08:04
(забыли проверить - всего лишь один из возможных вариантов)
Обсуждать чек-листы и тест-кейсы как командой тестировщиков так и в расширенном составе с привлечением разработчиков, аналитиков. Коллективный разум лучше чем принцип "пускай конь думает, у него голова большая"
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных