Здравствуйте, approach, Вы писали:
A>Ну, я зачастую работаю Q&A. A>Про тимлидов и не говорю, мы для них боги. Пока мы не утвердим архитектуру, разработка не начинается.
Жжошь! Но вообще — да, это часто встречающаяся позиция. Спросите у любого, чья профессия всех важнее... Грузчики вам тут-же обьяснят, что они — боги, пока не разгрузят жизнь стоит в ступоре, "охранник" на парковке как 2+2=4 докажет, что мир замирает и ждёт, пока он не нажмёт кнопку на шлакбауме...
Ну, я зачастую работаю Q&A. Темы все те же, улучшить качество кода. У нас кстати девы на свой код сами пишут тесты, а вот нагрузочные уже мы. Иногда приходится воспитывать разработчиков, особенно молодых, пару раз перепишет интерфейс, уже совсем по-другому к тестам относится. Про тимлидов и не говорю, мы для них боги. Пока мы не утвердим архитектуру, разработка не начинается. Писать хороший код надо научиться, время потратить, знания обрести, поэтому у нас в тестерах одни дедушки, всем уже за 40 и есть даже за 50. Не обсуждаем мы уже качество кода, студенческие споры неинтересны уже нам, а вот разнообразные тест тулы и фреймворки завсегда.
Ну…, тестирование это интересней, чем программирование! Сертификация от «Software Testing International Software Testing Qualifications Board (ISEB)». Грамотное тестирование это высокое качество кода. Мы пишем софт, который обслуживает строительные объекты, мосты, нефтяные платформы, авиацию. Такой софт должен точно прогнозировать технический осмотр, замену запчастей, ресурсы машин, колебания почвы, метеоусловия и т.д. Я думаю, теперь становится понятно, почему требуется такое качество кода. Все остальное тестирование от лукавого
Нет, не MS, небольшая софтверная компания с головным офисом в западной европе. Название широко известное только в узких кругах.
Здравствуйте, approach, Вы писали:
A>Понимаю, но мы же все-таки за деньги работаем, и никаких личных прявязанностей.
Да ладно тебе, не грусти. Все и так все понимают.
Здравствуйте, approach, Вы писали:
A>Ну, я зачастую работаю Q&A. Темы все те же, улучшить качество кода. У нас кстати девы на свой код сами пишут тесты, а вот нагрузочные уже мы. Иногда приходится воспитывать разработчиков, особенно молодых, пару раз перепишет интерфейс, уже совсем по-другому к тестам относится. Про тимлидов и не говорю, мы для них боги. Пока мы не утвердим архитектуру, разработка не начинается. Писать хороший код надо научиться, время потратить, знания обрести, поэтому у нас в тестерах одни дедушки, всем уже за 40 и есть даже за 50. Не обсуждаем мы уже качество кода, студенческие споры неинтересны уже нам, а вот разнообразные тест тулы и фреймворки завсегда.
Если это не гон, то хз где такое есть. У нас если у тестера достаточно мозгов, чтобы понять код, его при первой возможности переводят в программисты или в аналитики.
Здравствуйте, approach, Вы писали:
A>Ну…, тестирование это интересней, чем программирование! Сертификация от «Software Testing International Software Testing Qualifications Board (ISEB)». Грамотное тестирование это высокое качество кода. Мы пишем софт, который обслуживает строительные объекты, мосты, нефтяные платформы, авиацию. Такой софт должен точно прогнозировать технический осмотр, замену запчастей, ресурсы машин, колебания почвы, метеоусловия и т.д. Я думаю, теперь становится понятно, почему требуется такое качество кода. Все остальное тестирование от лукавого
Не очень понятно: по описанию выходит довольно солидная экспертная система. На голых тестах "по спецификации да по ТЗ" разве возможно подобное вытащить?
Или у вас все спецификации пишутся уже после исследовательской части, когда "умники" передают выверенную мат. модель программистам?
Экспертная система, матмодель наверное громко будет сказано, поскольку ядро приложения представляет собой командную модель основанную на событиях. Логика такова, что позволяет связать любое событие с любым другим событием в самых разных сочетаниях и приоритетах. Собственно это и есть ноу-хау, которое приносит деньги. Архитектурно это WPF приложение с весьма сложной анимацией пользовательского интерфейса, сложно описать словами, но рабочая область интуитивно помогает пользователю выбирать разнообразные сценарии событий, которые, разумеется, зависят от внешних данных. Приложение построено на Prism, в качестве контейнера совсем недавно покинули Unity из-за проблем с утечкой памяти, и перешли на MEF. Последний оказался менее зависимый, что расширило модульную архитектуру и теперь плагины можно подгружать не только при старте программы, а также и во время работы. Это дает гибкость конечных решений для потенциальных клиентов, то есть клиент оплачивает только необходимые ему модули, а также может заказать какие-то кастомные фичи, что ему ничего не стоит, поскольку клиенты приобретают годовую лицензию. Сложность архитектуры постоянно растет в связи с требованиями клиентов, где-то это системы безопасности в особо опасных зонах, где-то рабочий должен все время подтверждать свое местонахождение или выполненные работы, где-то техосмотр большого парка узлов и машин или другие сценарии.
Здравствуйте, minorlogic, Вы писали:
M>Круто, я не встречал тестеров которые могли в коде какнить разбираться . Майкрософт ?
Это реальность, по-моему, более-менее приличной ит-конторы.
Здравствуйте, AnrySpb, Вы писали:
AS>Здравствуйте, minorlogic, Вы писали:
M>>Круто, я не встречал тестеров которые могли в коде какнить разбираться . Майкрософт ? AS>Это реальность, по-моему, более-менее приличной ит-конторы.
А мотивация какая работать тестером если есть возможность работать разработчиком ?
Здравствуйте, minorlogic, Вы писали:
M>А мотивация какая работать тестером если есть возможность работать разработчиком ?
Странно, а зачем работать разработчиком, если можно работать тестировщиком?
Чем мотивация тестера хуже разработчика? Разработчик получил на утреннем митинге задачу, взять там либу такую-то, написать к ней адаптер или что там, все, никакого креатива. Тестеру намного интересней, его задача завалить свежеприготовленный код. Кто тестировал, знает, что тестер начинает работу с типа класса или интерфейса, создает инстанс (mock) и ранжирует в тесте публичные методы каждого класса, сначала автоматическим генератором тестов, затем сам вручную пишет тестовый метод, смотрит, появился баг, все, оформляет воркайтем. Если софт прошел тестера, значит, претензий к нему не будет еще долго.
Здравствуйте, minorlogic, Вы писали:
M>Круто, я не встречал тестеров которые могли в коде какнить разбираться . Майкрософт ?
Моей первой работой было тестирование в фиче тестинге и меня учили мол нашел баг, есть время, не ленись, попробуй сам найти руткост в коде, так и рос дальше. при написании тестов любили использовать подход вайтбокса и давать задания не "проверь что все работает", а "придумай как это сломать". в тоже время была команда систем тестенга и у них был другой подход — черный ящик.
в настоящее время работаю в более "солидной и известной компании" но тестеры у нас реально недоразвитые. они даже не знают как продукт должен работать, просто каждый день жмут одни и те же кнопки и если что-то не как вчера то так и пишут в багах, а потом оказывается что это не новый баг появился, а на оборот старый пофиксили, тут уж им явно не до кода
Все правильно, есть такая техника white box – это тестирование изнутри, то есть классы, методы приложения, а black box это тестирование снаружи, когда подаем в тесте, например на либу какой-нибудь объект и сверяем в ассерте результат.
Здравствуйте, approach, Вы писали:
A>Разработчик получил на утреннем митинге задачу, взять там либу такую-то, написать к ней адаптер или что там, все, никакого креатива. Тестеру намного интересней, его задача завалить свежеприготовленный код.
В такой разработке действительно мало интересного вижу (как впрочем и в тестировании).
Здравствуйте, approach, Вы писали:
A>Если софт прошел тестера, значит, претензий к нему не будет еще долго.
Ну скажем не всегда. Промышленное окружение от тестового всё же отличается. Вплоть до патчей на ОС и БД. Скилы тех, кто ставил софт — отличаются. У нас софт поставляется одному заказчику, но в разные регионы. И в каждом регионе на проде — свои баги! Такое подозрение, что местные сотрудники заказчика их культивируют
Всё заканчивается плохо. Если что-то закончилось хорошо — значит оно еще не закончилось.
Юра, я же шучу, впрочем, в каждой шутке есть только доля шутки.
Вот давай завтра придешь на работу, открывай свой проект, выбирай любой класс, и вот сам для себя скажи, можно его затестировать? Если нет, значит в коде ошибка, сразу тебе говорю.
Если класс нельзя тестануть с ходу, значит интерфейс выведен неверно, однозначно. Я разумеется не имею ввиду зависимые классы, которые должны мокаться в таких случаях.
Продолжу мысль. Разработчики, которые не понимают тестирование, никогда не пишут добротный код, увы. Архитекторы, которые не пришли к тестеру и не спросили, Вась, а Вась, посмотри, все ли тут можно затестировать, никогда не построят надежную и масштабированную систему. Возможность тестирования ПО говорит что архитектура выбрана верно, а это значит, что поддержка системы недорогая, расширение несложное и т.п. признаки грамотного ПО.
Кстати, недавно разбирался с прогой, не поверишь, объем 24 гига, вот попробуй представить как нужно проектировать такую систему.
Здравствуйте, Unforgiver, Вы писали: U>Ну скажем не всегда. Промышленное окружение от тестового всё же отличается.
Эндрю, отличается, есть такая беда. Скажу, что это характерно именно для больших компаний, которые всю политику определяют в центральном офисе. Да, там сидят прогеры и пишут очередной велосипед, который потом спускают в регионы. В регионах однако не только разная конфигурация оборудования, но и требования разные. Разумеется происходит нестыковка. Это больше проблема централизованного управления, чем разработки ПО. Вот чем Запад отличается, там нет «вертикали власти», соответственно каждое предприятие заказывает софт для себя в уникальной конфигурации. Потому там везде все компьютеризировано, потому что акционеры завтра скажут, нафик нам центровой офис будет диктовать условия, мы сами справимся, и они правы.
Здравствуйте, approach, Вы писали:
A>Архитекторы, которые не пришли к тестеру и не спросили, Вась, а Вась, посмотри, все ли тут можно затестировать, никогда не построят надежную и масштабированную систему.
Опять же на моей практике обычно долго приходится расжевывать тестерам как можно ту или иную функциональность протестировать . Чет прям все круто у вас.
К>Только не обижайся, я уверен, ты хороший тестер. Только следи за ЧСВ, может скакнуть.
Да, бывает такое, соглашусь, иной раз меня заносит...
M>Опять же на моей практике обычно долго приходится расжевывать тестерам как можно ту или иную функциональность протестировать . Чет прям все круто у вас.
Ну, если набирать тестеров по принципу «с паршивой овцы хоть шерсти клок», тогда да, так и происходит.
Впрочем характерно для российских компаний экономить на всем.
Я работаю в западной компании, поэтому подход заметно отличается, вижу как много кладется усилий для производства нормального кода, но репутация на западе превыше всего.
Здравствуйте, approach, Вы писали:
A>Юра, я же шучу, впрочем, в каждой шутке есть только доля шутки.
A>Вот давай завтра придешь на работу, открывай свой проект, выбирай любой класс, и вот сам для себя скажи, можно его затестировать? Если нет, значит в коде ошибка, сразу тебе говорю. A>Если класс нельзя тестануть с ходу, значит интерфейс выведен неверно, однозначно. Я разумеется не имею ввиду зависимые классы, которые должны мокаться в таких случаях.
вы в какой-то дремучей компании работаете.. никогда никто не слышал про TDD? про то как разработчики пишут юниттесты под каждый класс, еще до создания самого класса? да, архитектура получается интерфейсная, чтобы в любой момент все что нужно можно было заменить моками, но вы так расписываете это как будто это тайна за семью печатями и неведомая никому премудрость, в то время как это проза жизни и не более
A>Продолжу мысль. Разработчики, которые не понимают тестирование, никогда не пишут добротный код, увы. Архитекторы, которые не пришли к тестеру и не спросили, Вась, а Вась, посмотри, все ли тут можно затестировать, никогда не построят надежную и масштабированную систему. Возможность тестирования ПО говорит что архитектура выбрана верно, а это значит, что поддержка системы недорогая, расширение несложное и т.п. признаки грамотного ПО.
Продолжу и я мысль. учитывая что то чем вы занимаетесь входит в подмножество функций хорошего разработчика (обеспечивать покрытие тестами своего кода, поддержание проекта в состоянии когда его легко тестировать, етц), а не наоборот — вы, очевидно на уровень разработчика не вполне дотягиваете. выход из зоны комфорта, то-сё
Здравствуйте, approach, Вы писали:
A>Юра, я же шучу, впрочем, в каждой шутке есть только доля шутки.
Да ясное дело, неужели вы думаете тут кто-то всерьёз вам ответит?
A>Продолжу мысль. Разработчики, которые не понимают тестирование, никогда не пишут добротный код, увы. Архитекторы, которые не пришли к тестеру и не спросили, Вась, а Вась, посмотри, все ли тут можно затестировать, никогда не построят надежную и масштабированную систему.
Ну да, кто-же что может понимать в проектировании кроме тестировщика? Да и зачем эти архитекторы вообще нужны?..
Вот поговорим с ваими через пять лет: не будет ни архитекторов, ни техов, ни девелоперов, а будут одни сплошные тестировщики!
Я вот единственное чего не пойму: вы с Олимпа только нагрузочным тестированием занимаетесь. Что вам за дело до мелких людишек с их ничтожным юниттестированием?
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Здравствуйте, approach, Вы писали:
A>>Юра, я же шучу, впрочем, в каждой шутке есть только доля шутки.
YKU>Да ясное дело, неужели вы думаете тут кто-то всерьёз вам ответит?
A>>Продолжу мысль. Разработчики, которые не понимают тестирование, никогда не пишут добротный код, увы. Архитекторы, которые не пришли к тестеру и не спросили, Вась, а Вась, посмотри, все ли тут можно затестировать, никогда не построят надежную и масштабированную систему.
YKU>Ну да, кто-же что может понимать в проектировании кроме тестировщика? Да и зачем эти архитекторы вообще нужны?.. YKU>Вот поговорим с ваими через пять лет: не будет ни архитекторов, ни техов, ни девелоперов, а будут одни сплошные тестировщики!
В каждой шутке есть доля шутки. На деле роли все чаще смазываются. Разработчики участвуют в написании тестов, тестировщики (которые у нас уже изначально совмещают QA, QC и собственно тестирование) помимо своих задач совмещают роль аналитиков (вначале системных, потом бизнес) + с возможностью реверс-инжиниринга кода (особенно в случае легаси с минимумом документации), на определенных этапах есть пересечения. Например, спецификации представляют одинаковый интерес как для разработчиков, так и для тестировщиков, так как для обеих групп это служит отправной точкой, просто одни на основе спецификации пишут реализацию, а другие подготавливают процедуры проверки разрабатываемой системы на соответствие этим спецификациям. То есть происходит 2 параллельных потока. И поскольку у этих потоков требования и цели различаются, то объединения в одну общую группу в ближайшее время ожидать не приходится. Независимое тестирование еще не исчерпало свой ресурс. Но тенденция размытия сферы деятельности налицо. Так что скорее будет разделение на "светлых" и "темных".
. Чет прям все круто у вас.
