Ну, я зачастую работаю Q&A. Темы все те же, улучшить качество кода. У нас кстати девы на свой код сами пишут тесты, а вот нагрузочные уже мы. Иногда приходится воспитывать разработчиков, особенно молодых, пару раз перепишет интерфейс, уже совсем по-другому к тестам относится. Про тимлидов и не говорю, мы для них боги. Пока мы не утвердим архитектуру, разработка не начинается. Писать хороший код надо научиться, время потратить, знания обрести, поэтому у нас в тестерах одни дедушки, всем уже за 40 и есть даже за 50. Не обсуждаем мы уже качество кода, студенческие споры неинтересны уже нам, а вот разнообразные тест тулы и фреймворки завсегда.
Здравствуйте, approach, Вы писали:
A>Ну, я зачастую работаю Q&A. Темы все те же, улучшить качество кода. У нас кстати девы на свой код сами пишут тесты, а вот нагрузочные уже мы. Иногда приходится воспитывать разработчиков, особенно молодых, пару раз перепишет интерфейс, уже совсем по-другому к тестам относится. Про тимлидов и не говорю, мы для них боги. Пока мы не утвердим архитектуру, разработка не начинается. Писать хороший код надо научиться, время потратить, знания обрести, поэтому у нас в тестерах одни дедушки, всем уже за 40 и есть даже за 50. Не обсуждаем мы уже качество кода, студенческие споры неинтересны уже нам, а вот разнообразные тест тулы и фреймворки завсегда.
Если это не гон, то хз где такое есть. У нас если у тестера достаточно мозгов, чтобы понять код, его при первой возможности переводят в программисты или в аналитики.
Ну…, тестирование это интересней, чем программирование! Сертификация от «Software Testing International Software Testing Qualifications Board (ISEB)». Грамотное тестирование это высокое качество кода. Мы пишем софт, который обслуживает строительные объекты, мосты, нефтяные платформы, авиацию. Такой софт должен точно прогнозировать технический осмотр, замену запчастей, ресурсы машин, колебания почвы, метеоусловия и т.д. Я думаю, теперь становится понятно, почему требуется такое качество кода. Все остальное тестирование от лукавого
Нет, не MS, небольшая софтверная компания с головным офисом в западной европе. Название широко известное только в узких кругах.
Здравствуйте, 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>Понимаю, но мы же все-таки за деньги работаем, и никаких личных прявязанностей.
Да ладно тебе, не грусти. Все и так все понимают.
Здравствуйте, approach, Вы писали:
A>Если софт прошел тестера, значит, претензий к нему не будет еще долго.
Ну скажем не всегда. Промышленное окружение от тестового всё же отличается. Вплоть до патчей на ОС и БД. Скилы тех, кто ставил софт — отличаются. У нас софт поставляется одному заказчику, но в разные регионы. И в каждом регионе на проде — свои баги! Такое подозрение, что местные сотрудники заказчика их культивируют
Всё заканчивается плохо. Если что-то закончилось хорошо — значит оно еще не закончилось.
