S
но пацаны оттуда тоже такое слышали)
Size: a a a
2020 December 22
S
набор навыков наше все
AG
Куа вполне может решать когда катить фичи на прод, если это умелая разработка в фича тогл со всеми вытекающими практиками дизайна данных и миграций и ревью кода. С таким выкатить бекенд таску может и тестировщик, что собственно мы и делали на одном из продуктов
Женя, давай ищщо раз.
"Может" != "Должен", "Это может сделать куа" != "Это является частью тестирования".
"Может" != "Должен", "Это может сделать куа" != "Это является частью тестирования".
S
поэтому я сейчас судорожно впихиваю в себя максимум информации и навыков
S
а потом еще и китайский язык продолжу изучать
S
чего и всем советую
AG
Я вот, например, сейчас пишу эдакое quickstart приложение под iOS, как референс по интеграции с нами для сторонних разработчиков.
Ну, просто потому, что я могу это сделать, у меня есть на это ресурсы и мы с командой договорились что я это сделаю.
Но это, неожиданно, не превращает написание сэмп-приложений в часть процесса тестирования.
Ну, просто потому, что я могу это сделать, у меня есть на это ресурсы и мы с командой договорились что я это сделаю.
Но это, неожиданно, не превращает написание сэмп-приложений в часть процесса тестирования.
И
Sleeping with cats
чего и всем советую
EB
Согласен, это не тестирование, это зона остветственности. В каких-то компаниях если есть процессы надёжности кода / деплоя / етс, то эта роль может выполняться куа, тк они своим вердиктом качества фактически дают фиче жизнь в режиме ожидания.
AG
Amen.
EB
Я вот, например, сейчас пишу эдакое quickstart приложение под iOS, как референс по интеграции с нами для сторонних разработчиков.
Ну, просто потому, что я могу это сделать, у меня есть на это ресурсы и мы с командой договорились что я это сделаю.
Но это, неожиданно, не превращает написание сэмп-приложений в часть процесса тестирования.
Ну, просто потому, что я могу это сделать, у меня есть на это ресурсы и мы с командой договорились что я это сделаю.
Но это, неожиданно, не превращает написание сэмп-приложений в часть процесса тестирования.
Для меня превращает, ибо автоматизация нашего сдк именно за счёт таких сэмпл приложений и реализуется на е2е слое
AG
Для меня превращает, ибо автоматизация нашего сдк именно за счёт таких сэмпл приложений и реализуется на е2е слое
Ноуп, для автоматизации есть другое.
Это в опенсорс вместе с докой.
Это в опенсорс вместе с докой.
VK
Провести тестирование качественно можно только в том случае, если у вас есть все возможности (средства, информация и т.д.) это выполнить, если все это у вас было и вы выполнили тестирование не качественно, и есть ошибки, тогда имеет смысл предьявлять к тестированию претензии (наказывать, лишать, ругаться и прочее). Но опять же - надо четко понимать, что тестирование не панацея от всех бед, как и везде имеет значение и человеческий фактор. Кроме того, ответственность в любом случае должна быть солидарная. Ошибку сделал ведь не тестировщик, а разработчик, например, или аналитик, или еще кто-то. То есть, ответственность тестировщика всегда солидарная (я не говорю про случаи, когда тестировщик просто не стал ничего проверять).
Перекладываение ответственности с того же разработчика полностью на тестировщика обычно приводит к тому, что первые просто перестают даже пытаться искать свои ошибки (нет ведь в этом никакого смысла, ведь если что, виноват тестировщик) - не всегда, но очень часто.
Перекладываение ответственности с того же разработчика полностью на тестировщика обычно приводит к тому, что первые просто перестают даже пытаться искать свои ошибки (нет ведь в этом никакого смысла, ведь если что, виноват тестировщик) - не всегда, но очень часто.
K
Провести тестирование качественно можно только в том случае, если у вас есть все возможности (средства, информация и т.д.) это выполнить, если все это у вас было и вы выполнили тестирование не качественно, и есть ошибки, тогда имеет смысл предьявлять к тестированию претензии (наказывать, лишать, ругаться и прочее). Но опять же - надо четко понимать, что тестирование не панацея от всех бед, как и везде имеет значение и человеческий фактор. Кроме того, ответственность в любом случае должна быть солидарная. Ошибку сделал ведь не тестировщик, а разработчик, например, или аналитик, или еще кто-то. То есть, ответственность тестировщика всегда солидарная (я не говорю про случаи, когда тестировщик просто не стал ничего проверять).
Перекладываение ответственности с того же разработчика полностью на тестировщика обычно приводит к тому, что первые просто перестают даже пытаться искать свои ошибки (нет ведь в этом никакого смысла, ведь если что, виноват тестировщик) - не всегда, но очень часто.
Перекладываение ответственности с того же разработчика полностью на тестировщика обычно приводит к тому, что первые просто перестают даже пытаться искать свои ошибки (нет ведь в этом никакого смысла, ведь если что, виноват тестировщик) - не всегда, но очень часто.
K
Провести тестирование качественно можно только в том случае, если у вас есть все возможности (средства, информация и т.д.) это выполнить, если все это у вас было и вы выполнили тестирование не качественно, и есть ошибки, тогда имеет смысл предьявлять к тестированию претензии (наказывать, лишать, ругаться и прочее). Но опять же - надо четко понимать, что тестирование не панацея от всех бед, как и везде имеет значение и человеческий фактор. Кроме того, ответственность в любом случае должна быть солидарная. Ошибку сделал ведь не тестировщик, а разработчик, например, или аналитик, или еще кто-то. То есть, ответственность тестировщика всегда солидарная (я не говорю про случаи, когда тестировщик просто не стал ничего проверять).
Перекладываение ответственности с того же разработчика полностью на тестировщика обычно приводит к тому, что первые просто перестают даже пытаться искать свои ошибки (нет ведь в этом никакого смысла, ведь если что, виноват тестировщик) - не всегда, но очень часто.
Перекладываение ответственности с того же разработчика полностью на тестировщика обычно приводит к тому, что первые просто перестают даже пытаться искать свои ошибки (нет ведь в этом никакого смысла, ведь если что, виноват тестировщик) - не всегда, но очень часто.
Мне кажется, что, вообще, ни один процесс не может гарантировать 100% отсутствия багов. И тестирование, да и работа всех команд, направлены на снижение рисков.
VK
Мне кажется, что, вообще, ни один процесс не может гарантировать 100% отсутствия багов. И тестирование, да и работа всех команд, направлены на снижение рисков.
Все верно, именно минимизация ошибки. Причем если говорить именно об "обеспечении качачества" продукта, это работа комплекская, в которую должны быть вовлечены все участники, на каждом этапе. Вот почему я для себя QA и тестировщика, как понятия, стараюсь разделять.
AG
Мне кажется, что, вообще, ни один процесс не может гарантировать 100% отсутствия багов. И тестирование, да и работа всех команд, направлены на снижение рисков.
А я то наивный думал, что работа всех команд нацелена на то, что б бизнес работал.
AG
Денежки там делались. Вот это всё.
K
А я то наивный думал, что работа всех команд нацелена на то, что б бизнес работал.
Я где-то сказал, что это не так?