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

Фотография

7% - высокий ли процент ошибок с боевого?


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

#21 Vla8islav

Vla8islav

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

  • Members
  • Pip
  • 20 сообщений
  • ФИО:Пилипенко Владислав Валерьевич


Отправлено 11 апреля 2016 - 17:53

В моем простом мозгу тут же возник вопрос: это важно? Если да, то почему?

 

Вот у нас есть бизнес. Они деньги зарабатывают. И есть, насколько я понимаю, в том или ином виде отдел тестирования.

В первую очередь отдел тестирования - камень на шее проекта. В простейшем случае до того, как он появился, разработка выглядела так:

 

Разработчики > Прод

 

а теперь стало

 

Разработчики > Тестировщики > Прод

 

Негативный эффект, хотя бы от увеличения TTM(время доставки функционала на бой), на лицо. 

Тут возникает вопрос: дает ли отдел тестирования больше ценности, чем забирает?

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

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

Имеют смысл только те метрики, которые установил бизнес. Если бизнес устраивает 15% багов, найденных отделом тестирования - все ок. Если не устраивает 98.3% - в консерватории надо что-то менять.


  • 0

#22 clipsa

clipsa

    Специалист

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


Отправлено 12 апреля 2016 - 07:39

Имеют смысл только те метрики, которые установил бизнес. Если бизнес устраивает 15% багов, найденных отделом тестирования - все ок. Если не устраивает 98.3% - в консерватории надо что-то менять.

ИМХО, бизнесу глубоко пофиг сколько процентов багов было найдено на тесте или на проде, им важно, чтобы пользователи не наткнулись на такие баги, которые повредят бизнесу, соответственно, тестировщики должны такие баги отлавливать на тесте.


  • 0

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


#23 Сергей

Сергей

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

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 12 апреля 2016 - 07:58

Отдел тестирования нужен не для того, чтобы компанию валить багами и получать свою скромную зарплату, а чтобы компания имела актуальный срез и улучшала качество продукта. Если команда разработчиков небольшая и справляется своими силами, то, имхо, можно и не иметь отдел тестирования. Но на практике, разработчики ещё не то наплетут, какая у них хорошая программа. И ведь верят же, там...) Плюс вы так уверены в своем проценте ошибок? Вам кто его сказал? Клиенты? А сколько у вас их? Несколько миллионов? А вы посчитали, сколько отваливается клиентов, увидев всякую неработающую дрянь? Такие вопросы могут возникать только либо у джуниоров или директоров, не понимающих в процессе разработки ничего!


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#24 Vla8islav

Vla8islav

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

  • Members
  • Pip
  • 20 сообщений
  • ФИО:Пилипенко Владислав Валерьевич


Отправлено 12 апреля 2016 - 09:02

 

Имеют смысл только те метрики, которые установил бизнес. Если бизнес устраивает 15% багов, найденных отделом тестирования - все ок. Если не устраивает 98.3% - в консерватории надо что-то менять.

ИМХО, бизнесу глубоко пофиг сколько процентов багов было найдено на тесте или на проде, им важно, чтобы пользователи не наткнулись на такие баги, которые повредят бизнесу, соответственно, тестировщики должны такие баги отлавливать на тесте.

 

А вот и метрика. Осталось только формализовать, нет?


  • 0

#25 clipsa

clipsa

    Специалист

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


Отправлено 12 апреля 2016 - 10:09

 

 

Имеют смысл только те метрики, которые установил бизнес. Если бизнес устраивает 15% багов, найденных отделом тестирования - все ок. Если не устраивает 98.3% - в консерватории надо что-то менять.

ИМХО, бизнесу глубоко пофиг сколько процентов багов было найдено на тесте или на проде, им важно, чтобы пользователи не наткнулись на такие баги, которые повредят бизнесу, соответственно, тестировщики должны такие баги отлавливать на тесте.

 

А вот и метрика. Осталось только формализовать, нет?

 

мы об этом говорили почти с самого начала этой темы. У дефектов есть критичность.


  • 0

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


#26 DmitriyQA

DmitriyQA

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

  • Members
  • PipPipPip
  • 183 сообщений
  • ФИО:Коваленко Дмитрий Владимирович
  • Город:Tel Aviv

