Как раз об этом я и поднимал тему — идет поиск своих объяснений, статусов а-ля «зеленый, но с оговорками»… и от этого-то и хочется двигаться к позиции «зеленый-хороший, красный-плохой».
Ошибка новичка, говорите… о нет, ни в коем разе. Из-за того, что мы сами опускаем руки при автоматизации, оставляя огромную кипу ручной работы, мы и приходим к тому, что зеленый — не значит, что все работает. И именно это придется изменить в мозгу, чтобы начать ставить CI на рельсы у себя на работе.
Так может тогда и не надо CI, если он врет, говоря, что с билдом все хорошо. Или мы не можем это сказать наверняка? Continuous Integration Шредингера прям.
Можно вопрос, регрессионное тестирование вы тоже делаете вручную?
Про проверку консистентности UI, это нельзя оставлять на потом. Не думайте о том, автоматизировать это или тестировать руками. Думайте о том, чтобы при разработке UI, ваш дизайнер/UX-специалист находился рядом с разработчиками и работал с ними бок о бок.
По последнему вопросу, да, я очень хочу, чтобы тестирование было полностью автоматизировано. QA-инженеры отчасти и занимаются тем, что автоматизируют end-to-end сценарии, подключая слой UI, каких-то внешних компонентов и прочее.
ИМХО это работа QA — не допускать таких косяков. И опять же — ручная.
нет, QA и тут может автоматизировать. И здорово, если задумается об этом. Я знаю человека, который всю жизнь работает тестировщиком. Он даже не думает об автоматизации и даже перфоманс-тесты делает вручную. Естественно, на это уходит огромное количество времени и надежность таких проверок невелика.
По поводу примера с сортировкой, попробуйте парное программирование и парную работу Developer-QA. Пусть девелоперы увидят, как работают QA-инженеры, а QA посмотрит, как идет работа у девелоперов. Общение поможет им уйти от документации, мокапов и потери информации.
Тестирование производительности автоматизируется, тестирование безопасности автоматизируется (сканеров сейчас валом), тестирование консистентности UI и тестирование удобства — эм, ребят, а вы это делаете после того, как фича уже готова? Может в процессе работы поговорить с UX-специалистом, а не отдавать QA лишь после нескольких дней разработки?
QA-инженеры нужны, поскольку полностью избавиться от ручного тестирования не удастся.Но их работу надо минимизировать и максимум уводить в автоматизацию. Время человеческое куда дороже времени машинного
А последнее по списку, на что я обращал внимание — это как раз команда. Активная работа с продукт-овнером (или менеджером, если он представляет заказчика), как раз и будет приводить к той ситуации, что тесты будут именно те, что нужно, что продукт именно в таком виде заказчику и нужен.
Красная лампочка — она для всей команды, в которую входят и разработчики, и тестировщики, и менеджеры, и продукт-овнеры
я не уверен, что правильно понял суть. Приемочное тестирование в любом случае осуществляет либо заказчик, либо его представитель в лице продукт-овнера, он же решает, какая из проблем наиболее критична. Речь же о том, чтобы команда была уверена в том, что она отдает и вместо того, чтобы придумывать новые статусы, вроде «более зеленым» или «более красным», идти к тому, чтобы иметь однозначный ответ — зеленый, отдаем, красный — нет.
Любой тест может обмануть. И хороший, и плохой. Написать хороший — искусство. Написать плохой — необходимость, чтобы научиться писать хорошие. Пусть он ассертит поведение, пусть он проходит, когда на компьютер не дышишь и не запускаешь посторонних программ, но он уже будет работать быстрее, чем проверить это руками
Сколько времени занимает сборка приложения? Хорошо, если это просто веб-странички и изменение действительно только во фронт-энде. Но серверный код выкладывать вот так, без всякой проверки? Риск, конечно, благороден :) Перед встречей с инвестором сделать что-то, не проверив… нет, я тут лучше рисковать не буду, ибо обернуться это может неработающим приложением.
По поводу специфики, она вроде всегда и есть, а вроде и нет. Мы деплоили и полностью клиентские системы, и веб, и SaaS с несколькими тысячами серверов, и базы данных, и мобильные приложения. Разница в деталях, несомненно, но суть остается одной — собери приложение не сам, а доверь компьютерам
Мне все же верится, что даже плохой тест повышает уверенность при разработке. Для команды, которая тестов вообще не писала и только начинает, это понять особенно важно, потому что первая причина, по которой они отказываются — как раз то, что вы назвали: большая стоимость поддержки, длинные, медленные и т.д… Чтобы начать, им придется писать плохие тесты по началу. Через это просто придется пройти
А вы думаете я все это не в реальной жизни применяю? в самой что ни на есть реальной. С одной командой получилось быстрее, с другой помедленнее идет, но идет.
А в ситуациях, когда надо выкатить в течение 20 минут фикс на продакшен, мне кажется, еще страшнее делать это, не написав тест.
Если зеленый цвет не значит, что с проектом все хорошо, то зачем применять Continuous Integration?.. Мне бы как раз очень хотелось обратного, чтобы зеленый билд означал работающее приложение. Часто этого сложно добиться, я понимаю, что все тесты не напишешь, да и от ручной проверки мы все равно не избавимся, хотя бы просто запустить приложение. Чем больше автоматизации, чем больше система проверит сама, тем выше шансы на то, что продукт в рабочем состоянии. Без панацеи, естественно.
Ошибка новичка, говорите… о нет, ни в коем разе. Из-за того, что мы сами опускаем руки при автоматизации, оставляя огромную кипу ручной работы, мы и приходим к тому, что зеленый — не значит, что все работает. И именно это придется изменить в мозгу, чтобы начать ставить CI на рельсы у себя на работе.
Про проверку консистентности UI, это нельзя оставлять на потом. Не думайте о том, автоматизировать это или тестировать руками. Думайте о том, чтобы при разработке UI, ваш дизайнер/UX-специалист находился рядом с разработчиками и работал с ними бок о бок.
По последнему вопросу, да, я очень хочу, чтобы тестирование было полностью автоматизировано. QA-инженеры отчасти и занимаются тем, что автоматизируют end-to-end сценарии, подключая слой UI, каких-то внешних компонентов и прочее.
нет, QA и тут может автоматизировать. И здорово, если задумается об этом. Я знаю человека, который всю жизнь работает тестировщиком. Он даже не думает об автоматизации и даже перфоманс-тесты делает вручную. Естественно, на это уходит огромное количество времени и надежность таких проверок невелика.
По поводу примера с сортировкой, попробуйте парное программирование и парную работу Developer-QA. Пусть девелоперы увидят, как работают QA-инженеры, а QA посмотрит, как идет работа у девелоперов. Общение поможет им уйти от документации, мокапов и потери информации.
QA-инженеры нужны, поскольку полностью избавиться от ручного тестирования не удастся.Но их работу надо минимизировать и максимум уводить в автоматизацию. Время человеческое куда дороже времени машинного
Красная лампочка — она для всей команды, в которую входят и разработчики, и тестировщики, и менеджеры, и продукт-овнеры
По поводу специфики, она вроде всегда и есть, а вроде и нет. Мы деплоили и полностью клиентские системы, и веб, и SaaS с несколькими тысячами серверов, и базы данных, и мобильные приложения. Разница в деталях, несомненно, но суть остается одной — собери приложение не сам, а доверь компьютерам
А в ситуациях, когда надо выкатить в течение 20 минут фикс на продакшен, мне кажется, еще страшнее делать это, не написав тест.
я думал в дебаг-моде на продакшн не деплоят