Я бы добавила сюда "чайка-менеджера": прилетел, наорал, нагадил и улетел. Команда работает не благодаря, а вопреки.
И тип "бывший разработчик, которого повысили за большую экспертизу" с людьми работать не умеет, дальше может пойти по многим из описанных сценариев. Команда опять работает не благодаря, а вопреки.
Интересная статья, спасибо, что опубликовали. А разработчики у вас пишут "простые кейсы и автотесты" или T-shape только в 1 сторону работает?
И ещё один вопрос возник: а почему когда билд не стартует - это проблема тестировщика, это тестировщик отвлекает глупыми вопросами команду, делая её менее эффективной? Вы не считаете, что девелоперы должны нести хотя бы такую ответственность за качество передаваемого кода, что могли бы гарантировать, что билд рабочий? По трудовым затратам это было бы более эффективно, чем кто-то, кто потом дебажит чужой код, потому что ничего не работает.
О, очень крутой коммент. В примере должно получиться 6 копеек, у Вас 5 как я поняла. Проблема подобной обертки, что нам нужно округления в зависимости от стороны сделки (продажа или покупка), это становится известно только в тесте, соответственно нельзя просто написать обертку для расчетов, в неё надо будет прокидывать доп данные из бизнеса, но опыт интересный, спасибо
Это был пример как было сделано, и как возникла ошибка в тестах и в коде, одна и та же. Почему было не сделать по-другому? Видимо потому, что баги так и возникают :)
То чувство, когда зашёл в статью почитать про то как автоматизировали ручные задачи и поменяли подход к релизному циклу, а проблему залили людьми и стали тратить на ручное тестирование ещё больше времени и ресурсов *сложный смайл*
Коллеги, подход: у нас проблемы с тестированием, давайте наймем 1го, 2х, N-тестировщиков, в 90% случаев не работает. Вы сейчас клеете пластыри, вместо того чтобы лечить болезнь. Займитесь автоматизацией, пусть девелоперы вам напишут фреймворк если у тестирования ресурсов нет, подключайте тестирование к планированию релизов, сделайте вообще это самое планирование - не увидела в статье ничего про релизный цикл, кроме того что к вам прибегает бизнес и запихивает задачи. Делайте ретро и анализируйте какие проблемы есть у вас и с чем это связано. Я уверена большинство из них будет связано с орехами в процессе, а не с тестированием.
Я решала ту же самую проблему в легаси системе, большой команде с отсутствием планирования, и часто хреновым описанием требований, больше 1000 кейсов у нас, за полгода мы пришли к нормальному состоянию тестирования, при этом с самой командой тестирования работать почти не пришлось - все дело в том как планируется релиз, какие оценки даются, как описываются требования, какой код вам отдают на входе и тп, с процессом надо работать.
Вы действительно не поняли о чем статья, у меня есть гипотеза почему: возможно Вы невнимательно ее читали, потому что повторяете те вещи, которые я там писала. Например, про то, что достижение 100% бессмысленно. И что порытие кода не связано напрямую с тем что багов нет.
Т.е. если тестов нет, это значит, что либо разработчики на них просто забили (нередкий случай), либо разработчики их не осилили(и такое бывает)
Не очень поняла как связана эта статья и тесты разработчиков, когда я говорю про тесты тестировщиков…
Я бы добавила сюда "чайка-менеджера": прилетел, наорал, нагадил и улетел. Команда работает не благодаря, а вопреки.
И тип "бывший разработчик, которого повысили за большую экспертизу" с людьми работать не умеет, дальше может пойти по многим из описанных сценариев. Команда опять работает не благодаря, а вопреки.
Интересная статья, спасибо, что опубликовали. А разработчики у вас пишут "простые кейсы и автотесты" или T-shape только в 1 сторону работает?
И ещё один вопрос возник: а почему когда билд не стартует - это проблема тестировщика, это тестировщик отвлекает глупыми вопросами команду, делая её менее эффективной? Вы не считаете, что девелоперы должны нести хотя бы такую ответственность за качество передаваемого кода, что могли бы гарантировать, что билд рабочий? По трудовым затратам это было бы более эффективно, чем кто-то, кто потом дебажит чужой код, потому что ничего не работает.
О, очень крутой коммент. В примере должно получиться 6 копеек, у Вас 5 как я поняла. Проблема подобной обертки, что нам нужно округления в зависимости от стороны сделки (продажа или покупка), это становится известно только в тесте, соответственно нельзя просто написать обертку для расчетов, в неё надо будет прокидывать доп данные из бизнеса, но опыт интересный, спасибо
Это был пример как было сделано, и как возникла ошибка в тестах и в коде, одна и та же. Почему было не сделать по-другому? Видимо потому, что баги так и возникают :)
То чувство, когда зашёл в статью почитать про то как автоматизировали ручные задачи и поменяли подход к релизному циклу, а проблему залили людьми и стали тратить на ручное тестирование ещё больше времени и ресурсов *сложный смайл*
Коллеги, подход: у нас проблемы с тестированием, давайте наймем 1го, 2х, N-тестировщиков, в 90% случаев не работает. Вы сейчас клеете пластыри, вместо того чтобы лечить болезнь. Займитесь автоматизацией, пусть девелоперы вам напишут фреймворк если у тестирования ресурсов нет, подключайте тестирование к планированию релизов, сделайте вообще это самое планирование - не увидела в статье ничего про релизный цикл, кроме того что к вам прибегает бизнес и запихивает задачи. Делайте ретро и анализируйте какие проблемы есть у вас и с чем это связано. Я уверена большинство из них будет связано с орехами в процессе, а не с тестированием.
Я решала ту же самую проблему в легаси системе, большой команде с отсутствием планирования, и часто хреновым описанием требований, больше 1000 кейсов у нас, за полгода мы пришли к нормальному состоянию тестирования, при этом с самой командой тестирования работать почти не пришлось - все дело в том как планируется релиз, какие оценки даются, как описываются требования, какой код вам отдают на входе и тп, с процессом надо работать.
Не очень поняла как связана эта статья и тесты разработчиков, когда я говорю про тесты тестировщиков…