Отправлено 13 апреля 2016 - 11:37

По моему мнения вертикаль взаимодействия совсем не так выглядит. 

 

Правильно:

Продаткт -> Прогрраммисты -> Тестировщики ->  Пользователи. 

                        <<< а тут обратная связь <<

 

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

В некоторых маленьких компаниях в этой схеме действительно нет отдела тестирования, тоесть все баги находят пользователи и комплейнят о них через саппорт.

Но такая система работает только для маленьких бесплатных проектов, которые ничего не продают. В случае же продаж, после первого критического бага потребуют деньги назад.

 

Вот тут и начинает окупатся отдел тестирования. С ростом компании появляется репутация, имидж, конкуренты, оставьте дыру в безопансоти и завтра база ваших клиентов будет разослана по интернету. 

Отдел тестирования становится актуальным в компаниях где работает больше 10 человек. 


  • 0

Senior QA/ Wix.com / qaacademy.net


#27 Vla8islav

Vla8islav

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

  • Members
  • Pip
  • 20 сообщений
  • ФИО:Пилипенко Владислав Валерьевич


Отправлено 13 апреля 2016 - 13:14

По моему мнения вертикаль взаимодействия совсем не так выглядит. 

 

Правильно:

Продаткт -> Прогрраммисты -> Тестировщики ->  Пользователи. 

                        <<< а тут обратная связь <<

 

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

В некоторых маленьких компаниях в этой схеме действительно нет отдела тестирования, тоесть все баги находят пользователи и комплейнят о них через саппорт.

Но такая система работает только для маленьких бесплатных проектов, которые ничего не продают. В случае же продаж, после первого критического бага потребуют деньги назад.

 

Вот тут и начинает окупатся отдел тестирования. С ростом компании появляется репутация, имидж, конкуренты, оставьте дыру в безопансоти и завтра база ваших клиентов будет разослана по интернету. 

Отдел тестирования становится актуальным в компаниях где работает больше 10 человек. 

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

 

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

 

Помнится, у Баранцева была замечательная лекция(смотрел на ютубе, но сейчас сходу ссылку вряд ли дам), где он приводил в пример три модели команд разработчиков(А, B и C), пилящих примерно одинаковые задачи и их взаимодействие с командой тестирования, которой для полноценной проверки(понятно, что такой быть не может, это просто модель) требуется пройти N тест-кейсов(допустим, 60). При этом А - сверхчеловеки, которые не ошибаются, B - почти сверхчеловеки, которые баги делают изредка, и C - команда туда-сюда, которая делает багов существенно больше B, но все еще с виду ок. Даже в такой модели после нескольких итераций производительность команды тестирования, которые работали с С, очень серьезно деградировала.

 

Моя мысль проста - никакой отдел тестирования не поможет, если работает с командой С. Дыры будут находиться, бизнес все равно будет страдать. А команда B(команды А в принципе существовать не может) и так будет допускать очень мало дефектов, особенно критических(они, очевидно, так или иначе свой код тестируют). И в случае с командой B надо считать, нужен ли отдел тестирования.


  • 0

#28 DmitriyQA

DmitriyQA

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

  • Members
  • PipPipPip
  • 183 сообщений
  • ФИО:Коваленко Дмитрий Владимирович
  • Город:Tel Aviv

Отправлено 13 апреля 2016 - 13:46

Я не вижу смысла говорить об абстрактных человеках которые не делают багов, их не бывает.

Скажу о конкретной технологии.

TDD или BDD очень хорошо себя зарекомендовала, как методолгия несомненного улучшения качества кода. Казалост бы - вот она смерть тестирования, но постойте.

Существенно уменьшилось количсество блокер багов, так как код сам себч тестирует перед билдом. Но этого мало осталась куча критикалов и мажоров который пройдут на продакшен.

И будут проходить до тех пор пока не появится не предвзятый отдел тестирования.

Который не смотрит на програму как на идеальный код, я ж его писал откуда там баги?

Или продакт который впринципе не обучен искать баги, и который люит этот дезайн больше жены? Кто эму скажет тчо дизайн авно?

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

