Наблюдения о поиске сениор позиции в 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, это потенциальная цена ошибки — зажаренный человек.

[АццкоМото]

Почему то никто не упомянул, что тесты могут ( и скорее должны) быть спекой.

Может быть, потому что спеки и тесты Это разные вещи?

Вот смотри, есть модуль который... Ну, скажем, возводит целое в квадрат. Туда пихаешь 2, получаешь 4. Пихаешь 12, получаешь 144.

Теперь вопрос, какие тесты могут стать "спекой"?

[Pantigalt]

Ну так живые люди (пользователи) и потестируют.

На свой страх и риск?

[rtogan]

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

Ох, всё не так очевидно. Вот работал я когда-то давно над AGPS стэком. Казалось бы, ну определятся координаты в гугломапсиках неверно, что с того? Раньше вообще без этого жили и ничего. А ведь тот же стэк используется при звонке в 911 и тут уже на кону может быть чья-то жизнь...

А всё потому что это использование при звонке в 911 - это нарушение соглашения по использованию Google Maps, если конечно Гугл явно такое использование не разрешил. Разрешал Гугл использовать или без разрешения прикрутили гугломапсик?

Гугломапсик тут вообще не при чем. Вы можете купить даже не смартфон, не иметь мапсики, отключить gps. В любой момент оператор может его включить и получить вашу локацию. Это называется network initiated location request, NILR. Наверное есть законы, регулирующие использование этого дела. Но никто не знает, как оно в реале. Почти уверен, что всякие ФСБ могут творить что хотят используя СОРМ. Вполне возможно, что ФБР это делает тоже.

"Почти уверен, что всякие ФСБ могут творить что хотят используя СОРМ. Вполне возможно, что ФБР это делает тоже."

Наивное незнание страны, в которой живете Вы ФСБ и ФБР - переставили местами. Россия в этом отношении лишь плетется за лидером

[SteveQA]

Тут народ мечтает о каких-то 200-300К нищебродских заработках для сеньор девелоперов.
А вот девушка после окончания русскоязычной школы тестирования в Калифорнии говорит о 500-600К для автотестировщиков. Вот это уже реальные заработки!

[AXA]

И вы говорите! (с) Анекдот . У девушки Аспиратура по математике за плечами и она уже девелопер. Не для всех это.

[nyekimov]

Почему то никто не упомянул, что тесты могут ( и скорее должны) быть спекой.

Может быть, потому что спеки и тесты Это разные вещи?

Вот смотри, есть модуль который... Ну, скажем, возводит целое в квадрат. Туда пихаешь 2, получаешь 4. Пихаешь 12, получаешь 144.

Теперь вопрос, какие тесты могут стать "спекой"?

Тот самый тест:
Describe(“test power module”)
Context(“square operation”)
Context(“when sending 2”)
It(“should be equal to 4”)
Expect(bla(2)) == 4

Ты открываешь тест на модуль и видишь перечисление всех поддерживаемых операций и самое главное условий. Чем не спека, условно говоря, хотя в tdd это так или иначе спекой и называют.

Самое сложное, это прийти к такому формату, чтобы было приятно читать.

[nyekimov]

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

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

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

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

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

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

Не знаю то не то, но глянь трейлер на only the brave. Если сама тематика тебе по душе, то фильм хорош.
Ну а по теме бага, мне кажется он не один. И из тех, который сложно доказывается - подвело или оборудование или человек. В фильме точно Моторола и не один пожарный и все произошло скорей всего после твоего ухода с компании, и твой случай скорей всего просто отдельный произошедший до мною рассказанного.

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

[АццкоМото]

Почему то никто не упомянул, что тесты могут ( и скорее должны) быть спекой.

Может быть, потому что спеки и тесты Это разные вещи?

Вот смотри, есть модуль который... Ну, скажем, возводит целое в квадрат. Туда пихаешь 2, получаешь 4. Пихаешь 12, получаешь 144.

Теперь вопрос, какие тесты могут стать "спекой"?

Тот самый тест:
Describe(“test power module”)
Context(“square operation”)
Context(“when sending 2”)
It(“should be equal to 4”)
Expect(bla(2)) == 4

Ты открываешь тест на модуль и видишь перечисление всех поддерживаемых операций и самое главное условий. Чем не спека, условно говоря, хотя в tdd это так или иначе спекой и называют.

Самое сложное, это прийти к такому формату, чтобы было приятно читать.

Как удачно сложилось. Если рассматривать этот тест как спеку, что должен делать код? Возводить в квадрат? Умножать на 2? Прибавлять 2? Возвращать 4 no matter what? ЧЕТЫРЕ концептуально разные имплементации вполне соответствуют тесту и проходят его на ура

Ещё раз: тесты это тесты, а спеки это спеки. Если бы это было не так, не было бы двух разных слов

[АццкоМото]

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

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

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

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

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

Не знаю то не то, но глянь трейлер на only the brave. Если сама тематика тебе по душе, то фильм хорош.
Ну а по теме бага, мне кажется он не один. И из тех, который сложно доказывается - подвело или оборудование или человек. В фильме точно Моторола и не один пожарный и все произошло скорей всего после твоего ухода с компании, и твой случай скорей всего просто отдельный произошедший до мною рассказанного.

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

Не, фильм, конечно, совсем про другое — он про пожар 2013 года, а я говорил про проект навскидку примерно 2000 года.

Что до автопилота, он и так массовый. И безопасней, чем человек. И жизней сколько спас. Но и люди гибли из-за багов.

[АццкоМото]

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

Ох, всё не так очевидно. Вот работал я когда-то давно над AGPS стэком. Казалось бы, ну определятся координаты в гугломапсиках неверно, что с того? Раньше вообще без этого жили и ничего. А ведь тот же стэк используется при звонке в 911 и тут уже на кону может быть чья-то жизнь...

А всё потому что это использование при звонке в 911 - это нарушение соглашения по использованию Google Maps, если конечно Гугл явно такое использование не разрешил. Разрешал Гугл использовать или без разрешения прикрутили гугломапсик?

Гугломапсик тут вообще не при чем. Вы можете купить даже не смартфон, не иметь мапсики, отключить gps. В любой момент оператор может его включить и получить вашу локацию. Это называется network initiated location request, NILR. Наверное есть законы, регулирующие использование этого дела. Но никто не знает, как оно в реале. Почти уверен, что всякие ФСБ могут творить что хотят используя СОРМ. Вполне возможно, что ФБР это делает тоже.

"Почти уверен, что всякие ФСБ могут творить что хотят используя СОРМ. Вполне возможно, что ФБР это делает тоже."

Наивное незнание страны, в которой живете Вы ФСБ и ФБР - переставили местами. Россия в этом отношении лишь плетется за лидером

Вы не допускаете, что это вы наивно не знаете страну?