"Введите в практику подготовку и переподготовку кадров" У.Э.Деминг
Что касается тех или не тех печенек - на работе я пишу бэк на PHP, но, всегда мечтал писать приложения под iOS - чем я и занимаюсь в свободное от работы время
Т.е. если работодателю нужно прокачать сотрудника в какой-то технологии, нужной работодателю - не вопрос, но за ресурсы работодателя (время, деньги, курсы, менторы...). В свое свободное, неоплачиваемое время я буду "развиваться" так как хочу я - изучать свифт, играть на губной гармошке или лежать на диване (тоже не самый плохой вариант - можно вспомнить анекдот про Резерфорда и его лаборанта, который все время проводил на работе - Резерфорда заинтересовало, когда же молодой человек думает, если он постоянно работает)
Диалог прям, как по нотам - "Цель" Голдратта вы конечно не читали))
Не имеющий грейда? Мне нужно 1000 упаковок в час, а ваш "станок" делает всего 100...
Не имеющий интеллекта? Для одной детали нужна упаковка вдоль, а для другой - поперек и идут они вперемешку...
Не имеющий опыта? Странно, но после месяца работы без обслуживания станок начал выдавать 50% брака))
Можно продолжить - то, что станок стоит денег, и если мне нужны 10 упаковок в день - он просто нерентабелен. Что его надо обслуживать и, зачастую, его обслуживание стоит дороже ручной упаковки и т.д.
Ваша проблема (не считая той, что вы почему то не смогли прочитать первые 10 страниц первого силлабуса istqb - и назначили тестировщегом человека, который занимается только выполнением тестов. Все остальные этапы тестирования - планирование, анализ, дизайн, реализация - вы почему-то решили отнести к QC)) - в том, что вы начали за здравие - QA это не то, чем в основном занимается тестировщик (и то, QA и QC пересекаются - вы же их изобразили даже не соприкасающимися), а кончили за упокой - у вас QA engineer - это тестировщег на стероидах - автоматизация, ci/cd и все такое... Т.е. ничего нового - это заблуждение из каждого утюга льется
Качество, в общем смысле ISO 9000-2015, откуда вы взяли ваши определения (может вы об этом и не знаете, но, они именно оттуда) - это не про IT, ПО редко выступает самоцелью - конечный пользователь, который платить деньги, вообще может ничего об этом не знать... У вас могуь быть и автотесты и ci/cd, и багов может вообще не быть - но, деньги пользователь почему-то несёт не вам....
О, харьковские пейзане подъехали)) Ну, как там клубника демократии? Колосится?
Вы, мсье, если уж взялись википедию цитировать - цитируйте полностью
"This defect prevention aspect of quality assurance differs from the defect detection aspect of quality control and has been referred to as a shift left since it focuses on quality efforts earlier in product development and production (i.e., a shift to the left of a linear process diagram reading left to right) and on avoiding defects in the first place rather than correcting them after the fact"
Звучит очень сомнительно, чтобы тестировщик занимался процессами найма и развития разработчиков. Да и к чему, если для этого есть HR?
И, да, никому не нужно, чтобы все его сотрудники "развивались" - нужно, чтобы они выполняли свою непосредственную работу как можно лучше. Если для этого сотрудника нужно "развить" - это хорошо, это правильно. А отвлекать человека от работы, непонятными активностями - это совсем неправильно
Да, эта аббревиатура уже настолько навязала в зубах, что уже начали придумывать всякие эвфемизмы для неё - например quality assistance - "содействие в обеспечении качества"))
Поэтому, вопрос действительно важный, но... Не докрутили вы, ребят. Даже, совсем наоборот - пошли в какие-то дебри...
Самый простой пример - сеньор Вася и джун Леша - кто из них сделает более качественно? Если не лезть во всякую софистику - лучше всегда сделает сеньор. Без всяких DoR, ci, cd и всего остального - просто сделает лучше. Нет, со всем этим он сделает ещё лучше - но, это вторично
Поэтому первый вопрос, который мы должны решить - не как внедрить ci/cd или в линтер чего нового запихнуть - а как сделать так, чтобы Леша стал Васей. Если есть деньги и нет времени - Лёшу можно уволить и нанять ещё одного Васю - и, да, это будет самым что ни на есть обеспечением качества. Или, Лёшу можно научить - на рабочем месте, что всегда и ставил во главу угла "папа" качества в его современном понимании У.Э.Деминг
Или, ещё один пример - с другой стороны - 152фз о ПД - ну вот вообще никак на него не может повлиять на qa, ни qc, ни тестировщик - но, тем не менее этот закон есть и он-таки обеспечивает качество
А ещё есть потребители, которым абсолютно плевать и на линтеры, и на тестирование - они выставляют свои требования к качеству и, в зависимости от них, пользуются тем или другим приложением. И опять, эти внешние требования обеспечивают качество... А вот как вы этими требованиями будете управлять (контролировать их выполнение) - это уже другой вопрос - здесь и пригодится все, что бы знаете и о DoR, и о DoD, и о приемочных критериях...
В сферической геометрии "прямой" считается большой круг - проходящий через две диаметрально противоположные точки. Вполне себе "очевидно", что нельзя нарисовать два больших круга, не имеющих общих точек
Минимум две - это аксиома. Из этой аксиомы легко получается бесконечность - все те прямые, которые лежат между указанными двуми
Что касается сферы - там вообще нет параллельных прямых. Правда, сферическая геометрия не относится к абсолютным - через диаметрально противоположные точки можно провести более одной прямой
Про определение полностью соглашусь - только немного дополню - параллельные должны лежать в одной плоскости (любой "плоскости" - Евклида, сфере, седловой поверхности...). Не имеют общих точек и скрещивающиеся прямые
Все так, все так. Из 1000 кандидатов на место водителя - 99% отсеять по резюме и получить в итоге абсолютно нерелевантных кандидатов - это надо очень постараться
А тех, что таки прошли отбор - нужно непременно собеседовать в несколько этапов вопросами по теоретической механике, термодинамике и остальному сопромату. Просто посадить кандидата за руль или дать колесо перебортовать это слишком не по фаанговски
Так же обязательно требовать от кандидата навыков экстремального вождения или минимум кмс по автоспорту. Зачем? Конечно же затем чтобы булочки из пекарни возить на старом каблучке, который разучился ездить быстрее 60 км/ч ещё 30 лет назад
Все гораздо проще с точки зрения глубинных знаний - любая научная теория должна быть фальсифицируемой. Если спроецировать требование фальсифицируемости на разработку ПО - мы получим такой атрибут качества, как тестируемость
Ну и далее по аналогии - чтобы сделать заключение об истинности какой-либо теории ее не "доказывают" - не проверяют по "требованиям", ее пытаются фальсифицировать - т.е. найти в ней "баги" - противоречия. Если этого сделать не получается - теория с высокой вероятностью является истинной
В общем-то, это конечно забавно "искать баги" мимо требований. Как минимум мы просто не будем знать что является багом, а что нет. Где-то кнопка должна быть красной, а где-то зелёной - и это нормально. Но, если вместо красной кнопки будет зелёная - это баг. Но, без требований мы никак не можем об этом знать
А если сказать, что ошибка, дефект (баг) и сбой - это не одно и то же ....
"Введите в практику подготовку и переподготовку кадров" У.Э.Деминг
Что касается тех или не тех печенек - на работе я пишу бэк на PHP, но, всегда мечтал писать приложения под iOS - чем я и занимаюсь в свободное от работы время
Т.е. если работодателю нужно прокачать сотрудника в какой-то технологии, нужной работодателю - не вопрос, но за ресурсы работодателя (время, деньги, курсы, менторы...). В свое свободное, неоплачиваемое время я буду "развиваться" так как хочу я - изучать свифт, играть на губной гармошке или лежать на диване (тоже не самый плохой вариант - можно вспомнить анекдот про Резерфорда и его лаборанта, который все время проводил на работе - Резерфорда заинтересовало, когда же молодой человек думает, если он постоянно работает)
Диалог прям, как по нотам - "Цель" Голдратта вы конечно не читали))
Не имеющий грейда? Мне нужно 1000 упаковок в час, а ваш "станок" делает всего 100...
Не имеющий интеллекта? Для одной детали нужна упаковка вдоль, а для другой - поперек и идут они вперемешку...
Не имеющий опыта? Странно, но после месяца работы без обслуживания станок начал выдавать 50% брака))
Можно продолжить - то, что станок стоит денег, и если мне нужны 10 упаковок в день - он просто нерентабелен. Что его надо обслуживать и, зачастую, его обслуживание стоит дороже ручной упаковки и т.д.
Ваша проблема (не считая той, что вы почему то не смогли прочитать первые 10 страниц первого силлабуса istqb - и назначили тестировщегом человека, который занимается только выполнением тестов. Все остальные этапы тестирования - планирование, анализ, дизайн, реализация - вы почему-то решили отнести к QC)) - в том, что вы начали за здравие - QA это не то, чем в основном занимается тестировщик (и то, QA и QC пересекаются - вы же их изобразили даже не соприкасающимися), а кончили за упокой - у вас QA engineer - это тестировщег на стероидах - автоматизация, ci/cd и все такое... Т.е. ничего нового - это заблуждение из каждого утюга льется
Качество, в общем смысле ISO 9000-2015, откуда вы взяли ваши определения (может вы об этом и не знаете, но, они именно оттуда) - это не про IT, ПО редко выступает самоцелью - конечный пользователь, который платить деньги, вообще может ничего об этом не знать... У вас могуь быть и автотесты и ci/cd, и багов может вообще не быть - но, деньги пользователь почему-то несёт не вам....
Как бы там ни было - следуя одному и тому же техпроцессу, слесарь 6 разряда делает меньше брака, чем слесарь 4 🤷
Читайте классику
Деминг "Выход из кризиса". Если покажется сложным - начать можно с книги Генри Нива "Пространство доктора Деминга"
Элияху Голдратт - "Цель - 1, 2, 3", "Критическая цепь"
Листер и Демарко - "Дедлайн", "Человеческий фактор", "Вальсируя с медведями", "Балдеющие от адреналина"...
О, харьковские пейзане подъехали)) Ну, как там клубника демократии? Колосится?
Вы, мсье, если уж взялись википедию цитировать - цитируйте полностью
"This defect prevention aspect of quality assurance differs from the defect detection aspect of quality control and has been referred to as a shift left since it focuses on quality efforts earlier in product development and production (i.e., a shift to the left of a linear process diagram reading left to right) and on avoiding defects in the first place rather than correcting them after the fact"
Звучит очень сомнительно, чтобы тестировщик занимался процессами найма и развития разработчиков. Да и к чему, если для этого есть HR?
И, да, никому не нужно, чтобы все его сотрудники "развивались" - нужно, чтобы они выполняли свою непосредственную работу как можно лучше. Если для этого сотрудника нужно "развить" - это хорошо, это правильно. А отвлекать человека от работы, непонятными активностями - это совсем неправильно
Да, эта аббревиатура уже настолько навязала в зубах, что уже начали придумывать всякие эвфемизмы для неё - например quality assistance - "содействие в обеспечении качества"))
Поэтому, вопрос действительно важный, но... Не докрутили вы, ребят. Даже, совсем наоборот - пошли в какие-то дебри...
Самый простой пример - сеньор Вася и джун Леша - кто из них сделает более качественно? Если не лезть во всякую софистику - лучше всегда сделает сеньор. Без всяких DoR, ci, cd и всего остального - просто сделает лучше. Нет, со всем этим он сделает ещё лучше - но, это вторично
Поэтому первый вопрос, который мы должны решить - не как внедрить ci/cd или в линтер чего нового запихнуть - а как сделать так, чтобы Леша стал Васей. Если есть деньги и нет времени - Лёшу можно уволить и нанять ещё одного Васю - и, да, это будет самым что ни на есть обеспечением качества. Или, Лёшу можно научить - на рабочем месте, что всегда и ставил во главу угла "папа" качества в его современном понимании У.Э.Деминг
Или, ещё один пример - с другой стороны - 152фз о ПД - ну вот вообще никак на него не может повлиять на qa, ни qc, ни тестировщик - но, тем не менее этот закон есть и он-таки обеспечивает качество
А ещё есть потребители, которым абсолютно плевать и на линтеры, и на тестирование - они выставляют свои требования к качеству и, в зависимости от них, пользуются тем или другим приложением. И опять, эти внешние требования обеспечивают качество... А вот как вы этими требованиями будете управлять (контролировать их выполнение) - это уже другой вопрос - здесь и пригодится все, что бы знаете и о DoR, и о DoD, и о приемочных критериях...
В сферической геометрии "прямой" считается большой круг - проходящий через две диаметрально противоположные точки. Вполне себе "очевидно", что нельзя нарисовать два больших круга, не имеющих общих точек
Минимум две - это аксиома. Из этой аксиомы легко получается бесконечность - все те прямые, которые лежат между указанными двуми
Что касается сферы - там вообще нет параллельных прямых. Правда, сферическая геометрия не относится к абсолютным - через диаметрально противоположные точки можно провести более одной прямой
Про определение полностью соглашусь - только немного дополню - параллельные должны лежать в одной плоскости (любой "плоскости" - Евклида, сфере, седловой поверхности...). Не имеют общих точек и скрещивающиеся прямые
Каждый раз читая подобные статьи я вспоминаю диалог Алекса с Ионой...
Честно - выглядит каким-то нелепым газлайтингом. На главной, крупно, посередине - все операции
Если кликнуть на карту или на счёт - которые тоже все есть на главной - далее так же крупно и посередине - операции по карте/счету
Лекарство от БАС - это круто
Но, упоминание ноотропов в контексте статьи - умножает степень доверия на 0
Все так, все так. Из 1000 кандидатов на место водителя - 99% отсеять по резюме и получить в итоге абсолютно нерелевантных кандидатов - это надо очень постараться
А тех, что таки прошли отбор - нужно непременно собеседовать в несколько этапов вопросами по теоретической механике, термодинамике и остальному сопромату. Просто посадить кандидата за руль или дать колесо перебортовать это слишком не по фаанговски
Так же обязательно требовать от кандидата навыков экстремального вождения или минимум кмс по автоспорту. Зачем? Конечно же затем чтобы булочки из пекарни возить на старом каблучке, который разучился ездить быстрее 60 км/ч ещё 30 лет назад
Нотация Йоды ещё как прижилась. Проблемы, которую она решала, как справедливо заметили, уже нет - а нотация есть
Ну вот мы и дошли ещё до одного принципа - тестирование зависит от контекста
Так скоро придем к пониманию, что опыт харьковской галерки, работающей на польского фермера... ээээ... простите, вендора - это ещё не весь опыт мира
Плакал и читал, читал и плакал... От смеха
В тестирование безопасности вы вообще зря полезли, месье
Как представил себе пентестера, тестирующего по требованиям, так и сполз под стол
ISTQB CTFL Syllabus Версия 2018
1.1.1 Основные цели тестирования
...
Обнаружение отказов и дефектов
...
Не благодарите меня, месье
Все гораздо проще с точки зрения глубинных знаний - любая научная теория должна быть фальсифицируемой. Если спроецировать требование фальсифицируемости на разработку ПО - мы получим такой атрибут качества, как тестируемость
Ну и далее по аналогии - чтобы сделать заключение об истинности какой-либо теории ее не "доказывают" - не проверяют по "требованиям", ее пытаются фальсифицировать - т.е. найти в ней "баги" - противоречия. Если этого сделать не получается - теория с высокой вероятностью является истинной
В общем-то, это конечно забавно "искать баги" мимо требований. Как минимум мы просто не будем знать что является багом, а что нет. Где-то кнопка должна быть красной, а где-то зелёной - и это нормально. Но, если вместо красной кнопки будет зелёная - это баг. Но, без требований мы никак не можем об этом знать
А если сказать, что ошибка, дефект (баг) и сбой - это не одно и то же ....
Да не торопитесь вы так, месье, уже заговариваться начали
А здесь у нас будет третий принцип, о котором наполеоны мценского уезда конечно не слышали - исчерпывающее тестирование невозможно