Что будет иначе - вспомните притчу про утку. 


  • 0

Senior QA/ Wix.com / qaacademy.net


#29 Vla8islav

Vla8islav

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

  • Members
  • Pip
  • 20 сообщений
  • ФИО:Пилипенко Владислав Валерьевич


Отправлено 13 апреля 2016 - 13:57

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


  • 0

#30 Vla8islav

Vla8islav

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

  • Members
  • Pip
  • 20 сообщений
  • ФИО:Пилипенко Владислав Валерьевич


Отправлено 13 апреля 2016 - 19:51

TDD или BDD очень хорошо себя зарекомендовала, как методолгия несомненного улучшения качества кода. Казалост бы - вот она смерть тестирования, но постойте. 

В первый раз прочитал, просто царапнуло глаз. Только теперь понял, что мне тут показалось не так. TDD и BDD - это методики тестирования. Наравне с другими техниками белой коробки.

О какой смерти тестирования может идти речь после внедрения инновационной методики тестирования в рабочий процесс?

А насчет предвзятости разработчиков - это недостаток, над устранением которого разработчику надо работать.


  • 0

#31 clipsa

clipsa

    Специалист

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


Отправлено 14 апреля 2016 - 09:02

 

TDD или BDD очень хорошо себя зарекомендовала, как методолгия несомненного улучшения качества кода. Казалост бы - вот она смерть тестирования, но постойте. 

В первый раз прочитал, просто царапнуло глаз. Только теперь понял, что мне тут показалось не так. TDD и BDD - это методики тестирования. Наравне с другими техниками белой коробки.

 
Это методологии разработки, а не тестирования:
 
TDD - Test Driven Development
BDD - Behaviour Driven Development

  • 0

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


#32 Vla8islav

Vla8islav

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

  • Members
  • Pip
  • 20 сообщений
  • ФИО:Пилипенко Владислав Валерьевич


Отправлено 14 апреля 2016 - 09:07

 

Это методологии разработки, а не тестирования:
 
TDD - Test Driven Development
BDD - Behaviour Driven Development

 

 

То есть разработка в себя тестирование не включает?


  • 0

#33 Little_CJIOH

Little_CJIOH

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

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 14 апреля 2016 - 09:20

 

 

Это методологии разработки, а не тестирования:
 
TDD - Test Driven Development
BDD - Behaviour Driven Development

 

 

То есть разработка в себя тестирование не включает?

 

Включает, но это методологии разработки. в которые определенным образом встроено тестирование выполняемое в определенном подходе.


  • 0

#34 DmitriyQA

DmitriyQA

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

  • Members
  • PipPipPip
  • 183 сообщений
  • ФИО:Коваленко Дмитрий Владимирович
  • Город:Tel Aviv

Отправлено 14 апреля 2016 - 11:05

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

Если интерестно вот вики. Без знание TDD сейчас деву на работу тяжело устроится. Кратко суть в том что девелопер сначали пишет юнит тест на свой модуль, а потом уже пишет сам рабочий код.

Тогда становится ясно что код готов когда тест будет пройден.

 

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


  • 0

Senior QA/ Wix.com / qaacademy.net


#35 Сергей

Сергей

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

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 14 апреля 2016 - 12:15

Вы забыли добавить существующие пользователи, т.к. новых просто может и не быть.


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#36 Vla8islav

Vla8islav

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

  • Members
  • Pip
  • 20 сообщений
  • ФИО:Пилипенко Владислав Валерьевич


Отправлено 14 апреля 2016 - 14:01

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

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

 

Включает, но это методологии разработки. в которые определенным образом встроено тестирование выполняемое в определенном подходе.

 

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


  • 0

#37 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 15 апреля 2016 - 11:41

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

 

Многие с вами не согласятся.

В вашем технологическом стеке на первом месте небось java стоит?


  • 0

#38 DmitriyQA

DmitriyQA

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

  • Members
  • PipPipPip
  • 183 сообщений
  • ФИО:Коваленко Дмитрий Владимирович
  • Город:Tel Aviv

Отправлено 15 апреля 2016 - 17:54

80 % JS и только 20 Scala и Java


  • 0

Senior QA/ Wix.com / qaacademy.net



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

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