нет не интересно, интересно было лет 7 назад когда волна поднялась, а сейчас так, сентиментальный фельетон в стиле СССРовского "фитиля"=) но написано красиво, да
выглядит как локализация сборки с полным циклом тестирования…
в целом в общем то пусть так, надеюсь когда нибудь такие проекты мы сможем называть «производством полного цикла»
Мы с вами скатились к тому факту что ИТ индустрия в целом сломана, есть там ручные тестировщики или нет, не важно, на выходе получается тормознутое говнище =)
отлично, вы нашли очень хороший баг руками, по двум причинам
1) вы погружены в предметную область
2) тестируемый объект, сложен для тестирования именно этого вида ошибок (логика)
IMHO автоматизация как раз поможет сделать так, чтобы подобный класс ошибок фиксировался на регрессии
Слушайте, всегда считал, что цель работы QA это собственно говоря повышение самого Quality (как метрику часто берут кол-во багов в JIRA поделить на кол-во багов с production (с клиентов) и собственно повышение Assurance (доверия) к результатам тестирования
Добиваться этого IMHO через автоматизацию легче
Естественно тестировщик может не хотеть в автоматизацию, но тогда повторюсь он должен достигать QA через грамотный дизайн тестов.
и иметь Грамотные метрики
и Грамотные процессы
=)
я не против ручного тестирования,
но оно вообще не должно сводиться к «свободному поиску ошибок методом научного тыка», хотя и такой вариант возможен при условии, что тестировщик на выходе дает реально reproducible баг и этот баг действительно аффектит что-то
и соответственно, ручное тестирование должно быть как минимум воспроизводимым и чтобы оно было воспроизводимым, все равно нужна автоматизация =)
иначе ручное тестирование сожрет все время на коммуникациях
ну то что вы «корректоров» назвали тестировщиками =) это конечно хорошо, но тестировали они у вас не саму ИТ систему, а валидировали данные в этой системе, это все таки разные вещи,
при этом вы сами говорите что у вас автоматическая проверка и рандомизация входных данных для задач была ;)
IMHO, конкретно QA который не умеет в автоматизацию, должен тогда уметь в Requirements и тест дизайн, то есть он должен сценарии тестирования делать такие, которые потом уже автоматизаторы могли бы взять в работу
=)) почему вы считаете что это хоть как то поможет?
почему вы считаете что возможно законодательно сформулировать точность «состава этикетки»? тем более в такой сфере как услуги?
по моему афтор просто релаксирует и занимается «провокациями» рассматривая хабр даже не как поле для дискуссий, а площадку для рефлексирующих высеров в надежде получить эмоциональный отклик
EncryptionConfiguration это же шифрование только на уровне etcd
внутри кубов как были get secrets в нешифрованные так и останутся? разве нет?
Вы погуглите "семья саклер оксиконтин", сами все поймете
Спасибо =) отличная статья, будем давать на нее ссылки для разъяснения
Недавно вышла переработанная версия
https://github.com/AlexAkulov/clickhouse-backup/releases/tag/v1.0.0
c поддержкой Atomic и множеством фиксов
нет не интересно, интересно было лет 7 назад когда волна поднялась, а сейчас так, сентиментальный фельетон в стиле СССРовского "фитиля"=)
но написано красиво, да
в целом в общем то пусть так, надеюсь когда нибудь такие проекты мы сможем называть «производством полного цикла»
вроде бы linkerd использует EWMA алгоритм, но не ясно учитывает ли он там ошибки и timeouts
1) вы погружены в предметную область
2) тестируемый объект, сложен для тестирования именно этого вида ошибок (логика)
IMHO автоматизация как раз поможет сделать так, чтобы подобный класс ошибок фиксировался на регрессии
Добиваться этого IMHO через автоматизацию легче
Естественно тестировщик может не хотеть в автоматизацию, но тогда повторюсь он должен достигать QA через грамотный дизайн тестов.
и иметь Грамотные метрики
и Грамотные процессы
=)
я не против ручного тестирования,
но оно вообще не должно сводиться к «свободному поиску ошибок методом научного тыка», хотя и такой вариант возможен при условии, что тестировщик на выходе дает реально reproducible баг и этот баг действительно аффектит что-то
и соответственно, ручное тестирование должно быть как минимум воспроизводимым и чтобы оно было воспроизводимым, все равно нужна автоматизация =)
иначе ручное тестирование сожрет все время на коммуникациях
при этом вы сами говорите что у вас автоматическая проверка и рандомизация входных данных для задач была ;)
IMHO, конкретно QA который не умеет в автоматизацию, должен тогда уметь в Requirements и тест дизайн, то есть он должен сценарии тестирования делать такие, которые потом уже автоматизаторы могли бы взять в работу
или я как то не так прочитал статью?
Вы уверены что у вас действительно есть место на рынке?
Понимаете, IMHO мануальный тестировщик это ОЧЕНЬ ДОРОГО (несмотря на то, что зарплаты ниже)
единственный плюс мануального тестировщика, если он реально умеет в дизайн тестов
и умеет например реально крутые steps to reproduce делать
И мануальный тестировщик появляется тогда, когда тестировать «автоматически» у компании не хватает компетенций
почему вы считаете что возможно законодательно сформулировать точность «состава этикетки»? тем более в такой сфере как услуги?
по моему афтор просто релаксирует и занимается «провокациями» рассматривая хабр даже не как поле для дискуссий, а площадку для рефлексирующих высеров в надежде получить эмоциональный отклик
github.com/esrlabs/chipmunk