QA в Германии
Все сгрудили в одну кучу под названием DevOps с непрерываным процессом движения к совершенству. Нет продукта, нет релизов - есть непрерывное привинчивание новых фич, отвинчивание старых и шлифовка существующих.
Это вы что-то в DevOps недопоняли. Никто не мешает делать релизы, никто не запрещает QA. Наоборот, в DevOps команду предлагают включать и QA инженеров.
DevOps просто решение, помогающее уменьшить разногласия между разработчиками и операторами. Не больше.
я думаю прежде чем спрашивать о QA, надо спросить, сколько фирм получали хотябы нормальные описания того, что надо сделать:-) т.е. прежде чем проверять качество, надо знать что требуется. а зачастую, в 90% (из опыта) заказчики не знают что хотят. какой же тут QA?!
О, да! С этим согласна на 100%. Считаю размытые требования основной проблемой на нашей фирме. Клиенты вроде все солидные, но не утруждают себя подбробной датализацией требований. А потом оказывается, что вот тут-то должно быть так, а не этак. Частично удается списать это на них самих.
Бывает, что заказчик знает, что хочет. Но потом оказывается, что это знание было неверным. Был такой случай. Сделали все точь-в-точь, как хотел заказчик. Потом приходит баг, почему это действие запрещено?! Пришлось тыкать носом в ими же написанное требование, что этой действие должно быть запрещено. Они согласились, все исправления были оплачены. А потом выкатили запрос на новую фичу, чтобы все запреты и разрешения должны быть с возможностью конфигурации 
или бывает так, что хотят чего-то, говоришь им, вы вот это не продумали, и вот это, и вот это. ответ: этого не будет. а потом выясняется. все будет. бывает немножко по другому, а бывает точь в точь как говорил - но будет.
другой случай: приходят - не работает. спрашиваешь. обясняют. говоришь: это не было затребовано. заказчик: но вот здесь же так работает! и муторно часами пытаешься объяснить, что то что не было оговорено и работает, случайно, так как хотели, это еще не оправдывает выводов, что в этом же месте, но с другими данными, будет работать, так как ожидает заказчик.
так что прежде чем o QA, говорить, надо сначала про RE говорить. уже на этом уровне не всегда работет.
Ага, с RE у многих проблемы. И как это улучшить, понятия не имею. Я со своей стороны во время фазы оценки пинаю менеджеров, чтобы проясняли моменты с клиентами. Но в Германии все таки мееееедленно, что оценочная фаза уже заканчивается, а фидбека так и нет.
Ага, с RE у многих проблемы. И как это улучшить, понятия не имею.
Как-то у меня был такой удачный опыт. Когда я увидел, что задача слишком мутно описана, удалось договориться с заказчиком, что мы начнём работу над ней только у него в офисе, он нам предоставит два рабочих места и ежедневные личные встречи с ним и его специалистами. В результате, удалось за неделю все уточнить до приемлемого уровня и подписать у него этот документ. То есть, справиться с качеством постановки задачи удалось организационными мерами. Если бы стали переписываться - не закончили бы просто никогда.
Для этого существует Anforderungsmanagement.
это понятно, что он существует или точнее должен бы существовать:-)
и как с этим? т.е. я и имел в виду, что если RE нет, то откуда QA возьмется.
То есть, справиться с качеством постановки задачи удалось организационными мерами. Если бы стали переписываться - не закончили бы просто никогда.
У нас выезжают к клиенту редко. Ну когда петух в одно место клюнет, то да, выезжают. Как в последний раз. Фичу реализовали, но столько багов потом получили, что поехали все лично разъяснять. Но случается, что и письмами удается все необходимое выяснить. А если не удается получить обратную связь вовремя, то тупо пишем, как это будет реализовано и точка 
Это все же разные вещи. Например, в моей теперешней фирме RE есть, да еще какой :)
На самом деле, QA тоже есть, но не в тех проектах, в которых я работаю.
я имел в виду, что если нет маломальского RE, то про QA можно забыть. чего проверять если не задано как должно быть?
я работаю в QA
Обстоят так, что когда-то (лет десять назад) таки не было. А потом постепенно заказчики возмутились, что поставляем говно и потребовали завести. Завели, но оно какое-то самодеятельное. Пару человек на сдачу одного проекта нанимали, кьюэй профи, так это - действительно видно, что профи: подготовка, порядок, все задокументировано, запротоколировано, в общем - смотри и удивляйся.
С тех пор - только свои "неучи". Прочел сам пару книжек умных, приспособился пользоваться майкрософтовским PICT, с тех пор у меня ошибок практически не находили, мне было это интересно.
И как в QA работается?
Я слышал, что зарплаты меньше, чем у разработчиков, но сама работа попроще. Это правда?
Не думаете переводиться на девелопера? Опять же слышал, что это обычная практика после нескольких лет работы в QA.
Спрашиваю, так как у самого близится окончание мастера, специальность Информатика, нужно будет лихорадочно искать работу, а опыта работы программистом толкового нет. Вот и думаю, идти в QA или девелопером :-(
слышал, что это обычная практика после нескольких лет
-----
А потянет?
Уровень знаний и навыков у QA... хммм... скажем мягко - специфический...
Способ мышления - тоже. С разработкой - могут и не справится.
Я бы несколько раз подумал, прежде чем брать QA разрабом... и все же - скорее всего не взял... но это - мой взгляд на ситуацию.
опыта работы программистом толкового нет
-----
Ну значит тебе быть рабом... не QA, не разрабом, а просто рабом... пока не поймешь как зарабатываются деньги на ИТ...
Я в IT более десяти лет, проблема лишь в том, что не в местном европейском IT, а в презренном всеми 1С, о которой здесь ни сном ни духом.
Конечно, точки соприкосновения есть и голова работает правильно, но отсутствие практического опыта с какими-либо вообще технологиями, здесь распространенными, кроме университетских проектов на Java - считаю большим минусом.
Вот и думаю: завтра диплом будет на руках, что делать?
что делать?
-----
Так Я тебе уже ответил - быть РАБом. В прямом смысле слова РАБ - подневольное,
принуждаемое работать на условиях владельца. И если останешься в ИТ - ты им и
будешь.
Ровно до того момента, пока не поймешь...
Я в IT более десяти лет ... 1С
-----
Ну а Я с паяльником лет с 6-7-ми... в те годы еще транзисторы были в диковонку...
Так что поработал со всяким хламом... а вот с 1С - не случилось - когда предлагали,
то поставили условие - на своей технике, со своими клиентами... со стороны конторы
- документация и лицензия на 1С... изучать - самостоятельно... на этом и не срослось.
Зато поработал со всякими разными экзотическими системами и технологиями. Но не
со всеми... все - слишком много...
Если думаешь программить - садись за самые последние разработки мелкомягких...
и не забывай об том что есть и другие. Но это - не быстро... лет через пять будешь
знать то, что сейчас актуально... разумеется, на тот момент все будет уже заменено
и надо будет изучать новье... ну это - обычное дело - это не 10 лет на 1С...
П.С. Одной Жабой - не обойдешься. Без 4-х... а то и 5-ти... разных языков сейчас
ничего не делается...
Одной Жабой - не обойдешься. Без 4-х... а то и 5-ти... разных языков сейчас ничего не делается...
Больше пиши, неча бусурман жалеть. Кто знает только 5 языков тот лошара! Без 27 языков ни один проект не делается, даю вам честное, благородное слово!
Номальный разработчик спокойно проживет зная только яву.
Номальный разработчик спокойно проживет зная только яву.
Это от проекта и величины компании зависит. Некий РАБ или безумный одиночка может быть и должен знать 5 языков, чтобы все тянуть самому. А крупные компании свои крупные продукты сопровождают десятки лет на "старых" языках и технологиях, и в ус не дуют.