Спасибо за статью. Отдельное за ваше разделение QC и QA. Однако, в статье увидел, кто такой Fullstack QC, а вот про QA вы так ничего, кажется, и не сказали. Хотя называете себя Fullstack QA. Или я неправильно понял?
Я хотел бы верить в благородство и моральность бизнеса, но я работал в аутстафе/аутсорсе. Стандартная практика: приукрасить умения программиста, увеличить ему опыт, продать заказчику.
Интересно, а кто же за эту "стандартную практику" топит...
Во втором случае мы скорее хотели обозначить отличие в областях применимости результата процессов QC и QA, поэтому выразились так. Благодаря вашему комментарию поняли, что не совсем точно. Спасибо, очень дельное замечание!
> По итогу, через контроль качества мы можем влиять на качество? Контроль качества помогает влиять на качество, но сам по себе является лишь лакмусовой бумажкой.
Спасибо за статью, Святослав. Приятно осознавать, что мы, не сговариваясь, решили подсветить эту проблему с разницей буквально в пару недель. Быть может, совместным фронтом получится изменить ситуацию в индустрии чуть более эффективно, чем это делалось разными людьми ранее.
Мы всё-таки считаем, что "начинать надо с себя", поэтому обращаемся в первую очередь к самим тестировщикам, которые называют себя "QA".
Если у вас получится, загляните к нам в статью "Перестань называть себя QA", будем очень рады услышать ваше мнение https://habr.com/ru/companies/tochka/articles/826152/
Совершенно верно! То, что тестировщиков стали называть QA – как раз результат того, что именно тестировщики стали чаще других ролей специализироваться на обеспечении качества. Но, к сожалению, в итоге это привело к тому, что всех тестировщиков стали называть QA. С этим мы и хотим попробовать бороться. Спасибо большое за ваш комментарий!
Станок-упаковщик, который вообще не имеет ни грейда, ни интеллекта, ни опыта, но имеющий правильно составленную инструкцию для упаковки, делает меньше брака, чем человек-упаковщик ЛЮБОГО разряда
К сожалению, мы пока не собирали какой-то список источников для этой задачи.
Но я бы рекомендовал попробовать разобрать процесс разработки на этапы, в каждом из этапов нашёл бы практики и техники, его обеспечивающие.
Из того, что прямо сейчас приходит на ум: изучите DoR и DoD, практики экстремального программирования, Три Амиго, стратегии ветвления, фича-флаги, Blue-Green деплои, trunk-based develompent. В принципе, в некоторых командах может потребоваться экспертиза настройки линтеров и статических анализаторов. Где-то - экспертиза организации код-ревью.
По ходу ещё наткнётесь на множество увлекательных практик и инструментов, которые могут помочь настроить процессы так, чтобы сделать разработку максимально быстрой и качественной.
Не обязательно. Опять же, в статье мы пишем, что для выполнения процессов QC и QA требуются разные скиллы. Даже разные майндсеты, что бы это ни значило. Но определённо, я встречал большое количество тестировщиков, которым очень тяжело даётся QA. И огромное количество техлидов и тимлидов, например, которым это даётся сильно прощё.
По поводу "называть себя буду так, как хотят рекрутеры". Вы путаете причину и следствие, к сожалению. Не рекрутеры придумали называть тестировщиков QA, а сами тестировщики. Как-то странно плясать под дудку тех, кто пляшет под вашу дудку.
По поводу того, что мы спрашиваем на собеседованиях: в статье русским языком написано, что мы считаем это не просто терминологической путаницей. Мы никогда не спрашиваем на собеседованиях определения терминов. Мы выясняем, умеет ли человек в анализ (т.е. отделять одно от другого), понимает ли, что такое "роль", рефлексирует ли он вообще о том, чем он занимается по жизни, или просто кнопки жмёт. И да, в хорошо настроенных процессах всё это требуется знать для качественной работы. Жаль, что вам не доводилось в подобных ситуациях оказываться
Смысл статьи, если грубо, в том, что QC (то, чем занимаются преимущественно тестировщики) не имеет никакого отношения к QA.
> Ну какая организация процесса разработки ... пока тимлиды вышли покурить на воздух? Серьезно?
И об этом мы говорим. О том, что тимлид в том числе занимается QA, и, как правило, куда в большей степени, чем тестировщик. Но почему-то именно тестировщиков все называют QA. Эту "несправедливость" мы статьёй и хотим попытаться исправить.
В результате прочтения вашего комментария сложилось ощущение, что вы неправильно поняли статью или прочитали её по диагонали. В статье прямым текстом говорится, что задача QC – обеспечить информацию о качестве продукта и его соответствии требованиям.
Вы пишете тоже самое, только почему-то со статьёй не соглашаетесь, это забавно)
Самый простой пример - сеньор Вася и джун Леша - кто из них сделает более качественно? Если не лезть во всякую софистику - лучше всегда сделает сеньор. Без всяких DoR, ci, cd и всего остального - просто сделает лучше. Нет, со всем этим он сделает ещё лучше - но, это вторично
Вот в том-то и дело, что вектор движения обеспечения качества – выстроить процесс разработки таким образом, чтобы джун мог сделать не менее качественно, чем синьор. И не требовалось судорожно искать по рынку ещё одного, а то и сотни новых синьоров. Или тратить деньги на развитие своих джунов до уровня синьоров. Это совершенно невыгодно бизнесу в перспективе. На дистанции выгоднее построить конвейер, использовать в нём джунов, а получать качество, которое раньше получалось только при найме синьоров.
И чем лучше развивается культура обеспечения качества, тем дешевле строится такой конвейер, и тем меньше денег тратится на создание чего-то полезного. И тем больше синьоры занимаются ещё более интересными и сложными задачами.
Спасибо за статью. Отдельное за ваше разделение QC и QA. Однако, в статье увидел, кто такой Fullstack QC, а вот про QA вы так ничего, кажется, и не сказали. Хотя называете себя Fullstack QA. Или я неправильно понял?
Интересно, а кто же за эту "стандартную практику" топит...
Во втором случае мы скорее хотели обозначить отличие в областях применимости результата процессов QC и QA, поэтому выразились так. Благодаря вашему комментарию поняли, что не совсем точно. Спасибо, очень дельное замечание!
> По итогу, через контроль качества мы можем влиять на качество?
Контроль качества помогает влиять на качество, но сам по себе является лишь лакмусовой бумажкой.
Спасибо за статью, Святослав. Приятно осознавать, что мы, не сговариваясь, решили подсветить эту проблему с разницей буквально в пару недель. Быть может, совместным фронтом получится изменить ситуацию в индустрии чуть более эффективно, чем это делалось разными людьми ранее.
Мы всё-таки считаем, что "начинать надо с себя", поэтому обращаемся в первую очередь к самим тестировщикам, которые называют себя "QA".
Если у вас получится, загляните к нам в статью "Перестань называть себя QA", будем очень рады услышать ваше мнение
https://habr.com/ru/companies/tochka/articles/826152/
Совершенно верно!
То, что тестировщиков стали называть QA – как раз результат того, что именно тестировщики стали чаще других ролей специализироваться на обеспечении качества. Но, к сожалению, в итоге это привело к тому, что всех тестировщиков стали называть QA. С этим мы и хотим попробовать бороться.
Спасибо большое за ваш комментарий!
Станок-упаковщик, который вообще не имеет ни грейда, ни интеллекта, ни опыта, но имеющий правильно составленную инструкцию для упаковки, делает меньше брака, чем человек-упаковщик ЛЮБОГО разряда
К сожалению, мы пока не собирали какой-то список источников для этой задачи.
Но я бы рекомендовал попробовать разобрать процесс разработки на этапы, в каждом из этапов нашёл бы практики и техники, его обеспечивающие.
Из того, что прямо сейчас приходит на ум: изучите DoR и DoD, практики экстремального программирования, Три Амиго, стратегии ветвления, фича-флаги, Blue-Green деплои, trunk-based develompent. В принципе, в некоторых командах может потребоваться экспертиза настройки линтеров и статических анализаторов. Где-то - экспертиза организации код-ревью.
По ходу ещё наткнётесь на множество увлекательных практик и инструментов, которые могут помочь настроить процессы так, чтобы сделать разработку максимально быстрой и качественной.
Не обязательно. Опять же, в статье мы пишем, что для выполнения процессов QC и QA требуются разные скиллы. Даже разные майндсеты, что бы это ни значило. Но определённо, я встречал большое количество тестировщиков, которым очень тяжело даётся QA. И огромное количество техлидов и тимлидов, например, которым это даётся сильно прощё.
QM тоже процесс, а QA Lead – пожалуй, лишь роль, которая отвечает за часть этого процесса
В статье к ним и обращаемся
По поводу "называть себя буду так, как хотят рекрутеры". Вы путаете причину и следствие, к сожалению. Не рекрутеры придумали называть тестировщиков QA, а сами тестировщики. Как-то странно плясать под дудку тех, кто пляшет под вашу дудку.
По поводу того, что мы спрашиваем на собеседованиях: в статье русским языком написано, что мы считаем это не просто терминологической путаницей. Мы никогда не спрашиваем на собеседованиях определения терминов. Мы выясняем, умеет ли человек в анализ (т.е. отделять одно от другого), понимает ли, что такое "роль", рефлексирует ли он вообще о том, чем он занимается по жизни, или просто кнопки жмёт. И да, в хорошо настроенных процессах всё это требуется знать для качественной работы. Жаль, что вам не доводилось в подобных ситуациях оказываться
Смысл статьи, если грубо, в том, что QC (то, чем занимаются преимущественно тестировщики) не имеет никакого отношения к QA.
> Ну какая организация процесса разработки ... пока тимлиды вышли покурить на воздух? Серьезно?
И об этом мы говорим. О том, что тимлид в том числе занимается QA, и, как правило, куда в большей степени, чем тестировщик. Но почему-то именно тестировщиков все называют QA. Эту "несправедливость" мы статьёй и хотим попытаться исправить.
В результате прочтения вашего комментария сложилось ощущение, что вы неправильно поняли статью или прочитали её по диагонали.
В статье прямым текстом говорится, что задача QC – обеспечить информацию о качестве продукта и его соответствии требованиям.
Вы пишете тоже самое, только почему-то со статьёй не соглашаетесь, это забавно)
Вот в том-то и дело, что вектор движения обеспечения качества – выстроить процесс разработки таким образом, чтобы джун мог сделать не менее качественно, чем синьор. И не требовалось судорожно искать по рынку ещё одного, а то и сотни новых синьоров. Или тратить деньги на развитие своих джунов до уровня синьоров. Это совершенно невыгодно бизнесу в перспективе. На дистанции выгоднее построить конвейер, использовать в нём джунов, а получать качество, которое раньше получалось только при найме синьоров.
И чем лучше развивается культура обеспечения качества, тем дешевле строится такой конвейер, и тем меньше денег тратится на создание чего-то полезного. И тем больше синьоры занимаются ещё более интересными и сложными задачами.
Привет! А почему вдруг грейдов перестало быть достаточно для отделения квалификации одного тостера от другого?)