я считаю эффективность по конечной цели компании, а не по количеству багов, задумайся над этим ;)
#21
Отправлено 08 октября 2015 - 15:01
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#22
Отправлено 08 октября 2015 - 15:02
И какая эффективность? З/пл разработчика (0.5 ч) и тестировщика (1.5 ч)? Имхо, нормальный раскла
И какая эффективность? З/пл разработчика (0.5 ч) и тестировщика (1.5 ч)? Или кто-то предпочитает по другому вести дело? Имхо, нормальный расклад. Было бы ненормально, если было бы наоборот.
ты считаешь эффективность по зарплате?
за эти полтора часа можно было бы найти еще как минимум 5 таких же 'явных' багов, я считаю
Олег прав. А что касается зп, фикс багов зачастую на кого? Правильно, на джуниор разработчиков возлагают.
#23
Отправлено 08 октября 2015 - 15:05
я считаю эффективность по конечной цели компании, а не по количеству багов, задумайся над этим ;)
А какая конечная цель компании?
#24
Отправлено 08 октября 2015 - 15:09
И какая эффективность? З/пл разработчика (0.5 ч) и тестировщика (1.5 ч)? Имхо, нормальный раскла
И какая эффективность? З/пл разработчика (0.5 ч) и тестировщика (1.5 ч)? Или кто-то предпочитает по другому вести дело? Имхо, нормальный расклад. Было бы ненормально, если было бы наоборот.
ты считаешь эффективность по зарплате?
за эти полтора часа можно было бы найти еще как минимум 5 таких же 'явных' багов, я считаю
Олег прав. А что касается зп, фикс багов зачастую на кого? Правильно, на джуниор разработчиков возлагают.
Обычно... хм... обычно их просто не на кого возлагать...)))
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#25
Отправлено 08 октября 2015 - 15:30
Приложение было веб и со сложной логикой. Понять в чём ошибка было не возможно вообще, так как основные баги были именно в логике работы приложения.
Ну тогда возникают вопросы к менеджеру по персоналу или начальнику "тестера"
#26
Отправлено 09 октября 2015 - 07:20
А какая конечная цель компании?
Конечная цель компании - зарабатывать деньги. И хорошо, когда эту мысль понимает не только персонал с управленческими функциями.
#27
Отправлено 09 октября 2015 - 08:20
А какая конечная цель компании?
Конечная цель компании - зарабатывать деньги. И хорошо, когда эту мысль понимает не только персонал с управленческими функциями.
Никто не спорит. Это всё чудестно. Есть только несколько моментов. Путь, по которому компания идёт в вопросе зарабатывания денег. И второе - роль сотрудников в этом процессе. То есть, если процесс построен на принципах совокупного вклада в прибыль и отдача от этого, то да, каждый понимает свою роль и сотрудник конечно тоже. Но обычно, сотруднику вполне справедливо пофигу на прибыль компании. Ему то что с неё?
#28
Отправлено 15 октября 2015 - 07:57
Никто не спорит. Это всё чудестно. Есть только несколько моментов. Путь, по которому компания идёт в вопросе зарабатывания денег.
Про пути не понял.
И второе - роль сотрудников в этом процессе. То есть, если процесс построен на принципах совокупного вклада в прибыль и отдача от этого, то да, каждый понимает свою роль и сотрудник конечно тоже. Но обычно, сотруднику вполне справедливо пофигу на прибыль компании. Ему то что с неё?
Человек волен выбирать, где ему работать: в компании, где ценят (или хотя бы очень стараются это сделать) вклад каждого сотрудника в общее дело или в другого рода компаниях.
#29
Отправлено 15 октября 2015 - 08:41
Я работаю в компании, где вклад каждого ценен. Но, именно ценя время разработчика, тестировщик пытается докопаться до истины.
Кстати, это же черта характера — копать до конца или «о, нашел, да и ладно». Имхо, лучшие тестировщики с первой чертой, они и учатся постоянно и тд и тп. Но на проектах всякие люди бывают нужны :)
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#30
Отправлено 15 октября 2015 - 09:57
Кстати, это же черта характера — копать до конца или «о, нашел, да и ладно». Имхо, лучшие тестировщики с первой чертой, они и учатся постоянно и тд и тп. Но на проектах всякие люди бывают нужны :)
Т.е. Вы готовы пожертвовать качеством релиза из - за поиска сути явного бага ?
#31
Отправлено 15 октября 2015 - 10:31
Зачем вы утрируете?
То есть раскопать баг = пожертвовать качеством релиза? Бред какой-то, что-то не так с процессами в компании, которая так считает.
И именно этим прикрываются тестировщики — да там все очевидно же! Баг явный, ну явный же.
Только вот на деле этот «явный» баг может оказаться совсем неявным. Когда у разработчика не воспроизведется. Потому что тестировщик не локализовал проблему, а нашел только поверхностный всплеск
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#32
Отправлено 15 октября 2015 - 10:56
То есть раскопать баг = пожертвовать качеством релиза? Бред какой-то, что-то не так с процессами в компании, которая так считает.
я уже писал, что за 1.5 часа который тестировщик потратил на явный баг можно найти 5 таких же явных багов.
Да и разработчик потратил на баг 0.5 часа. Это на системный поиск проблемы и исправление.
Допустим, у Вас поджимает время до выпуска релиза и вы копаете тот явный баг , который и воспроизвести то не составляет труда, но зачем то вы все равно копаете , я не знаю для чего, потому что разработчик скорее всего все равно прочитает только заголовок и посмотрит скриншот таска.
Ну и вследстивии копания упустили 4 бага(дпустим не явных, а где нужны специфические условия для воспроизведения).
Не знаю , что тут бредового , по моему это вполне реальная ситуация.
Или во всех компаниях гибкие сроки тестирования ? типа , подождем пока тестировщик дотестирует.
P.S. И я говорю про явный баг который воспроизводится всегда , как в примере. Не логиниться в кабинет пользователя при любых условиях.
#33
Отправлено 15 октября 2015 - 22:59
Иногда, по разным причинам копаюсь.
#34
Отправлено 16 октября 2015 - 04:40
А мне нравятся компании, которые вкладываются в сотрудника. Которые обучают его. Отправляют на тренинги, конференции. предоставляют книжки, помогают расти внутренними задачами.
И если человеку интересно раскапывать баг — то помогают ему.
При этом я так и не поняла, почему это мое мнение тут же превратилось в «тестировщик заваливает дедлайн, аааааа!!1».
Если вас поджимает время выпуска, то весь процесс может меняться. Баги могут даже в багтрекер не заносится, а фиксится на ходу — и это нормально. Но это не значит, что после дедлайна процесс в компании останется тот же.
И если мы говорим о явном баге, то у меня скорее возник бы вопрос — а почему вообще тестировщик причины явного бага искал полтора часа? Может, его надо чему-то научить? Чтобы он тратил меньше времени на это?
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#35
Отправлено 16 октября 2015 - 06:43
Вставлю и свои 5 копеек.
О необходимости копаться в поиске первопричины бага обсуждал с разработчиками, так как им это править
Случай 1:
После разговора с фронтенд разработчиком, мне был дан ясный ответ:
"Если нужно поправить верстку, было бы отлично чтобы было указано что и насколько сместить/отодвинуть/добавить отступ и т.д"
Случай 2:
После общения с бэкенд разработчиком, ответ был немного иначе:
"Если код писал я - ненужно особо копаться, достаточно шагов воспроизведения. Но если писал не я, а мне придется это править - лучше будет более детально расписать, так как чтобы мне вникнуть(а если еще он и не работал с этим проектом!) нужно немало времени."
Правда есть и те кому пофиг, но это уже отдельная тема.
Как всегда, вывод один: Прежде чем что то менять в подходе к описанию/копания бага, спросите разработчиков, надо им это или нет.
Если идею никто из разработчиков не поддерживает, то это бесполезный выхлоп для компании который влечет потерю времени(как для себя это вполне годный скил в любом случае).
#36
Отправлено 16 октября 2015 - 09:28
Как всегда, вывод один: Прежде чем что то менять в подходе к описанию/копания бага, спросите разработчиков, надо им это или нет.
Если идею никто из разработчиков не поддерживает, то это бесполезный выхлоп для компании который влечет потерю времени(как для себя это вполне годный скил в любом случае).
Плюсую!
Нет единого стандарта, как надо.
Нельзя нападать на тестировщика за то, что он полтора часа что-то выискивал. Это может быть нужно, а может быть нет.
Правда, иногда разработчик не догадывается, насколько ты можешь облегчить ему жизнь :) Но если ему реально пофиг — то не нужно и начинать
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/
#37
Отправлено 16 октября 2015 - 12:33
И если мы говорим о явном баге, то у меня скорее возник бы вопрос — а почему вообще тестировщик причины явного бага искал полтора часа? Может, его надо чему-то научить? Чтобы он тратил меньше времени на это?
Явное проявление абсолютно ничего не имеет общего с явной причиной.
#38
Отправлено 16 октября 2015 - 13:36
Искать, не искать причину "явного бага" – сильно зависит от окружающей обстановки.
Если у вас через 2 часа показа, то тратить время на поиски причины "явного бага" - глупо.
Если у вас работа разработчик расписана на год вперед, то писать "явный баг" не разобравшись в причинах, тоже не очень хорошо.
Я лично считаю, что лучше найти причину: улучшает знания о системе; освобождает время разработчика; в процессе поиска причины, находятся другие баги. Но мне кажется, главное четко ограничивать себя по времени поиска причины (на этот баг я потрачу не больше 30 минут и т.п.), а то можно все время на тестирования потратить.
#39
Отправлено 16 октября 2015 - 14:09
Может, его надо чему-то научить? Чтобы он тратил меньше времени на это?
Вы намекаете на то, что его нужно отправить к Вам в школу тестировщиков ?
#40
Отправлено 17 октября 2015 - 15:04
Нельзя нападать на тестировщика за то, что он полтора часа что-то выискивал. Это может быть нужно, а может быть нет.
Нападать не нужно! А вот указать на то, что он впустую тратит рабочее время надо обязательно! Кто-то же из старших или более опытных на проекте обязательно знает стоит этим заниматься или нет.
А иначе человек уходит в задачу на целый день, а потом, когда начинаешь объяснять, что там работы на час было, обижается.
Темы с аналогичным тегами Ручное Тестирование
Работа и карьера →
Работа для тестировщика/QA →
Работа/Росcия →
Ищем инженера-тестировщика ПО (Middle) г.ЕкатеринбургАвтор arnellatash, 17 фев 2023 ручное тестирование, тестирование и 1 еще... |
|
|||
Тестирование →
Начинающему тестировщику →
Помогите начинающему тестировщикуАвтор JulJL, 22 дек 2022 Тестирование, Ручное тестирование и 1 еще... |
|
|||
Тестирование →
Тест-дизайн и ручное тестирование →
Вопрос о инструментах для моб тестированияАвтор starikoff1336, 10 июл 2021 РУЧНОЕ ТЕСТИРОВАНИЕ |
|
|||
Работа и карьера →
Работа для тестировщика/QA →
Работа/Москва →
Ручной Тестировщик мобильного приложения (iOS, Android)Автор AndrewSF, 08 апр 2021 работа, удаленка и 2 еще... |
|
|||
Работа и карьера →
Работа для тестировщика/QA →
Удаленная работа →
Ручной тестировщик, AutoFAQ.ai, удаленная работаАвтор VladislavBelyaev, 16 окт 2020 ручное тестирование и 5 еще... |
|
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных