VR
Внезапно - а что по вашему должны делать тестировщики - оба края ?
И какую оценку дать ?
И какую оценку дать ?
Size: a a a
2019 February 17
VR
пятёрочку ?)
k
ну какое ощущение? ваша команда тестирования знакома с архитектурой? описание крайних точек для ориентира хорошо-плохо) описание спорное возможно. но оценку выставить позволяет
k
любопытно) то есть тестировщику мешает это?
VR
Может - например, читая CVE.
Да и понимая как внутри работает - лучше понимает слабые места.
Но я не тестировщик. Мне просто вопрос не понравился - на мой взгляд тестировщик должен уметь и ломать "чёрный ящик" и ломать "конкретную инфраструктуру" и "пройти по данному ТЗ и проверить, что в базовом кейсе приложение вообще работает".
Да и понимая как внутри работает - лучше понимает слабые места.
Но я не тестировщик. Мне просто вопрос не понравился - на мой взгляд тестировщик должен уметь и ломать "чёрный ящик" и ломать "конкретную инфраструктуру" и "пройти по данному ТЗ и проверить, что в базовом кейсе приложение вообще работает".
k
Может - например, читая CVE.
Да и понимая как внутри работает - лучше понимает слабые места.
Но я не тестировщик. Мне просто вопрос не понравился - на мой взгляд тестировщик должен уметь и ломать "чёрный ящик" и ломать "конкретную инфраструктуру" и "пройти по данному ТЗ и проверить, что в базовом кейсе приложение вообще работает".
Да и понимая как внутри работает - лучше понимает слабые места.
Но я не тестировщик. Мне просто вопрос не понравился - на мой взгляд тестировщик должен уметь и ломать "чёрный ящик" и ломать "конкретную инфраструктуру" и "пройти по данному ТЗ и проверить, что в базовом кейсе приложение вообще работает".
уметь должен) полностью согласен
VR
уметь должен) полностью согласен
Ну так а в чём заключался твой вопрос в опросе ?
Что ты хотел узнать-то ?
Что ты хотел узнать-то ?
k
Ну так а в чём заключался твой вопрос в опросе ?
Что ты хотел узнать-то ?
Что ты хотел узнать-то ?
вопрос не в том что должен гипотетический тестировщик. а конкретно в твоём проекте тестировщик знаком ли с тем как вообще устроен его продукт? может ли он локализовать проблему не в виде «я что-то нажал и всё упало» а опускаясь вглубь найти проблемный модуль по логам, как можно точнее локализуя проблему
VR
скорее он сделает тест кейс - проверить, что так не делают.
VR
вопрос не в том что должен гипотетический тестировщик. а конкретно в твоём проекте тестировщик знаком ли с тем как вообще устроен его продукт? может ли он локализовать проблему не в виде «я что-то нажал и всё упало» а опускаясь вглубь найти проблемный модуль по логам, как можно точнее локализуя проблему
Нужно ли ему искать проблемный модуль и строку кода ?
Ему нужно найти _повторяемый_ сценарий _воспроизведения_ бага.
Дальше пускай по сценарию разработчик разбирается с логами и модулями.
Ему нужно найти _повторяемый_ сценарий _воспроизведения_ бага.
Дальше пускай по сценарию разработчик разбирается с логами и модулями.
k
ок) принято)
VR
Вот еще вопрос на который я могу ответить только 5 - тестировщик должен уметь в обе стороны.
Знать менеджерский язык - вообще не их задача.
Знать менеджерский язык - вообще не их задача.
k
Вот еще вопрос на который я могу ответить только 5 - тестировщик должен уметь в обе стороны.
Знать менеджерский язык - вообще не их задача.
Знать менеджерский язык - вообще не их задача.
давай так) не смотри на описание граничных значений) заполняй просто по десятибальной шкале. но опять таки, это вопрос не о гипотетическом тестировщике, а о том с кем ты работаешь.
VR
А может кто рассказать - как вы ускоряете поставку фич ?
Сейчас у нас 2 команды и спринты по 2 недели.
Хочется быстрее, но некоторые задачи в более короткие сроки не укладываются.
Как лучше синхронизировать фронт и бек, чтобы деплоиться по готовности фичи ?
Сейчас у нас 2 команды и спринты по 2 недели.
Хочется быстрее, но некоторые задачи в более короткие сроки не укладываются.
Как лучше синхронизировать фронт и бек, чтобы деплоиться по готовности фичи ?
GM
А может кто рассказать - как вы ускоряете поставку фич ?
Сейчас у нас 2 команды и спринты по 2 недели.
Хочется быстрее, но некоторые задачи в более короткие сроки не укладываются.
Как лучше синхронизировать фронт и бек, чтобы деплоиться по готовности фичи ?
Сейчас у нас 2 команды и спринты по 2 недели.
Хочется быстрее, но некоторые задачи в более короткие сроки не укладываются.
Как лучше синхронизировать фронт и бек, чтобы деплоиться по готовности фичи ?
Заведите у себя фича-тоглы, и деплойте фронт и бек отдельно по мере готовности. Как фича выкатится на обе платформы, включайте фичу
VR
Заведите у себя фича-тоглы, и деплойте фронт и бек отдельно по мере готовности. Как фича выкатится на обе платформы, включайте фичу
Не хочется фича тогглы - лапши в коде много будет.
Или я не понимаю как это работает.
Я вижу некоторый вариант релизов раз в неделю - фича деплоится в каждый предстоящий релиз.
Вот и хочу мнений - кто как делает.
Или я не понимаю как это работает.
Я вижу некоторый вариант релизов раз в неделю - фича деплоится в каждый предстоящий релиз.
Вот и хочу мнений - кто как делает.
VR
бек может выпускать breaking changes - тогда их нужно строго вместе с фронтом деплоить, пускай даже на staging.
Сейчас мы уверены, что в конце спринта у нас 100% рабочая ветка.
Сейчас мы уверены, что в конце спринта у нас 100% рабочая ветка.
VR
Больная история.
Я не понимаю как в python(django) приложении это красиво версионировать.
Наверное лучше почитать надо.
Я не понимаю как в python(django) приложении это красиво версионировать.
Наверное лучше почитать надо.
VR
а язык бека какой ?
VR
Слушай, да, в других языках также делается.
Спасибо, будет использовать рекомендованный велосипед!
Спасибо, будет использовать рекомендованный велосипед!