Состав, соответствие госту и качество игнгридиентов предполагается определять на вкус? Даже при наличии специализированной лаборатории - верифицировать готовый продукт - это плохая практика. Верификация продукта - а также его ингридиентов - производится на более ранних этапах производства, специально обученными людьми - технологами-пищевиками.
Я, как конечный потребитель, могу, а самое главное хочу - чтобы продукт хорошо выглядел, был в удобной и функциональной упаковке, был вкусным и питательным - т.е. то, что мы называем валидацией.
Чего я точно не хочу - беспокоиться, что вместо мяса в продукт положили сою (если пельмени не соевые, конечно) или свинину - в халяльный продукт. Что продукт содержит вредные вещества выше нормы или что он был произведен с нарушением технологического процесса. Все это мне должен обеспечить технолог на этапе верификации.
Так же, как конечный потредитель - я не хочу варить пельмени в чайнике, ломать на мелкие части, варить час или больше и другие интересные вещи - ну сделали вы такой тест - и что? Какой баг нашли или предполагали найти? Какую информацию о качестве планировали получить?
В общем, выглядит все как-то трешовенько. Продукт для тестирования выбран неудачно, тестировщик не вполне понимает, что он делает.
Да, кстати, категория Б - от 60 до 80%, а не "не менее 80%" и мышечных волокон, а не "мяса" - это важно, мясо состоит не только из мышечных волокон. С документацией тоже надо уметь работать
Есть такое понятие - вариативность процесса. Вариативность процесса разработки ПО очень высока. Одну и ту же задачу разработчик может сделать и за один час - и за десять. И это нормально - если время находится в пределах вариативности процесса. При этом, вариации бывают системными и несистемными. Не меняя процесса - можно как-то бороться с несистемными вариациями. Если же пробовать изменить системную вариацию, не меняя процесса - т.е. несистемными методами - результат будет только хуже. Это наглядно демонстрирует эксперимент Деминга "Воронка и мишень" - https://advanced-quality-tools.ru/deming-funnelexperiment.html
А чем API-тесты - не E2E? Актором вполне может выступать не живой человек, а какой-то сервис. В том числе и фронт приложения. Я бы даже сказал, что API-тесты формально - более E2E, чем UI-автотесты - потому что живой человек видит кнопку на которую нужно кликнуть и текст, который вернул сервер, а не их css-селекторы
О том, что главная задача - найти нужного человека - Демарко с Листером писали в Дедлайне 30 лет назад. Только, причем здесь харды соискателя? Я уверен, что вы возьмёте на работу человека с никакими хардами, если будете уверены в том, что этот человек вам подходит
Никто не говорит, что на работу нужно брать без собеседования. Но, мы, вроде как, обсуждаем особенности технического собеседования - цель которого как раз и заключается в определении хардов соискателя
Ваша колокольня в том, что решаете вы. Решаете чисто субъективно. Кандидат может ответить правильно на 147%, но, если вы по какой-то причине считаете иначе - ошиблись, перепутали, мало ли - кандидат не пройдет. Только не принимайте ВЫ - на свой счет - я говорю обобщенно. Конкретно у вас все может быть идеально. Но, проблема, которую подчветил ТС - есть
Кажется, что критериев "нравится - не нравится" не должно быть на техническом собеседованнии. Да, вердикт может быть таким - классный специалист, но первоклассный #удак, работать вместе не сможем. Но, техническое собеседование отвечает именно за - "классный специалист"
Потому что собеседующий "знает лучше". Проблема в том, что нет критериев - суждения полностью субъективны. Сертификации, дипломы, образования - не панация, да - но там есть критерии. Которых нет, еще раз уточню - на техническом собеседовании
Миф в том, что каждый волен судить со своей колокольни. Знание многопоточки может отличаться у кандидата от вашего знания, причем в лучшую сторону - но, это не поможет ему пройти собеседование. Да и вообще - какое-либо знание может быть неважным - человек может просто вам не понравиться - вот там ниже вообще собеседование (техническое!!!) со свиданием сравнивают
Одних вы можете не взять за то, что у них сертификата нет. Других - за то, что деревья вращать не умеют. Третьих - за то, что они чего-то там не зазубрили. Четвертых - за что-то еще. Просто потому что вы так решили и вы это можете. Кажется автор о том и пишет, что техническое собеседование - это миф
Демарко и Листер писали о том, что оценка задач снижает производительность команды в Человеческом факторе. Книга вышла в 1987, данные для выводов были получены ещё раньше - задолго до любого аджайла
>Что мешает проверить в первый раз и потом после окончательных правок?
Например то, что основной сценарий могут сломать во время правок
>а потом придет менеджер и скажет "да пофиг на эту ошибку, надо срочно накатывать"
тогда тестирование здесь лишнее. Пусть катят :)
"Создание уверенностей в работоспособности ПО", как артефакт тестирования - это миф. У тестирования может быть только один артефакт - найденный баг, что кстати, написано в основных принципах
"В рамках должностных обязанностей". А то, мало ли какой Иван Дулин там у вас в начальниках...
Состав, соответствие госту и качество игнгридиентов предполагается определять на вкус? Даже при наличии специализированной лаборатории - верифицировать готовый продукт - это плохая практика. Верификация продукта - а также его ингридиентов - производится на более ранних этапах производства, специально обученными людьми - технологами-пищевиками.
Я, как конечный потребитель, могу, а самое главное хочу - чтобы продукт хорошо выглядел, был в удобной и функциональной упаковке, был вкусным и питательным - т.е. то, что мы называем валидацией.
Чего я точно не хочу - беспокоиться, что вместо мяса в продукт положили сою (если пельмени не соевые, конечно) или свинину - в халяльный продукт. Что продукт содержит вредные вещества выше нормы или что он был произведен с нарушением технологического процесса. Все это мне должен обеспечить технолог на этапе верификации.
Так же, как конечный потредитель - я не хочу варить пельмени в чайнике, ломать на мелкие части, варить час или больше и другие интересные вещи - ну сделали вы такой тест - и что? Какой баг нашли или предполагали найти? Какую информацию о качестве планировали получить?
В общем, выглядит все как-то трешовенько. Продукт для тестирования выбран неудачно, тестировщик не вполне понимает, что он делает.
Да, кстати, категория Б - от 60 до 80%, а не "не менее 80%" и мышечных волокон, а не "мяса" - это важно, мясо состоит не только из мышечных волокон. С документацией тоже надо уметь работать
Есть такое понятие - вариативность процесса. Вариативность процесса разработки ПО очень высока. Одну и ту же задачу разработчик может сделать и за один час - и за десять. И это нормально - если время находится в пределах вариативности процесса. При этом, вариации бывают системными и несистемными. Не меняя процесса - можно как-то бороться с несистемными вариациями. Если же пробовать изменить системную вариацию, не меняя процесса - т.е. несистемными методами - результат будет только хуже. Это наглядно демонстрирует эксперимент Деминга "Воронка и мишень" - https://advanced-quality-tools.ru/deming-funnelexperiment.html
Увы, это настолько правда, что даже в Википедии в статью о геометрии Лобачевского пришлось добавить раздел - Мифы))
Параллельные прямые не пересекаются во всех геометриях))
А чем API-тесты - не E2E? Актором вполне может выступать не живой человек, а какой-то сервис. В том числе и фронт приложения. Я бы даже сказал, что API-тесты формально - более E2E, чем UI-автотесты - потому что живой человек видит кнопку на которую нужно кликнуть и текст, который вернул сервер, а не их css-селекторы
О том, что главная задача - найти нужного человека - Демарко с Листером писали в Дедлайне 30 лет назад. Только, причем здесь харды соискателя? Я уверен, что вы возьмёте на работу человека с никакими хардами, если будете уверены в том, что этот человек вам подходит
Уточнения абсолютно излишни - все так и есть. Об этой проблеме и пишет ТС - стандартов нет, вместо них - предпочтения.
Никто не говорит, что на работу нужно брать без собеседования. Но, мы, вроде как, обсуждаем особенности технического собеседования - цель которого как раз и заключается в определении хардов соискателя
Нравиться всем абсолютно не обязательно. Но, как это - нравлюсь я кому-то или нет - влияет на мои навыки, как специалиста?
Давайте немного развернем вашу мысль. Зачем нужны стандарты, если кто-то людям аппендициты вырезает, а кто-то высоковольтные линии тянет
Другой собеседующий скажет ровно наоборот. О чем и речь - стандартов оценки нет, есть личные предпочтения
Ваша колокольня в том, что решаете вы. Решаете чисто субъективно. Кандидат может ответить правильно на 147%, но, если вы по какой-то причине считаете иначе - ошиблись, перепутали, мало ли - кандидат не пройдет. Только не принимайте ВЫ - на свой счет - я говорю обобщенно. Конкретно у вас все может быть идеально. Но, проблема, которую подчветил ТС - есть
Кажется, что критериев "нравится - не нравится" не должно быть на техническом собеседованнии. Да, вердикт может быть таким - классный специалист, но первоклассный #удак, работать вместе не сможем. Но, техническое собеседование отвечает именно за - "классный специалист"
Потому что собеседующий "знает лучше". Проблема в том, что нет критериев - суждения полностью субъективны. Сертификации, дипломы, образования - не панация, да - но там есть критерии. Которых нет, еще раз уточню - на техническом собеседовании
Миф в том, что каждый волен судить со своей колокольни. Знание многопоточки может отличаться у кандидата от вашего знания, причем в лучшую сторону - но, это не поможет ему пройти собеседование. Да и вообще - какое-либо знание может быть неважным - человек может просто вам не понравиться - вот там ниже вообще собеседование (техническое!!!) со свиданием сравнивают
Вот об этом и речь - зачем мешать все это 3, 4, 5... - в "техническое собеседование"?
Одних вы можете не взять за то, что у них сертификата нет. Других - за то, что деревья вращать не умеют. Третьих - за то, что они чего-то там не зазубрили. Четвертых - за что-то еще. Просто потому что вы так решили и вы это можете. Кажется автор о том и пишет, что техническое собеседование - это миф
Демарко и Листер писали о том, что оценка задач снижает производительность команды в Человеческом факторе. Книга вышла в 1987, данные для выводов были получены ещё раньше - задолго до любого аджайла
>Что мешает проверить в первый раз и потом после окончательных правок?
Например то, что основной сценарий могут сломать во время правок
>а потом придет менеджер и скажет "да пофиг на эту ошибку, надо срочно накатывать"
тогда тестирование здесь лишнее. Пусть катят :)
"Создание уверенностей в работоспособности ПО", как артефакт тестирования - это миф. У тестирования может быть только один артефакт - найденный баг, что кстати, написано в основных принципах