По поводу (2) и (3) думаю что спорить бесполезно. Наверное вы правы.
Я не работал над авиоционным или медицинским софтом, не знаю как там устроено.
Но мне сложно поверить, что некий человек, который не вовлечён в проект может быть главным отвественным за качество продукта.
Хотелось бы верить, что в вышеперечисленных областях все участники процесса разработки прекрасно понимают цену ошибки.
Сравнение QA/SEPG и тестирования — это тема, пожалуй, следующей статьи.
Позвольте дать совет. Сохраните свое время. Напишите лучше о чём-нибудь другом.
Да и Ваше замечание о том, что такой отдел «мешает» людям — это странно, т.к. деятельность его как раз таки направлена на то, чтобы эту жизнь улучшать.
Ничего странного. Как вы правильно заметили, такой отдел нужен когда несколько проектов. Но нужен ли? Обычно этим занимаются люди ничего не понимающие в каждом конкретном проекте. Не понимающие команду, не понимающие текущие сложности. Они стараются применить ко всем одинаковые практики, считать неработающие метрики.
Видел на практике две крайности. Отдел есть, что-то делает и никому от этого ни жарко ни холодно.
Вторая — отдел есть и наделён сильными полномочиями менять процесс, не взирая на то, что каждое следующее «улучшение» добавляет головной боли программистам, тестировщикам и другим людям нацеленным на «деливери».
Это конечно холиварная тема, именно поэтому и было бы интересно сделать круглый стол на эту тему на конференции.
Автор brutalko всё верно написал про единый code base.
По поводу перевода программиста в тестировщики. Сколько удачных примеров таких переходов в вашей карьере?
Что-то я не вижу толпы программистов, стоящих в очереди на перевод на (зачастую) менее денежную и менее (по их мнению) интересную работу. Если что, я знаю что это не так, но я и в тестировании поэтому и никуда пока не собираюсь.
Я работал с людьми переведенными из программистов в тестровщики. Думаю, что в 100% случаев это было нежелание уходить с насиженного места и страх не найти новой работы в хорошей компании.
Резюмируя. Только программист, сам захотевший работать в тестировании будет работать полезно. А вот держать в команде человека, спасающийся от увольнения в кризис перейдя на «менее пыльную» работёнку — не завидую команде и начальнику.
Могу порекомендовать пару софтверных лавок, где вам за ваши вопросы похлопают, покивают, а потом забьют на них и на вас. Да ещё и поговорят в духе «Ко мне опять этот умник приходил, парил про неправильные серийные номера».
А дальше хоть утестируйтесь. Даю волю вашей фантазии и «правильному видению процесса тестирования».
И ещё подумайте на тему работы над приложением, которое никому не нужно.
Где-то недавно пробегала фраза (по памяти цитирую): отсутствие или неумелое тестирование может загубить хороший проект, но супер-отличное тестирование не спасет изначально плохой проект.
С одной стороны есть много хороших и правильных замечаний, например про метрики. С другой — какие-то тестировщики-обезъяны накладывающие право вето на выпуск продукта.
С одной стороны правильные слова про HR и глупый поиск на соотвествие и знание инструмента. С другой — никому не нужные сравнения/противопоставления QA и тестирования, свойственные начинающим тестировщикам. Кто-нибудь где-нибудь в своей жизни видел отдел QA (или SEPG) который бы занимался только процессами и при этом, в лучшем случае, не мешал бы работать людям? Утопия.
С одной стороны совершенно точное замечание про несовершенные, неумелые отделы тестирования, которые дискредитируют сами себя. С другой — какой-то мифический QA Director, который должен «взять отвественность за качество» на себя, отобрав его у простого руководителя отдела тестирования. Где вы таких директоров видели? Если такой есть — то имхо, это должен быть первый кандидат на увольнение. В худшем случае он будет мешать процессу «деливери», стоя во главе банды обезъян и не давая поставить главную печать на продукт. Ну а в лучшем случае на него все забьют.
Ну а вообще статья занятная. Было бы любопытно по всей этой тематике круглый стол устроить где-нить на SQA Days или другой конференции.
«И, например, при желании программиста могли не уволить, а перевести в отдел тестирования, где бы он писал тесты.»
Вот одна из причин из-за которой о тестировщиках плохое мнение или суждение как о людях непрофессиональных. Программиста, которого отторгли другие программисты ни в коем случае нельзя пускать в тестирование. Скорее всего это человек некомпетентный, не склонный к развитию и безотвественный. Более того он уже не умеет тестировать.
Ой, а зачем вы так сложно iso на флэшку копировали по инструкции 3х летней давности?
Качаете iso и делате dd, как написано тут http://en.opensuse.org/SDB:Live_USB_stick
И без всякого шаманства у вас загрузочная флэшка openSuse.
Когда проект начинался он был бесплатный и можно было туда грузить музыку. А потом стало 15 треков в день или без ограничений, но за деньги. И не важно грузил ты туда музыку или нет.
При воспроизведении очень хочется ускорения, а не замедления. Много контента (полезного) хочется процентов на 20-30 ускорить. Например, видео с конференций, сразу все такие бодренькие становятся.
Спасибо. Вспомнился институтский курс по теории принятия решений. Очень нравилось решать подобные задачки.
Кстати у вас неточность в №3
«При А=0 данный критерий можно заменить критерием максимума, а при А=1 — критерием Вальда.» — исходя из формулы все в точности до наоборот.
Честно признаться даже не знаю огорчаться или радоваться. Пользуюсь этим клиентом уже около 8 лет. Не всегда новые версии были лучше старых, а последнее время, к сожалению, это стало тенденцией. То одна фича отвалится, то другая. Но даже не смотря на это thundirbird был и остается одним из лучших почтовиков.
Имхо, иногда не стоит вносить «псевдоулучшения» в угоду видимости того, что проект жив.
Поддерживаю про слово «компромисс». Преподаватель курса Assertive Communication, англичанка, говорила, что компромисс это одно из наихудших решений которое только кажется win-win, но при этом обе стороны, наоборот, оказываются неудовлетворенными. Со временем, чем больше компромиссов, эта неудовлетворенность накапливается, что в итоге может приводить к конфликтам.
Так что «компромисс» имеет негативный оттенок и в английском языке.
Зачем вы не понимая предмета пытаетесь меня в чём-то убедить? Только позоритесь, когда пишете ерунду. Уж поверьте человеку, который 7 лет работал над продуктами под названием ТСК.
Пожалуйста не читайте это. Автор все напутал про тестирование.
Я не работал над авиоционным или медицинским софтом, не знаю как там устроено.
Но мне сложно поверить, что некий человек, который не вовлечён в проект может быть главным отвественным за качество продукта.
Хотелось бы верить, что в вышеперечисленных областях все участники процесса разработки прекрасно понимают цену ошибки.
Позвольте дать совет. Сохраните свое время. Напишите лучше о чём-нибудь другом.
Ничего странного. Как вы правильно заметили, такой отдел нужен когда несколько проектов. Но нужен ли? Обычно этим занимаются люди ничего не понимающие в каждом конкретном проекте. Не понимающие команду, не понимающие текущие сложности. Они стараются применить ко всем одинаковые практики, считать неработающие метрики.
Видел на практике две крайности. Отдел есть, что-то делает и никому от этого ни жарко ни холодно.
Вторая — отдел есть и наделён сильными полномочиями менять процесс, не взирая на то, что каждое следующее «улучшение» добавляет головной боли программистам, тестировщикам и другим людям нацеленным на «деливери».
Это конечно холиварная тема, именно поэтому и было бы интересно сделать круглый стол на эту тему на конференции.
По поводу перевода программиста в тестировщики. Сколько удачных примеров таких переходов в вашей карьере?
Что-то я не вижу толпы программистов, стоящих в очереди на перевод на (зачастую) менее денежную и менее (по их мнению) интересную работу. Если что, я знаю что это не так, но я и в тестировании поэтому и никуда пока не собираюсь.
Я работал с людьми переведенными из программистов в тестровщики. Думаю, что в 100% случаев это было нежелание уходить с насиженного места и страх не найти новой работы в хорошей компании.
Резюмируя. Только программист, сам захотевший работать в тестировании будет работать полезно. А вот держать в команде человека, спасающийся от увольнения в кризис перейдя на «менее пыльную» работёнку — не завидую команде и начальнику.
А то, что вы напридумывали про меня. Вы ошиблись во всём. Ну что ж. Живите в мире своих иллюзий, но меня, пожалуйста туда не тащите.
На сём закончу непродуктивный разговор.
Могу порекомендовать пару софтверных лавок, где вам за ваши вопросы похлопают, покивают, а потом забьют на них и на вас. Да ещё и поговорят в духе «Ко мне опять этот умник приходил, парил про неправильные серийные номера».
А дальше хоть утестируйтесь. Даю волю вашей фантазии и «правильному видению процесса тестирования».
И ещё подумайте на тему работы над приложением, которое никому не нужно.
С одной стороны есть много хороших и правильных замечаний, например про метрики. С другой — какие-то тестировщики-обезъяны накладывающие право вето на выпуск продукта.
С одной стороны правильные слова про HR и глупый поиск на соотвествие и знание инструмента. С другой — никому не нужные сравнения/противопоставления QA и тестирования, свойственные начинающим тестировщикам. Кто-нибудь где-нибудь в своей жизни видел отдел QA (или SEPG) который бы занимался только процессами и при этом, в лучшем случае, не мешал бы работать людям? Утопия.
С одной стороны совершенно точное замечание про несовершенные, неумелые отделы тестирования, которые дискредитируют сами себя. С другой — какой-то мифический QA Director, который должен «взять отвественность за качество» на себя, отобрав его у простого руководителя отдела тестирования. Где вы таких директоров видели? Если такой есть — то имхо, это должен быть первый кандидат на увольнение. В худшем случае он будет мешать процессу «деливери», стоя во главе банды обезъян и не давая поставить главную печать на продукт. Ну а в лучшем случае на него все забьют.
Ну а вообще статья занятная. Было бы любопытно по всей этой тематике круглый стол устроить где-нить на SQA Days или другой конференции.
Вот одна из причин из-за которой о тестировщиках плохое мнение или суждение как о людях непрофессиональных. Программиста, которого отторгли другие программисты ни в коем случае нельзя пускать в тестирование. Скорее всего это человек некомпетентный, не склонный к развитию и безотвественный. Более того он уже не умеет тестировать.
Качаете iso и делате dd, как написано тут http://en.opensuse.org/SDB:Live_USB_stick
И без всякого шаманства у вас загрузочная флэшка openSuse.
Кстати у вас неточность в №3
«При А=0 данный критерий можно заменить критерием максимума, а при А=1 — критерием Вальда.» — исходя из формулы все в точности до наоборот.
Это сжатый пересказ его же книги The Clean Coder.
www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073
Достойная книга. Надеюсь, что будет всё больше людей, которые её прочитают и осознают.
Можете передать ожидаемую позицию результата и немного подправить метод CheckResults.
Автору респект, разложено по полочкам. Мог бы — плюсанул.
Имхо, иногда не стоит вносить «псевдоулучшения» в угоду видимости того, что проект жив.
Так что «компромисс» имеет негативный оттенок и в английском языке.