Тут не могу согласиться, тестировщик обладающий навыками автоматизации обладает более высокой производительностью труда и если ваш продукт нормально автоматизируется и при этом достаточно стабилен, то создание автотестов будет иметь бОльшую экономическую эффективность и чем больше в продукте функционала и старше продукт тем выгоднее становиться автоматизация, ну либо нанимайте каждые n месяцев еще одного ручника чтоб сохранять темпы регресса.
Кажется что в примере не совсем DDT, а обычная параметризация. В моем понимании DDT это когда только лишь на основе входных данных строится логика сценария т.е. и шаги и проверки.
Эм, заводить отдельную задачу на каждый косяк в коде и промерживать задачу в мастер с кучей косяков? Видится что такими темпами техдолг распухнет, а качество начнет падать.
Тоже проходил интервью недавно на AQA, Первая секция была java, в основном теория и пара задач оторванных от реальности.
Вторая секция: кодревью, докер, кубер, sql.
По докеру и куберу как я понял нужно чтоб ты имел опыт работы с этим, а не просто понимал для чего это нужно и умел взаимодействовать на уровне потребителя уже выстроенных конструкций (чтение логов, тюнинг скриптов).
В итоге отказ по докеру и куберу. На вопрос: что далее если ты идёшь автоматизатором на UI тебе нужно хорошо это знать HR ответила - да.
Вопрос выполняют ли AQA роль девопсов в команде пока HR-ром игнорируется=)
Каковы преимущества ручного тестирования?
Оно дешевле автоматизированного.
Тут не могу согласиться, тестировщик обладающий навыками автоматизации обладает более высокой производительностью труда и если ваш продукт нормально автоматизируется и при этом достаточно стабилен, то создание автотестов будет иметь бОльшую экономическую эффективность и чем больше в продукте функционала и старше продукт тем выгоднее становиться автоматизация, ну либо нанимайте каждые n месяцев еще одного ручника чтоб сохранять темпы регресса.
Кажется что в примере не совсем DDT, а обычная параметризация. В моем понимании DDT это когда только лишь на основе входных данных строится логика сценария т.е. и шаги и проверки.
Эм, заводить отдельную задачу на каждый косяк в коде и промерживать задачу в мастер с кучей косяков? Видится что такими темпами техдолг распухнет, а качество начнет падать.
Тоже проходил интервью недавно на AQA, Первая секция была java, в основном теория и пара задач оторванных от реальности.
Вторая секция: кодревью, докер, кубер, sql.
По докеру и куберу как я понял нужно чтоб ты имел опыт работы с этим, а не просто понимал для чего это нужно и умел взаимодействовать на уровне потребителя уже выстроенных конструкций (чтение логов, тюнинг скриптов).
В итоге отказ по докеру и куберу. На вопрос: что далее если ты идёшь автоматизатором на UI тебе нужно хорошо это знать HR ответила - да.
Вопрос выполняют ли AQA роль девопсов в команде пока HR-ром игнорируется=)
Интересно узнать как вы тестируете миграции в такой специфичной базе данных?