И байтики, и поддерживаемый код, в общем, не самое важное. Об этом хорошо написано в последней книге дядюшки Боба - "Идеальная работа. Программирование без прикрас"
"Если посмотреть на количество молодых людей в программировании, напрашивается вывод, что это профессия для молодых. И возникает вопрос: «А где же люди в возрасте?» Мы здесь! Мы никуда не ушли. Просто изначально нас было не очень много.
Проблема в том, что нас недостаточно, чтобы обучать всех менее опытных коллег. На каждого программиста с 30-летним стажем приходится 63 программиста, которым требуется обучение, причем тридцать два из них — полные новички.
Отсюда состояние вечной неопытности, для выхода из которого попросту нет достаточного количества наставников. Одни и те же старые ошибки повторяются снова и снова "
Вы поймите меня правильно - подключение на ранних этапах - это хорошо, это правильно. Но, это не QA. Тестирование требований - это все-равно тестирование
И на уменьшение количества багов тестировщики повлиять не могут - поэтому все правильно у вас написано. Если разработчик генерит больше багов, чем фич - можно купить ему лицензию webstorm, вместо блокнота, которым он пользуется, можно отправить его на курсы, можно приставить ментора. Можно расстаться с этим разработчиком в крайнем случае
На что из перечисленного у вас в компании могут влиять тестировщики?
QA - это разработчики-сеньоры в команде, с соответствующими зарплатами, материально-техническим обеспечением и технологиями - внутренние требования к качеству. Или закон о защите прав потребителей, 152 ФЗ и т.д. - внешние требования к качеству
На эти требования инженеры-тестировщики практически не могут никак влиять
Спорить действительно нет смысла. Об всем этом написано и в силлабусе ISTQB, и в ISO 25000 / дублирующих ГОСТ'ах. Но, никто не любит читать первоисточники
Даже в Википедии специально акцентируется внимание на том, что Обеспечение качества не нужно путать с Управлением качеством и наоборот
Control - управление, management - ... менеджмент. Трудности перевода
Тестирование - часть QC. Просто кто-то когда-то решил, что тестирование это не круто, давайте будем называть тестировщика - QA. Называть, в общем, ничего, можно. Но, нужно понимать, что к обеспечению качества это не имеет отношения
Инженеры по... хм... обеспечению качества - не могут это самое качество обеспечить? У вас не возникает когнитивного диссонанса?
Может пора признать, что классическая схема, которую выдает поисковик на запрос "чем QA отличается от тестирования" - QA -> QC -> Testing - неактуальна?
QA (обеспечение качества) и QC (управление качеством) несомненно связанные понятия, пересекающиеся - но, не являются частью друг друга.
Дзайбацу стали кэйрэцу. "Большая четверка" существует и поныне. И "экономическое чудо" началось как раз с их восстановления, после развала оккупационной властью
Да, для этого необходимы специальные трудновыполнимые условия, чтобы все выше описанное превратилось в явь, но физиологически такое возможно
Конечно, физиологически теоретически все возможно. Эффект Джинса, например, когда вода в чайнике, поставленная на горячую плиту, не закипает, а превращается в лед. Возможно, но - маловероятно
При этом, в наборе жира при дефиците калорий как раз нет ничего удивительного. Аналогия - 5 человек на необитаемом острове, с запасом еды на 2-3 и отсутствием поступлений извне. Как бы ни были необходимы мышцы для выживания - самое логичное, что можно сделать - перевести одного человека в запасы пищи - иначе, умрут все. Без вариантов
Именно поэтому, даже профессиональные бодибилдеры и лифтеры не заморачиваются над какими-то сложными схемами по переводу жира в мыщцы. Цикл массонабора - увеличиваем массу и жира, и мышц - лучше конечно, мышц, но набранный жир тоже никакой трагедии из себя не представляет. И цикл сушки - когда мы сбрасываем массу, стараясь сохранить больше мышц.
А лифтеры-тяжеловесы (и тяжелоатлыты) так и вообще с сушкой не заморачиваются - и выглядят, как колобки. Профицит жира - профицит калорий - мышцы могут расти без ограничений - а значит и силовые показатели тоже
При этом, все, без исключения, профессионалы сидят на мощной химии - но, даже это не делает чуда в виде перевода килограмма жира в два килограмма мышц. Что, опять-таки соглашусь с автором - в принципе возможно, особенно с химией. Но, никому особо не нужно.
Хотя, нет, я конечно неправ. Это все очень нужно - кто же понесет свои деньги тренеру, который честно скажет, что на самом деле работают самые простые вещи - время и терпение :D
С сисадмином тоже все просто - работает или он, или система. Так что ваши домыслы мимо.
Насчет тестирования, немного копипасты:
— Кстати о качестве. Вот мы доподлинно знаем, что наши программисты пишут хороший код, — гордо сказала Молли, подходя к огромной красной надписи на дальней стене комнаты.
Надпись гласила: Ровно 14!
— Четырнадцать чего? — удивился мистер Томпкинс.
— Четырнадцать проверок кода без единой ошибки, — Молли прямо светилась от радости.
— Это впечатляет, — пробормотал мистер Томпкинс. — Я полагаю, мы вполне могли бы сэкономить те сорок два человекочаса, которые были затрачены на эти проверки кода, а на качестве продукта это никак бы не отразилось. Ведь ошибок все равно не было.
— Думаю, ты ошибаешься, — несколько раздраженно ответила Молли. — Именно благодаря проверке кода мы добились такого высокого качества работы.
— Только не благодаря последним четырнадцати, верно? Без них вполне можно было бы обойтись.
1, 2, 3, 4... - все в итоге своидтся к тому же. Нашли что-то, что повлияет на изменение продукта - продукт стал лучше. Нет - на прод пойдет тот же самый продукт, который туда пошел бы при полном отсутствии тестирования
Активностей в подпроцессе тестирования действительно много. Но, финальным продуктом все-равно является отчет о тестировании. И, если он не содержит в себе найденных багов - тестирование на качество не влияет никак.
А баги, найденные на более ранних этапах SDLC - это все-равно баги, просто ошибку допускает не разработчик в коде - до разработки дело еще не дошло - а, например, аналитик в требованиях
Как можно повысить качество продукта с помощью тестирования, не находя багов? С багом все понятно - его нашли, пофиксили, приложение стало лучше. А если в процессе тестирования ничего не нашли - каким образом оно станет качественнее? Оно каким было до тестирования, таким и осталось
Как минимум - тестировщик быстрее и лучше локализует проблему. Как максимум - пофиксит, доступными ему средствами. Если у вас это не так - могу только посочувствовать
А в чем же смысл тестирования, если не в поиске багов? Если задача дошла до тестирования - т.е. на предыдущих этапах мы решили что все ок - наибольшую пользу может принести только найденный баг. Это, если уж на то пошло - один из основных принципов тестирования
Сначала был Deep blue. А потом Вася со своей рыбкой. Так что все возможно. Может не в данном конкретном случае, а в принципе. А сейчас так и вообще нейросетки рулят - и рыбке до них далеко. И, возможно, и Гуглу с Яндексом в скором времени
Про то, что эти кейсы скорее для формы регистрации, а не авторизации уже написали. Добавлю, что как-то все простенько - без фантазии. Что еще можно проверить (Целесообразность во внимание брать не будем. Нам же нужно сломать форму регистрации, раз уж задача дошла до тестирования?)
Где происходит верификация? Фронт/бэк? Нужна проверка и там и там, но, обязательно она должна быть на бэке (фронту, как известно - верить нельзя)
Из предыдущего пункта сразу напрашивается проверка - а могу ли я вообще ввести в поле что-то некорректное? Если могу - могу ли отправить - или фронт как-то покажет мне ошибку - подсветит или напишет?
А если отправить миллион символов?
А если отправить картинку, видео, и т.д.?
Пустую строку проверили, а NULL, NaN, undefined, true, false?
SQL-инъекция?
Race condition - попробовать одновременно зарегистрировать двух пользователей с одинаковыми логинами?
А если такой логин уже есть в системе?
А можно ли использовать логин admin, administrator и т.д.?
Знающие люди говорят, что нет никакого остеохондроза шейного отдела позвоночника)) https://encyclopatia.ru/wiki/Остеохондроз
И байтики, и поддерживаемый код, в общем, не самое важное. Об этом хорошо написано в последней книге дядюшки Боба - "Идеальная работа. Программирование без прикрас"
"Если посмотреть на количество молодых людей в программировании, напрашивается вывод, что это профессия для молодых. И возникает вопрос: «А где же люди в возрасте?» Мы здесь! Мы никуда не ушли. Просто изначально нас было не очень много.
Проблема в том, что нас недостаточно, чтобы обучать всех менее опытных коллег. На каждого программиста с 30-летним стажем приходится 63 программиста, которым требуется обучение, причем тридцать два из них — полные новички.
Отсюда состояние вечной неопытности, для выхода из которого попросту нет достаточного количества наставников. Одни и те же старые ошибки повторяются снова и снова "
Вы поймите меня правильно - подключение на ранних этапах - это хорошо, это правильно. Но, это не QA. Тестирование требований - это все-равно тестирование
И на уменьшение количества багов тестировщики повлиять не могут - поэтому все правильно у вас написано. Если разработчик генерит больше багов, чем фич - можно купить ему лицензию webstorm, вместо блокнота, которым он пользуется, можно отправить его на курсы, можно приставить ментора. Можно расстаться с этим разработчиком в крайнем случае
На что из перечисленного у вас в компании могут влиять тестировщики?
QA - это разработчики-сеньоры в команде, с соответствующими зарплатами, материально-техническим обеспечением и технологиями - внутренние требования к качеству. Или закон о защите прав потребителей, 152 ФЗ и т.д. - внешние требования к качеству
На эти требования инженеры-тестировщики практически не могут никак влиять
Спорить действительно нет смысла. Об всем этом написано и в силлабусе ISTQB, и в ISO 25000 / дублирующих ГОСТ'ах. Но, никто не любит читать первоисточники
Даже в Википедии специально акцентируется внимание на том, что Обеспечение качества не нужно путать с Управлением качеством и наоборот
Control - управление, management - ... менеджмент. Трудности перевода
Тестирование - часть QC. Просто кто-то когда-то решил, что тестирование это не круто, давайте будем называть тестировщика - QA. Называть, в общем, ничего, можно. Но, нужно понимать, что к обеспечению качества это не имеет отношения
Инженеры по... хм... обеспечению качества - не могут это самое качество обеспечить? У вас не возникает когнитивного диссонанса?
Может пора признать, что классическая схема, которую выдает поисковик на запрос "чем QA отличается от тестирования" - QA -> QC -> Testing - неактуальна?
QA (обеспечение качества) и QC (управление качеством) несомненно связанные понятия, пересекающиеся - но, не являются частью друг друга.
Тестирование - это как раз часть QC
Дзайбацу стали кэйрэцу. "Большая четверка" существует и поныне. И "экономическое чудо" началось как раз с их восстановления, после развала оккупационной властью
Печально, когда ты на проекте один. Да ещё и джун. Четвертое правило воронки в действии
Конечно,
физиологическитеоретически все возможно. Эффект Джинса, например, когда вода в чайнике, поставленная на горячую плиту, не закипает, а превращается в лед. Возможно, но - маловероятноПри этом, в наборе жира при дефиците калорий как раз нет ничего удивительного. Аналогия - 5 человек на необитаемом острове, с запасом еды на 2-3 и отсутствием поступлений извне. Как бы ни были необходимы мышцы для выживания - самое логичное, что можно сделать - перевести одного человека в запасы пищи - иначе, умрут все. Без вариантов
Именно поэтому, даже профессиональные бодибилдеры и лифтеры не заморачиваются над какими-то сложными схемами по переводу жира в мыщцы. Цикл массонабора - увеличиваем массу и жира, и мышц - лучше конечно, мышц, но набранный жир тоже никакой трагедии из себя не представляет. И цикл сушки - когда мы сбрасываем массу, стараясь сохранить больше мышц.
А лифтеры-тяжеловесы (и тяжелоатлыты) так и вообще с сушкой не заморачиваются - и выглядят, как колобки. Профицит жира - профицит калорий - мышцы могут расти без ограничений - а значит и силовые показатели тоже
При этом, все, без исключения, профессионалы сидят на мощной химии - но, даже это не делает чуда в виде перевода килограмма жира в два килограмма мышц. Что, опять-таки соглашусь с автором - в принципе возможно, особенно с химией. Но, никому особо не нужно.
Хотя, нет, я конечно неправ. Это все очень нужно - кто же понесет свои деньги тренеру, который честно скажет, что на самом деле работают самые простые вещи - время и терпение :D
С сисадмином тоже все просто - работает или он, или система. Так что ваши домыслы мимо.
Насчет тестирования, немного копипасты:
— Кстати о качестве. Вот мы доподлинно знаем, что наши программисты пишут хороший код, — гордо сказала Молли, подходя к огромной красной надписи на дальней стене комнаты.
Надпись гласила: Ровно 14!
— Четырнадцать чего? — удивился мистер Томпкинс.
— Четырнадцать проверок кода без единой ошибки, — Молли прямо светилась от радости.
— Это впечатляет, — пробормотал мистер Томпкинс. — Я полагаю, мы вполне могли бы сэкономить те сорок два человекочаса, которые были затрачены на эти проверки кода, а на качестве продукта это никак бы не отразилось. Ведь ошибок все равно не было.
— Думаю, ты ошибаешься, — несколько раздраженно ответила Молли. — Именно благодаря проверке кода мы добились такого высокого качества работы.
— Только не благодаря последним четырнадцати, верно? Без них вполне можно было бы обойтись.
1, 2, 3, 4... - все в итоге своидтся к тому же. Нашли что-то, что повлияет на изменение продукта - продукт стал лучше. Нет - на прод пойдет тот же самый продукт, который туда пошел бы при полном отсутствии тестирования
Активностей в подпроцессе тестирования действительно много. Но, финальным продуктом все-равно является отчет о тестировании. И, если он не содержит в себе найденных багов - тестирование на качество не влияет никак.
А баги, найденные на более ранних этапах SDLC - это все-равно баги, просто ошибку допускает не разработчик в коде - до разработки дело еще не дошло - а, например, аналитик в требованиях
Как можно повысить качество продукта с помощью тестирования, не находя багов? С багом все понятно - его нашли, пофиксили, приложение стало лучше. А если в процессе тестирования ничего не нашли - каким образом оно станет качественнее? Оно каким было до тестирования, таким и осталось
Как минимум - тестировщик быстрее и лучше локализует проблему. Как максимум - пофиксит, доступными ему средствами. Если у вас это не так - могу только посочувствовать
А в чем же смысл тестирования, если не в поиске багов? Если задача дошла до тестирования - т.е. на предыдущих этапах мы решили что все ок - наибольшую пользу может принести только найденный баг. Это, если уж на то пошло - один из основных принципов тестирования
Сначала был Deep blue. А потом Вася со своей рыбкой. Так что все возможно. Может не в данном конкретном случае, а в принципе. А сейчас так и вообще нейросетки рулят - и рыбке до них далеко. И, возможно, и Гуглу с Яндексом в скором времени
Тест-кейсы в чек-листе? Конечно, чек-листы бывают разной детализации, но набор тест-кейсов называется тест-сьют
Ввод без клавиатуры? Прекрасный кейс. Часто забывают про ctrl+c - ctrl+v
Дело не в фанатизме, а в профессионализме
Про то, что эти кейсы скорее для формы регистрации, а не авторизации уже написали. Добавлю, что как-то все простенько - без фантазии. Что еще можно проверить (Целесообразность во внимание брать не будем. Нам же нужно сломать форму регистрации, раз уж задача дошла до тестирования?)
Где происходит верификация? Фронт/бэк? Нужна проверка и там и там, но, обязательно она должна быть на бэке (фронту, как известно - верить нельзя)
Из предыдущего пункта сразу напрашивается проверка - а могу ли я вообще ввести в поле что-то некорректное? Если могу - могу ли отправить - или фронт как-то покажет мне ошибку - подсветит или напишет?
А если отправить миллион символов?
А если отправить картинку, видео, и т.д.?
Пустую строку проверили, а NULL, NaN, undefined, true, false?
SQL-инъекция?
Race condition - попробовать одновременно зарегистрировать двух пользователей с одинаковыми логинами?
А если такой логин уже есть в системе?
А можно ли использовать логин admin, administrator и т.д.?
Et cetera
А деньги?
Какие деньги?
Ну... деньги
Ааа, деньги... Ах, я собака беспамятная...