Comments 81
Ну поскольку человеческий фактор в разработке весьма немаловажен, то и простые житейские истины не повредят:
— не борзей («да я, да я ведущий разработчик, у меня все должно работать!» или наоборот — «да я ведущий спец по тестированию, у меня всё ломается!»))
— уважай чужую точку зрения
— умей подать и обосновать свою
(это применимо в обе стороны конечно же)
Ну и руководство не должно стравливать всякими соревнованиями типа «кто больше багов найдет», «кто больше пофиксит»…
— не борзей («да я, да я ведущий разработчик, у меня все должно работать!» или наоборот — «да я ведущий спец по тестированию, у меня всё ломается!»))
— уважай чужую точку зрения
— умей подать и обосновать свою
(это применимо в обе стороны конечно же)
Ну и руководство не должно стравливать всякими соревнованиями типа «кто больше багов найдет», «кто больше пофиксит»…
Дим, я бы еще проще сказал: процесс тестирования не должен напоминать перекидывание мячика через сетку…
Но, как ты помнишь по нашему совместному опыту (:), для этого еще и проектная документация должна быть нормальной, чтобы не было так, что тестер и разработчик постановку трактуют каждый по своему, а менеджер хочет третьего :)
Но, как ты помнишь по нашему совместному опыту (:), для этого еще и проектная документация должна быть нормальной, чтобы не было так, что тестер и разработчик постановку трактуют каждый по своему, а менеджер хочет третьего :)
В здоровом теле, здоровый дух. Банально, но как правило верно, ты прав.
Неужели нельзя чтоб не писать? Например если и П, и Т, и М будут присутсвовать при постановке задач?
Можно, чтоб не писать. В фразе «для этого еще и проектная документация должна быть нормальной» вместо слова «документация» следует читать «коммуникация».
:) а поддерживать потом сделанное — тоже через коммуникацию? а если П и М давно уволились или по другую сторону шарика отдыхает?
да и оберации сознания штука такая…
да и оберации сознания штука такая…
Документация есть средство поддержания коммуникации, позволяющее передавать некоторую информацию без искажений а) без искажений во времени, б) с возможностью многократного воспроизведения (это важно как для одного человека — можно перечитывать многократно, так и для большого количества людей — передача информации таким образом масштабируется).
1) Есть и другие способы передачи информации, которые тоже обладают указанными двумя характеристиками.
2) Документация всегда неполна, поэтому аберрации сознания просто переходят в область интерпретации текста.
1) Есть и другие способы передачи информации, которые тоже обладают указанными двумя характеристиками.
2) Документация всегда неполна, поэтому аберрации сознания просто переходят в область интерпретации текста.
:) а если их не трое — а пятеро? а если делаем что-то сложнее чем сайт из трех страничек, что еще и через год поддерживать кому-то надо будет?
Вообще-то можно устраивать такие соревнования, потому что это весело. Ну, как на локтях побороться или посоревноваться, кто дальше стрельнет вишнёвой косточкой. Плохо, если это переходит из разряда «просто соревнования» в «механизм управления».
Обычно это переходит как раз в «пинг-понг», как выразился dimas, либо между отделами либо внутри отдела — и то и другое крайне вредно для продукта/проекта (во всяком случае из моего опыта). А вот что-то типа — «давайте версию на неделю раньше срока выпустим» — уже теплее на мой взгляд. Но мною в «дикой природе» не встречено )
Собственно, тестировщики там ни при чем. Демарко привел их как пример «кристаллизации команды» — очень ценное и нужное явление.
Советы мощные.
Советы мощные.
Ага, а теперь возьмите двух-трех тестерш-блондинок и попробуйте донести до них эту мысль. Не получилось? Так какой же вы евангелист? :-)
Давайте сюда ваших блондинок, будем заниматься евангелизацией :)
Кстати да, тренеры, которые учат программистов или менеджеров, завидуют мне лютой завистью, потому что у меня обычно на тренингах прекрасной половины человечества минимум полгруппы :)
Кстати да, тренеры, которые учат программистов или менеджеров, завидуют мне лютой завистью, потому что у меня обычно на тренингах прекрасной половины человечества минимум полгруппы :)
Представляю себе Чёрную Команду, состоящую из тестерш-блондинок — валькирии!
По поводу блондинок вспомнилось. На одном из тренингов я давал задание придумать объяснение на понятном примере разницы между тремя понятиями — ошибка, дефект и сбой. Так вот, там была группка из трёх замечательных барышень, которые после непродолжительного обсуждения заявили, что они им сложно объяснить это на примере софта, зато они легко могут это объяснить на примере пришивания кармана на платье :)
Тестировщик — человек, который спросит менеджер о том, насколько хорошо поработал программист => программисту выгодно взаимодействовать с тестировщиком. =)
Только без заговоров. Кстати, следующий отрывок будет про то, как тестировщикам влиять на менеджеров :)
от такого подхода недалеко до того, что тестирование будет слабеньким…
с тестировщиков должны спрашивать за серьезные необнаруженные баги в релизе.
а уж они должны сами или совместно с разработчиками придумывать как их обнаруживать и, по возможности, автоматизировать это…
с тестировщиков должны спрашивать за серьезные необнаруженные баги в релизе.
а уж они должны сами или совместно с разработчиками придумывать как их обнаруживать и, по возможности, автоматизировать это…
Если баги не обнаружены, это плохо. Но плохо не только это, но и то, что они вообще сделаны. Так что это означает, что разработчики облажались не меньше, чем тестировщики.
Но плох тот тестировщик, который попытается в такой ситуации перевести стрелки на разработчиков, потому что они ему этого не простят. Они ждали от тестировщика защиты, а получили подставу.
Но плох тот тестировщик, который попытается в такой ситуации перевести стрелки на разработчиков, потому что они ему этого не простят. Они ждали от тестировщика защиты, а получили подставу.
О. Вот это тоже типичная ошибка, которая портит отношение в коллективе, а тем более между тестерами и разработчиками — кто больше виноват :)
Ошибки были, есть и будут, особенно в системах «с большим наследством»… Да и если бы их не было — тестеры бы были не нужны :)
Но защита разработчку тоже от тестера не нужна по сути, главное — чтобы противостояния и взаимных обвинений не было. В идеале то, конечно, хочется вообще сотрудничества — чтобы и разработчик мог внятно объяснить что в каких компонентах поменялось (или вообще какие трогали), а тестер мог не только внятно объяснить последовательность 100% воспроизведения ошибки, а то и помочь локализовать или хотя бы миннимизировать последовательность…
Ошибки были, есть и будут, особенно в системах «с большим наследством»… Да и если бы их не было — тестеры бы были не нужны :)
Но защита разработчку тоже от тестера не нужна по сути, главное — чтобы противостояния и взаимных обвинений не было. В идеале то, конечно, хочется вообще сотрудничества — чтобы и разработчик мог внятно объяснить что в каких компонентах поменялось (или вообще какие трогали), а тестер мог не только внятно объяснить последовательность 100% воспроизведения ошибки, а то и помочь локализовать или хотя бы миннимизировать последовательность…
О. Вот это тоже типичная ошибка, которая портит отношение в коллективе, а тем более между тестерами и разработчиками — кто больше виноват :)
Гм… Из моего комментария сложилось впечатление, что я рекомендую выяснять степень вины? Вообще-то я пытался высказать как раз противоположную мысль.
Но защита разработчику тоже от тестера не нужна (лишь бы не было противостояния)...
В идеале то, конечно, хочется вообще сотрудничества… а то и помочь локализовать или хотя бы миннимизировать
Мне кажется, или здесь действительно есть некоторое противоречие?
Гм… Из моего комментария сложилось впечатление, что я рекомендую выяснять степень вины? Вообще-то я пытался высказать как раз противоположную мысль.
Но защита разработчику тоже от тестера не нужна (лишь бы не было противостояния)...
В идеале то, конечно, хочется вообще сотрудничества… а то и помочь локализовать или хотя бы миннимизировать
Мне кажется, или здесь действительно есть некоторое противоречие?
Я работала над крупным проектом для московской мэрии. На строне заказчика был очень специфичный РМ. Когда выявлялась проблема, сразу начинали искать виноватых. Вопрос «что делать?» даже не поднимался. Интересовало только одно: «Кто виноват?».
Осёл тот руководитель, кто сталкивает лбами команду и ищет виноватых. Надо искать пути решения и вырабатывать превентивные меры. А искать виноватых — занятие бесполезное.
Осёл тот руководитель, кто сталкивает лбами команду и ищет виноватых. Надо искать пути решения и вырабатывать превентивные меры. А искать виноватых — занятие бесполезное.
*которого
Почему «программист» это правильное слово, а тестировщик подчеркивается, будто я в нём ошибку допустил?..
А может быть допустил?
Это специально сделано для того, чтобы тестировщик задал себе вышеприведённый вопрос. Для поддержания тонуса, так сказать. Чтобы не расслаблялся.
Это специально сделано для того, чтобы тестировщик задал себе вышеприведённый вопрос. Для поддержания тонуса, так сказать. Чтобы не расслаблялся.
Где-то было на днях, что в русском языке (его словарях) нет слова «тестировщик», а есть слово «тестер». А я вообще предложил слово «тестист» :)
человек, который использует слово «тестер» по отношения к тестировщикам, заведо зная определение этого слова в словарях(гляньте определение) — по меньшей мере поступает неуважительно.
Феликс, я использую и использовать буду. Ибо это калька с английского и ничего в ней нет плохого. И букв там меньше :)
Это все-равно, что говорить — «е-мэйл — это неправильно, а правильно электронная почта». Ну да, а все-равно говорим е-мэйл. И все главное понимают.
Это все-равно, что говорить — «е-мэйл — это неправильно, а правильно электронная почта». Ну да, а все-равно говорим е-мэйл. И все главное понимают.
Ну так имэйл то не обидится, а вот когда человека предметом называют…
То что кофе теперь это и ОНО — тоже все понимают, но грамотные люди положительно отмечают, когда собеседник использует именно форму ОН.
Кроме того, Леш, а тебе не кажется что «тестер» это как то скудно и ограниченно?
То что кофе теперь это и ОНО — тоже все понимают, но грамотные люди положительно отмечают, когда собеседник использует именно форму ОН.
Кроме того, Леш, а тебе не кажется что «тестер» это как то скудно и ограниченно?
Хороший аргумент, менеджеры вот тоже обиделись, когда я назвал класс TrashManager :) сразу вопрос «Ты кого конкретно имел в виду?»
Давно пора опрос собрать, кому обидно и кому нет. Мне не обидно, я горжусь тем что я тестер :) Да и работа с англоязычными заказчиками влияет — они не говорят testirovschick, они используют слово tester.
Я уже в одной ветке спрашивала, ты не ответил… Ты часто пишешь что это «обидно». Почему??
Я уже в одной ветке спрашивала, ты не ответил… Ты часто пишешь что это «обидно». Почему??
А каким словом, существующим в словарях русского языка, уважительно переводить английское слово «tester» в контексте лица, проводящего software testing? Проверщик? Испытатель?
1) в словарях Русского языка нет одного слова, которое бы полностью отражало всю деятельность тестировщика — но можно найти комбинацию из нескольких слов.
2) в деловой среде, например при описании вакансии, всегда пишут «Тестировщик».(если одним словом)
2) в деловой среде, например при описании вакансии, всегда пишут «Тестировщик».(если одним словом)
Ну, «специалист, занимающийся программированием компьютерных программ.», мягко говоря, тоже как-то не очень отражает всю деятельность программиста, особенно в вакансиях, где требуют «хорошее знание Photoshop и администрирование MS SharePoint» :). Плюс, ссылки на вакансии, по-моему, несколько некорректны, поскольку это должности, а не профессии/специальности.
да, давно уже тестирование — не сопутствующий, а обязательный процесс
в ряде компаний уже давно поняли, если нужен качественный софт — тестировать должны хорошие спецы, не глупее, чем разработчики и с не худшей производительностью, а это значит, что и не дешевле
в ряде компаний уже давно поняли, если нужен качественный софт — тестировать должны хорошие спецы, не глупее, чем разработчики и с не худшей производительностью, а это значит, что и не дешевле
Во многих компаниях на западе зарплата синьор инженера по качеству равна примерно 80-90% зарплаты синьор программера.
т.е. всё таки немного намекая, что они хоть на 10%, но недочеловеки?)
я наблюдал иное, особенно это видно по продуктовым компаниям — задача тестирования ПО в таких компаниях очень часто не ограничивается кликаньем, так как выходят новые версии и старый функционал тоже надо тестировать на множестве платформ — то становится актуальна задача автоматизации базовых тестов, т.е. тестировщики решают вполне себе разработческую задачу — как сделать процесс тестирования полноценным и на множестве платформ (т.е. ещё и не слабые админские знания). Плюс для продуктовых компаний качество продукта критичней чем затраты на его производство. Поэтому в таких компаниях зарплата сеньёра тестировщика == зарплате сеньёора программиста.
в частности на прошлом Microsoft Quality Assurance Day — Григорий Мельников сообщил о таком положении вещей в их команде. Подобное я наблюдал и в ряде перспективных СНГ компаний.
я наблюдал иное, особенно это видно по продуктовым компаниям — задача тестирования ПО в таких компаниях очень часто не ограничивается кликаньем, так как выходят новые версии и старый функционал тоже надо тестировать на множестве платформ — то становится актуальна задача автоматизации базовых тестов, т.е. тестировщики решают вполне себе разработческую задачу — как сделать процесс тестирования полноценным и на множестве платформ (т.е. ещё и не слабые админские знания). Плюс для продуктовых компаний качество продукта критичней чем затраты на его производство. Поэтому в таких компаниях зарплата сеньёра тестировщика == зарплате сеньёора программиста.
в частности на прошлом Microsoft Quality Assurance Day — Григорий Мельников сообщил о таком положении вещей в их команде. Подобное я наблюдал и в ряде перспективных СНГ компаний.
«т.е. всё таки немного намекая, что они хоть на 10%, но недочеловеки?)»
Они? Я сам один из них =)
Судя про зарплатам на просторах бывшего СССР, 10% разницы это очень хорошо. У нас часто бывает и 50%.
Они? Я сам один из них =)
Судя про зарплатам на просторах бывшего СССР, 10% разницы это очень хорошо. У нас часто бывает и 50%.
а я разработчик)
но и ваш случай тоже распространён, думаю в будущем эти случаи будут иметь место, но будут сильно разделены
т.е. ничего удивительного не будет в том, что у хороших тестеров зарплата порой будет и выше, чем у разработчиков, но при этом джуниоры и всякие кликатели — будут получать несравненно меньше разработчиков
но и ваш случай тоже распространён, думаю в будущем эти случаи будут иметь место, но будут сильно разделены
т.е. ничего удивительного не будет в том, что у хороших тестеров зарплата порой будет и выше, чем у разработчиков, но при этом джуниоры и всякие кликатели — будут получать несравненно меньше разработчиков
На мой взгляд тестирование программного продукта вещь очень интересная и очень важная.
Тестировщик, человек, который очень хорошо разбирается в ПО которое он тестирует, до конца понимает его бизнес и сценарии использования.
Имеет хорошее представление о используемых в ПО технологиях и их возможностях.
Подходит к тестированию проекта в какой то степени индивидуально в зависимости от бизнеса проекта. Без оглядки на прецеденты созданных на прошлых проектах.
Не загоняет свою работу в строгие рамки.
И еще очень очень много требований к человеку который будет отвечать за качество продукта…
Тестировщик, подумай перед тем как создать тикет, о том, стоит ли? не абсурдно ли твое умозаключение? Видишь ли ты вариант исправления (не приходи с проблемами, приходи с решениями/предложениями)?
Один из сотен ежедневных курьезов который вспомнился:
"… В Safari на Mac OS X на странице веб-приложения вертикальный скроллбар списка (реализованного через div с overflow:scroll) уже чем скроллбар документа..."
:)
Важно помнить что тестировщик и программист это часть одной комманды разработки ПО. Просто любите свое дело и будьте благоразумными.
Тестировщик, человек, который очень хорошо разбирается в ПО которое он тестирует, до конца понимает его бизнес и сценарии использования.
Имеет хорошее представление о используемых в ПО технологиях и их возможностях.
Подходит к тестированию проекта в какой то степени индивидуально в зависимости от бизнеса проекта. Без оглядки на прецеденты созданных на прошлых проектах.
Не загоняет свою работу в строгие рамки.
И еще очень очень много требований к человеку который будет отвечать за качество продукта…
Тестировщик, подумай перед тем как создать тикет, о том, стоит ли? не абсурдно ли твое умозаключение? Видишь ли ты вариант исправления (не приходи с проблемами, приходи с решениями/предложениями)?
Один из сотен ежедневных курьезов который вспомнился:
"… В Safari на Mac OS X на странице веб-приложения вертикальный скроллбар списка (реализованного через div с overflow:scroll) уже чем скроллбар документа..."
:)
Важно помнить что тестировщик и программист это часть одной комманды разработки ПО. Просто любите свое дело и будьте благоразумными.
>Видишь ли ты вариант исправления (не приходи с проблемами, приходи с решениями/предложениями)?
По голове за такое давать надо. Ибо есть золотое правило «приходишь ко мне с решением — в ответ получаешь проблему. Приходишь с проблемой — получаешь решение».
По голове за такое давать надо. Ибо есть золотое правило «приходишь ко мне с решением — в ответ получаешь проблему. Приходишь с проблемой — получаешь решение».
Комментарии, начинающиеся со слов «по голове за такое давать надо», сразу дискредетируют себя :)
По теме: в крупных компаниях, где контролю качества уделяется должное внимание, тестировщики всегда являются храниетелями информации о продукте наравне с аналитиками. Поэтому «приходить с решением» — это правильно. И естественно, речь не идёт о том «как решать» — т.е. лезть в код и учить разработчиков жить это, конечно, некошерно. Но объяснить, как правильно должен вести себя софт — это и важно и нужно.
По теме: в крупных компаниях, где контролю качества уделяется должное внимание, тестировщики всегда являются храниетелями информации о продукте наравне с аналитиками. Поэтому «приходить с решением» — это правильно. И естественно, речь не идёт о том «как решать» — т.е. лезть в код и учить разработчиков жить это, конечно, некошерно. Но объяснить, как правильно должен вести себя софт — это и важно и нужно.
По теме: спорно и зависит от конкретного дефекта. Общее правило тут: тестеры не должны подменять собой девелоперов/аналитиков/etc. Как сказано в статье из топика — тестеры это такой SaaS который дает представление о том насколько хорошо продукт решает бизнес задачи и указывает на конкретные _проблемы_ продукта.
«Общих правил» не существует. Совмещение отделов аналитики и тестирования — распространённая практика. Если в компании есть аналитики, и неизвестно, как исправлять дефект — то дефект должен заводиться на аналитика (чтобы где-то сохранить информацию о том что есть правильно). Зачастую аналитиков нет, и их роль выполняют тестеры.
Самые худшие дефекты — из серии «здесь что-то неправильно». Обычно разработчики подключают своё восприятие «правильности», фиксят, а потом оказывается, что время было потрачено зря и надо переисправлять.
Самые худшие дефекты — из серии «здесь что-то неправильно». Обычно разработчики подключают своё восприятие «правильности», фиксят, а потом оказывается, что время было потрачено зря и надо переисправлять.
просто иногда нужно давать специалистам нацепить шкуру другого: можно посадить программиста с тестировщиком и пускай программист указвает на моменты которые нужно тестить и наоборот, главное без фанатизма.
Товарищи авторы подобных статей, вы вообще когда нибудь программировали в команде большей чем 2 человека?
99% программистов идиоты, и пока их не будешь унижать, учиться писать качественно они не будут!!!
(не факт что будут и после, но в таком случае они хотя бы сорвутся и уйдут на более подходящую для их мозгов работу, например дворниками)
Оставшиеся 1% сами вас попросят «тестируйте тщательнее, и если я облажался ткните носом, причём жёстко чтоб я запомнил и не повторял»
99% программистов идиоты, и пока их не будешь унижать, учиться писать качественно они не будут!!!
(не факт что будут и после, но в таком случае они хотя бы сорвутся и уйдут на более подходящую для их мозгов работу, например дворниками)
Оставшиеся 1% сами вас попросят «тестируйте тщательнее, и если я облажался ткните носом, причём жёстко чтоб я запомнил и не повторял»
заставить критически смотреть на ошибки != унижать
А Вы себя к какой профессии причисляете, если не секрет? :)
Во-во, тоже не пойму, бред какой-то, я вот всегда рад найденному багу, поскольку это позволяет мне сделать мой код еще совершеннее. А если еще и есть человек, который их ищет, то вообще здорово.
Нашел еще один очень адекватный взгляд на эту тему со стороны программиста.
А еще Болтон проведет 19 ноября мастер-класс по исследовательскому тестированию в рамках конференции SQA Days-8, а также выступит с ключевым докдадом «Два взгляда в будущее тестирования программного обеспечения» («Two Futures of Software Testing»).
как программист исповедую следующий подход: тестеры это такие друзья которые хорошо делают работу которую я сам делать не люблю. Мне слишком нравится то, что я пишу, и нет никакого желания проверять как оно может сломаться. Мне скучно проверять все варианты, я подсознательно каждый раз думаю что в этом раз все хорошо — ведь я «предусмотрел все варианты».
Когда же приходят баги — первое что я делаю — говорю спасибо. Искренне. Мне помогли. Теперь у меня есть возможность сделать программу лучше.
Когда же приходят баги — первое что я делаю — говорю спасибо. Искренне. Мне помогли. Теперь у меня есть возможность сделать программу лучше.
>и изучайте код
и потом в запросах не фотографию ошибки высылать, а кусок кода с ошибкой и метод исправления!
Так постепенно тебя тоже в программисты возьмут)
и потом в запросах не фотографию ошибки высылать, а кусок кода с ошибкой и метод исправления!
Так постепенно тебя тоже в программисты возьмут)
Sign up to leave a comment.
Тестировщики, хотите знать, как положительным образом влиять на программистов?