От себя замечу, что если описана ситуация когда разработчику приходит на PR синтаксически неверный код, я бы очень задумался о процессах в этой компании, о ее зрелости и вообще стоит ли дальше общаться.
Вероятность этого мала.
Если я не путаю ВОЗ допускает использование респираторов FFP2 с полнолицевым щитком.
Основная задача, как я понимаю защита от того, когда на вас чихают, от вот этих капелек.
Стоимость полумаски и хорошие очки, это уже полнолицевая маска бюджетного уровня, а может и нет :)
Коллега, на первой картинке ты приводишь в пример интегрированного решения GVS Elipse Integra за примерно 17к. И при этом ты его попробовал!
Я в свое время много работал с дремелем и металлом и после ряда не приятных инцидентов пришел к полно лицевому щитку из поликарбоната на каску, с высоким степенью стойкости. Да и каска на голове. Это реально спасало, а щиток живет долго и он совместим со всеми полумасками.
Далее по полно лицевым маскам Unix 5000 стоит порядка 3к. И нет на них дефицита, людей готовых их носить в общественных местах исчезающе мало. Просто пара сайтов решила хайпануть
Я советую смотреть на проблему шире и с разных сторон.
Я не понял, какую проблему автор решает.
Если нужна защита глас от стружек и прочего, то очки норм. Если хочется большего, то используется щиток. Они обычно совместимы с масками.
Если нужна защита глаз от агрессивной атмосферы, то нужны уже полно лицевые маски.
И так далеее.
Если автор про защиту от вируса, то очков хватит, даже не плотно прилегающих.
Соглашусь.
Выспитесь, пару дней ничего не делайте. Снова выспитесь.
И проведите настоящую рестроспектиу с включенным критическим мышлением.
И вот тогда поймете, где вы ошибаетесь
Все верно, в стандарте есть такое определение качества. Мое определение из книги “Total quality cintrol”, которое мне запомнилось и как мне кажется отражает суть качества. Как я писал, стандарт отличается от реальной жизни. В стандартах нет тестировщиков, а в жизни есть, так же и тут. Продукта без пользователей не существует. И фактически качество продукта определяют они, а не ТЗ. Другой вопрос кто за это отвечает и что с этим делать.
А книги нагло врут про реальную жизнь…
В стандартах есть тестирование, это так к слову.
Еще раз, «Качество — степень соответствия совокупности присущих характеристик объекта требованиям».
С этим мы можем работать, улучшать и прочее. С тем что думают пользователи внезапно нет.
Мы можем предпринимать набор действий, а вот результат слабо предсказуем.
Именно поэтому QA специалисты работают с ОБЕСПЕЧЕНИЕМ качества. Их задача убрать преграды на пути других, что бы они сделали продукт качественно, основной инструмент это процессы.
Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
это валидация и верификация?
Потому что ты написал это в чистом виде QC. Именно QC специалисты определяют достаточно критериев для приемки той или иной фичи или нет. Иногда ПМИ заставляют писать аналитиков, но аналитик и тестировщик это одно и то же, набор навыков у них один.
Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.
Эти люди есть везде где активно используют ИСО или CMMI, просто в части компаний придумывают свой альтернативный путь и идут по нему.
Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
1. мы нашли “багу” на PBR или в ТЗ.
Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
2. Нашли багу на проде.
Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.
Посмотрите, что есть сопровождаемость по стандартам.
Нравиться мне когда сравнивают не сравнимое. Но скажу. Компании которые упираются в том числе и в качество, делают так, что бы стоимость исправления дефекта была одинаково низкой, хоть на проде, хоть в доке. И этим занимаются специалисты по качеству. Так что второй пример, пример именно фиговой работы QA.
e-ivanchenko, смотрим ГОСТ Р ИСО 9000-2015: «Качество — степень соответствия совокупности присущих характеристик объекта требованиям». Все, и не надо фантазировать про потребителя и прочее. Вот как требования выявили, так и получили…
Опять же, специалисты по QA не занимаются они вот этим: QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это.
То что тут описанно это QC, ага оно самое, верификация и валидация.
В задачу QA входит например поставить процесс релизного менеджмента или например если мелко, процесс обработки изменеий в коде, пулл реквестов.
Повторюсь, QA инженеры работают с процессами, просто обычно они не поднимаются выше процессов обеспечения качества, а вот инженеры по процессам, работают уже с любым уровнем.
e-ivanchenko по картинке, где стоимость изменения растет вверх от времени. Это будет так если вы поклали орган на атрибут качества под названием сопровождаемость.
Процесс выглядит так: есть список задач, который я определяю на спринт.
Интересный момент, с учетом того, в скраме именно команда говорит сколько она сделает за спринт, да ПО определяет приоритеты, но на обьем он влиять не может.
И еще, а можно увидеть схему как правильно сидеть за компьютером.
На всех схемах верхний край монитора либо на уровне глаз, либо ниже. Исходя из написанного в статье это не правильно
Нет, QA специалисты не занимаются QC, а уж тем более тестированием.
Если у вас в компании так, то тогда у меня для вас плохие новости :)
Есть такой фасет в нефункционально тестировании. И?
Да есть тестировщики специализирующиеся на нем, но именно тестировщики, они обычно одновременно юзабилити занимаются. Но это не то чем занимается QA
Статья отличная!, последний пример про гуглодок вообще сюрреализм какой-то) Тестировщик должен прежде всего уметь общаться со всей командой.
Нет не должен. А вот к Тим Лиду большой вопрос, что за бардак у него в рабочей группе.
Быть QA это круто, это интересно и познавательно… Но что делать в ситуации, если тестировщик захотел стать QA, а такой должности в компании нет.
Хорошо бы понимать что есть QA и должность не обязательна должна быть.
Может быть и роль.
Кстати мало людей фанатеют от гостов и стандартов. А для QA они основа в работе…
И вот он пытается на этапе обсуждения требований заказчика что-то свое предложить, но его не слушают, пытается объяснить разработчику, как будет удобнее для пользователя сделать кнопку, форму и т.д. — разработчик говорит — этого нет в ТЗ. Рассказывает в никуда про автоматизацию и юнит тесты. В общем пытается сделать качество продукта более высоким, но безрезультатно.
Не занимаются QA удобством продукта для пользователя.
Более того если этого нет в ТЗ именно QA первый скажет стопе. Вносите в ТЗ, вот тогда и будем разговарить, нет процесса на измение тз? Ок, счас будуте.
QA — это в первую очередь нацеленность на бизнес и на процессы.
Но не всегда подобные сотрудники в команде это плохо. Чаще всего они самостоятельны, профессиональны и прекрасно знают себе цену. Здесь проблема не в качествах сотрудника, а руководителя: насколько конкретный руководитель готов работать с таким сложным и самоуверенным человеком.
www.youtube.com/watch?time_continue=4&v=ZK36t96y-u8&feature=emb_title
Если есть 3д принтер то не проблема! Там вроде уже и обратный переходник сделали.
Про FF-400, да это топ! Это стоит того, весьма хороша! Но найти ее большая проблема, согласен.
Глянул каталоги. Есть совсем не дорогое решение это ППМ-88, можно найти меньше 1000 и к ней Бриз-1001 то же весьма не дорого. Но поискать их придется.
Если я не путаю ВОЗ допускает использование респираторов FFP2 с полнолицевым щитком.
Основная задача, как я понимаю защита от того, когда на вас чихают, от вот этих капелек.
Стоимость полумаски и хорошие очки, это уже полнолицевая маска бюджетного уровня, а может и нет :)
Я в свое время много работал с дремелем и металлом и после ряда не приятных инцидентов пришел к полно лицевому щитку из поликарбоната на каску, с высоким степенью стойкости. Да и каска на голове. Это реально спасало, а щиток живет долго и он совместим со всеми полумасками.
Далее по полно лицевым маскам Unix 5000 стоит порядка 3к. И нет на них дефицита, людей готовых их носить в общественных местах исчезающе мало. Просто пара сайтов решила хайпануть
Я советую смотреть на проблему шире и с разных сторон.
Вот обзор: habr.com/ru/post/488990
Я не понял, какую проблему автор решает.
Если нужна защита глас от стружек и прочего, то очки норм. Если хочется большего, то используется щиток. Они обычно совместимы с масками.
Если нужна защита глаз от агрессивной атмосферы, то нужны уже полно лицевые маски.
И так далеее.
Если автор про защиту от вируса, то очков хватит, даже не плотно прилегающих.
Выспитесь, пару дней ничего не делайте. Снова выспитесь.
И проведите настоящую рестроспектиу с включенным критическим мышлением.
И вот тогда поймете, где вы ошибаетесь
А это просто брилиант!
А книги нагло врут про реальную жизнь…
В стандартах есть тестирование, это так к слову.
Еще раз, «Качество — степень соответствия совокупности присущих характеристик объекта требованиям».
С этим мы можем работать, улучшать и прочее. С тем что думают пользователи внезапно нет.
Мы можем предпринимать набор действий, а вот результат слабо предсказуем.
Именно поэтому QA специалисты работают с ОБЕСПЕЧЕНИЕМ качества. Их задача убрать преграды на пути других, что бы они сделали продукт качественно, основной инструмент это процессы.
Потому что ты написал это в чистом виде QC. Именно QC специалисты определяют достаточно критериев для приемки той или иной фичи или нет. Иногда ПМИ заставляют писать аналитиков, но аналитик и тестировщик это одно и то же, набор навыков у них один.
Эти люди есть везде где активно используют ИСО или CMMI, просто в части компаний придумывают свой альтернативный путь и идут по нему.
Посмотрите, что есть сопровождаемость по стандартам.
Нравиться мне когда сравнивают не сравнимое. Но скажу. Компании которые упираются в том числе и в качество, делают так, что бы стоимость исправления дефекта была одинаково низкой, хоть на проде, хоть в доке. И этим занимаются специалисты по качеству. Так что второй пример, пример именно фиговой работы QA.
e-ivanchenko, смотрим ГОСТ Р ИСО 9000-2015: «Качество — степень соответствия совокупности присущих характеристик объекта требованиям». Все, и не надо фантазировать про потребителя и прочее. Вот как требования выявили, так и получили…
Опять же, специалисты по QA не занимаются они вот этим:
QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это.
То что тут описанно это QC, ага оно самое, верификация и валидация.
В задачу QA входит например поставить процесс релизного менеджмента или например если мелко, процесс обработки изменеий в коде, пулл реквестов.
Повторюсь, QA инженеры работают с процессами, просто обычно они не поднимаются выше процессов обеспечения качества, а вот инженеры по процессам, работают уже с любым уровнем.
e-ivanchenko по картинке, где стоимость изменения растет вверх от времени. Это будет так если вы поклали орган на атрибут качества под названием сопровождаемость.
Интересный момент, с учетом того, в скраме именно команда говорит сколько она сделает за спринт, да ПО определяет приоритеты, но на обьем он влиять не может.
А то делать с упором под поясницу или же надо всей спиной лежать на спинке?
На всех схемах верхний край монитора либо на уровне глаз, либо ниже. Исходя из написанного в статье это не правильно
Если у вас в компании так, то тогда у меня для вас плохие новости :)
Есть такой фасет в нефункционально тестировании. И?
Да есть тестировщики специализирующиеся на нем, но именно тестировщики, они обычно одновременно юзабилити занимаются. Но это не то чем занимается QA
Нет не должен. А вот к Тим Лиду большой вопрос, что за бардак у него в рабочей группе.
Хорошо бы понимать что есть QA и должность не обязательна должна быть.
Может быть и роль.
Кстати мало людей фанатеют от гостов и стандартов. А для QA они основа в работе…
Не занимаются QA удобством продукта для пользователя.
Более того если этого нет в ТЗ именно QA первый скажет стопе. Вносите в ТЗ, вот тогда и будем разговарить, нет процесса на измение тз? Ок, счас будуте.
QA — это в первую очередь нацеленность на бизнес и на процессы.
Да прекрасно все!
П — подмена понятий.
ДеМарко в человеческом факторе доказал обратное и доказал насколько это плохо.