Наблюдения о поиске сениор позиции в SFBA осень 2018

[Alexander Troyansky]

всё потому что, большинство считает, что целью тестирования является выявление багов. Поэтому и выхлоп такой.

мммм... а в чем же на самом деле цель тестирования?

Хороший вопрос... Если предположить, что целью тестирование является поиск багов, то логично и предолжить что мерой успеха такого тестирования было количество найденных багов. Но это ж несколько абсурдно. Этого как если качество и готовность автомобиля измерять по количеству образованной стружки в процессе изготовления.

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

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

[АццкоМото]

Хороший вопрос... Если предположить, что целью тестирование является поиск багов, то логично и предолжить что мерой успеха такого тестирования было количество найденных багов. Но это ж несколько абсурдно. Этого как если качество и готовность автомобиля измерять по количеству образованной стружки в процессе изготовления.

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

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

К сожалению, в выделенном болдом предположении не так много логики. Мера успеха это либо процент escaped bugs, т.е. найденных после релиза, либо их общее количество с какими-то весовыми коэффициентами в зависимости от их северити. Количество найденных багов всегда интересовало только в плане как раз второй цели тестирования - определения готовности продукта. Дело в том, что количество escaped defects можно достаточно точно статистически предсказать, когда продукт проходит через несколько фаз тестирования.

Но все же я настаиваю на том, что главная цель тестирования - поиск багов. Хотя по большому счету все это вопрос формулировок

[Вячеслав Викторович]

всё потому что, большинство считает, что целью тестирования является выявление багов. Поэтому и выхлоп такой.

мммм... а в чем же на самом деле цель тестирования?

Хороший вопрос... Если предположить, что целью тестирование является поиск багов, то логично и предолжить что мерой успеха такого тестирования было количество найденных багов. Но это ж несколько абсурдно. Этого как если качество и готовность автомобиля измерять по количеству образованной стружки в процессе изготовления.

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

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

Качество тестирования легко поддаётся количественной оценке: сколько багов обнаружено пользователями уже в продукции.

[Alexander Troyansky]

всё потому что, большинство считает, что целью тестирования является выявление багов. Поэтому и выхлоп такой.

мммм... а в чем же на самом деле цель тестирования?

Хороший вопрос... Если предположить, что целью тестирование является поиск багов, то логично и предолжить что мерой успеха такого тестирования было количество найденных багов. Но это ж несколько абсурдно. Этого как если качество и готовность автомобиля измерять по количеству образованной стружки в процессе изготовления.

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

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

Качество тестирования легко поддаётся количественной оценке: сколько багов обнаружено пользователями уже в продукции.

Мы говорим не про качество тестирование, а про качество продукта. Даж не очень строго говоря, это разные вещи.

Более того эта самая оценка качества происходит:
а) в течение длительного времени; и
б) мало коррелирует с количеством найденных багов до выпуска;

Поэтому ваше "легко" - оч спорное, но самое главное - это оценка происходит уже после выхода продукта, а определить готовность надо до.

[M. Ridcully]

Качество тестирования легко поддаётся количественной оценке: сколько багов обнаружено пользователями уже в продукции.

Не в каждом продукты пользователи вообще могут баг найти.

[Мальчик-Одуванчик]

я подозревал что у вас всё плохо, но не настолько же ж

Те уже далече. Надеюсь на полученный иммунитет против индоцепной реакции.

[Вячеслав Викторович]

Качество тестирования легко поддаётся количественной оценке: сколько багов обнаружено пользователями уже в продукции.

Не в каждом продукты пользователи вообще могут баг найти.

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

[Вячеслав Викторович]

всё потому что, большинство считает, что целью тестирования является выявление багов. Поэтому и выхлоп такой.

мммм... а в чем же на самом деле цель тестирования?

Хороший вопрос... Если предположить, что целью тестирование является поиск багов, то логично и предолжить что мерой успеха такого тестирования было количество найденных багов. Но это ж несколько абсурдно. Этого как если качество и готовность автомобиля измерять по количеству образованной стружки в процессе изготовления.

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

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

Качество тестирования легко поддаётся количественной оценке: сколько багов обнаружено пользователями уже в продукции.

Мы говорим не про качество тестирование, а про качество продукта. Даж не очень строго говоря, это разные вещи.

Более того эта самая оценка качества происходит:
а) в течение длительного времени; и
б) мало коррелирует с количеством найденных багов до выпуска;

Поэтому ваше "легко" - оч спорное, но самое главное - это оценка происходит уже после выхода продукта, а определить готовность надо до.

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

[АццкоМото]

мммм... а в чем же на самом деле цель тестирования?

Хороший вопрос... Если предположить, что целью тестирование является поиск багов, то логично и предолжить что мерой успеха такого тестирования было количество найденных багов. Но это ж несколько абсурдно. Этого как если качество и готовность автомобиля измерять по количеству образованной стружки в процессе изготовления.

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

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

Качество тестирования легко поддаётся количественной оценке: сколько багов обнаружено пользователями уже в продукции.

Мы говорим не про качество тестирование, а про качество продукта. Даж не очень строго говоря, это разные вещи.

Более того эта самая оценка качества происходит:
а) в течение длительного времени; и
б) мало коррелирует с количеством найденных багов до выпуска;

Поэтому ваше "легко" - оч спорное, но самое главное - это оценка происходит уже после выхода продукта, а определить готовность надо до.

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

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

[Alexander Troyansky]

чорд, я, наверное, уже русский подзабыл, но в данном конктесте:

...
качество тестирования и определяет качество продукта.

понимаю "определяет" == "гарантирует". Тестирование - это только одно звено в цепи производства продукта. Как оно может гарантировать качество? Качественное тестирование это только необходимое, а не достаточное, условие качественного продукта.

Со следующей формулировкой не спорю:

тестирование определяет (оценивает) качество продукта.

Ибо это - цель тестирования по определению by definition

[nyekimov]

но умереть от бага в коде никто не умрет.

Ох, всё не так очевидно. Вот работал я когда-то давно над AGPS стэком. Казалось бы, ну определятся координаты в гугломапсиках неверно, что с того? Раньше вообще без этого жили и ничего. А ведь тот же стэк используется при звонке в 911 и тут уже на кону может быть чья-то жизнь. Я уже не говорю про тот стэк, который позволяет оператору 911 (ну или ФСБ-шнику) запросить location request вне зависимости от желания пользователя и даже настроек. Это почти всегда связано с угрозой жизни.

И да, куча народу уже погибла от багов в коде.

Это сарказм? Если да, то один из моих стародавних проектов был связан с тем, что сгорел пожарный, не получив сообщения, что пора валить.

Есть фильм only the brave, на мой вкус очень стоящая драма, основанная на реальных событиях. Там погиб не один пожарный в один момент из-за того, что либо их не услышал человек, либо сигнал действительно не прошёл из-за переполнения канала lmr от Motorola.

[nyekimov]

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

Самое сложное это интеграционные тесты и тестирование ux, там без человека не обойтись.
И по моему мнению, если кто то не умеет нынче готовить тестирование на ентерпрайз крупных проектах, то это их проблемы. Это как не уметь применять шаблоны проектирования и писать велосипеды, такой спагетти код с мясными шариками. Как раз таки те, кто вообще не знают принципы dependency injection такое и выдают. И хз как это можно назвать адекватным. Но при этом я не фанат 100% покрытия кода юнит тестами.

А ещё тот же рефакторин по нормальному надо делать, когда код у тебя покрыт тестами. Но конечно я понимаю, что чаще менеджеры хотят фичи быстрее и поэтому приходится чем то жертвовать или разработчикам лень работать 8 часов в сутки )

[sp123]

titanic.jpg

[Poet77]

Вот, ждал что хотя бы кто-то напишет. Многих русских (но не всех конечно) подводит патологическое отвращение к индусам, китайцам, и прочим азиатам. А они между прочим все разные.

Согласен, да все разные, но % адекватных для каждой страны тоже разный.

По моему опыту например (очень грубо конечно)
среди китайцев ( тех что здесь недавно) тех с кем можно общатся ну % 20
среди индусов - тех с кем можно общатся % 30
среди корейцев - тех с кем можно общатся % 40
среди пхилиппинцев И малайзийцев - % 70-80 нормальных

Поэтому у меня отвращение только к индусам И катайцам ну И к вьетнамцам еще а к остальным азиатам - совсем нет.
Это подпадает под вашу теорию ?

[АццкоМото]

но умереть от бага в коде никто не умрет.

Ох, всё не так очевидно. Вот работал я когда-то давно над AGPS стэком. Казалось бы, ну определятся координаты в гугломапсиках неверно, что с того? Раньше вообще без этого жили и ничего. А ведь тот же стэк используется при звонке в 911 и тут уже на кону может быть чья-то жизнь. Я уже не говорю про тот стэк, который позволяет оператору 911 (ну или ФСБ-шнику) запросить location request вне зависимости от желания пользователя и даже настроек. Это почти всегда связано с угрозой жизни.

И да, куча народу уже погибла от багов в коде.

Это сарказм? Если да, то один из моих стародавних проектов был связан с тем, что сгорел пожарный, не получив сообщения, что пора валить.

Есть фильм only the brave, на мой вкус очень стоящая драма, основанная на реальных событиях. Там погиб не один пожарный в один момент из-за того, что либо их не услышал человек, либо сигнал действительно не прошёл из-за переполнения канала lmr от Motorola.

Думаю, это как раз тот проект, который я упоминал. Ибо таки да, Моторола. Таки да, пожарный. Но. Насколько я знаю, один. Насколько я знаю, причина не установлена.

Тем не менее, когда сгорел "всего" один человек и код тащемта не твой, это довольно больно. Хотя я думаю, что в том конкретном случае код отработал правильно. А дальше либо не услышал, либо было уже поздно. No matter what, это потенциальная цена ошибки — зажаренный человек.