Comments 23
Ага, почти все это попадает под категорию, которую все любят писать в резюме — «ответственный».
По статистике врут. Ответственных в компании человека два-три. Они приближают ее существование к смыслу. Остальные — бабушка надвое сказала.
По статистике врут. Ответственных в компании человека два-три. Они приближают ее существование к смыслу. Остальные — бабушка надвое сказала.
Поздравляю, Вам не повезло с…
А, нет, извините. Вся разница в терминах — но дьявол, как всегда, в деталях. Тестировщик — не виноват. Виноват будет инженер по качеству. Равно как и в английском — QA и QE соответственно.
В крупных компаниях руководить отделом QA должен именно инженер. В маленьких, стремящихся выпустить Продукт (с большой буквы) — должен быть именно инженер.
Ну и немного поясню.
В данном случае инженер — это не уровень образования. Это уровень ответственности, уровень понимания того, что ты за любую дошедшую до конечного пользователя ошибку отвечаешь в бОльшей мере, чем программист.
Самое забавное — от таких работников программисты взвывают и плачут. Ну кому придет в голову регистрировать в базе Иисуса Христа с датой рождения 01.01.00? А Иоанна Крестителя с отрицательным годом рождения? А человека с именем из пяти алфавитов, включая тайский? А проверить каждое поле на смесь направления написания на английском и иврите? А...? А...?
Мы искали такого специалиста полгода. Нашли. Человек почти год учится, успехи — очень хорошие. В итоге баги по проектам от клиентов идут настолько специфичные — что тут скорее поверишь в фазу луны… Ну или сбои в железе. Кстати, что приятно — даже такие баги повторить на локальной установке инженер зачастую сможет — и сможет быстрее, чем сисадмин или автор кода.
Попробуйте, поищите :) Я в эту специальность пришел 5 лет назад — на смешной килобакс. С тем же мизерным опытом — но с огромной злостью на всех тех криворуких, кто писал и проверял код в том ПО, что я использовал повседневно. И как ведущий инженер по качеству — гарантирую: то, что прошло через наш отдел — будет работать близко к идеалу. С той же поправкой на фазу луны и сбои железа :)
А, нет, извините. Вся разница в терминах — но дьявол, как всегда, в деталях. Тестировщик — не виноват. Виноват будет инженер по качеству. Равно как и в английском — QA и QE соответственно.
В крупных компаниях руководить отделом QA должен именно инженер. В маленьких, стремящихся выпустить Продукт (с большой буквы) — должен быть именно инженер.
Ну и немного поясню.
В данном случае инженер — это не уровень образования. Это уровень ответственности, уровень понимания того, что ты за любую дошедшую до конечного пользователя ошибку отвечаешь в бОльшей мере, чем программист.
Самое забавное — от таких работников программисты взвывают и плачут. Ну кому придет в голову регистрировать в базе Иисуса Христа с датой рождения 01.01.00? А Иоанна Крестителя с отрицательным годом рождения? А человека с именем из пяти алфавитов, включая тайский? А проверить каждое поле на смесь направления написания на английском и иврите? А...? А...?
Мы искали такого специалиста полгода. Нашли. Человек почти год учится, успехи — очень хорошие. В итоге баги по проектам от клиентов идут настолько специфичные — что тут скорее поверишь в фазу луны… Ну или сбои в железе. Кстати, что приятно — даже такие баги повторить на локальной установке инженер зачастую сможет — и сможет быстрее, чем сисадмин или автор кода.
Попробуйте, поищите :) Я в эту специальность пришел 5 лет назад — на смешной килобакс. С тем же мизерным опытом — но с огромной злостью на всех тех криворуких, кто писал и проверял код в том ПО, что я использовал повседневно. И как ведущий инженер по качеству — гарантирую: то, что прошло через наш отдел — будет работать близко к идеалу. С той же поправкой на фазу луны и сбои железа :)
И, кстати, совсем забыл сказать.
Самое большое зло — люди, которые приходят на работу со знанием всех парадигм тестирования, легко оперируют терминами «дымовое», Agile и так далее. Лучший вопрос на фразу «Я хорошо знаю Agile-методы» — «А вы пробовали набрать этот термин в русской раскладке?» (Спойлер: получится Фпшду).
Могу дать даже полтора совета по найму человека, из которого можно вырастить Инженера:
— берите человека, который никогда не работал по этой специальности. Поверьте, хорошего инженера по качеству сманить с насиженного места тяжелее, чем программиста,
— не верьте в дипломы о профильном образовании. В нашей стране не учат на эту специальность — это тоже призвание в первую очередь.
— если в команде есть уже Инженер — дайте претенденту на вакансию тестовое задание в той области, которую он не знает. На неделю. За неделю справится — умеет учиться. Научим.
— если нет — тоже дайте. Проверьте. Только учить придется самим. Всей толпой, да. Как учили меня. Тут, кстати, будет действовать ваша правда — покажите человеку Ваш пост, поясните, ПОЧЕМУ это неправильно. За месяц испытательного срока поймете, способен ли он стать тем, что я написал выше.
— не стесняйтесь увольнять тех, кто не прошел. Хреновый программист — это терпимо. Пиная его в нужном направлении (а это уже задача ведущего по проекту) — можно получить Продукт. Но направление пинания должен задавать Инженер по качеству — и code review, да.
— и самое главное — научите себя. Этот инженер прикрывает вашу спину. Он будет отвечать за все ваши ошибки раньше вас. Если он пришел с чем-то, что он делает не так — покажите и объясните. Да, программисты не любят писать подробные инструкции. Но если QE говорит, что ему непонятен один момент, очевидный для вас — поверьте, конечному пользователю это будет еще менее очевидно.
Самое большое зло — люди, которые приходят на работу со знанием всех парадигм тестирования, легко оперируют терминами «дымовое», Agile и так далее. Лучший вопрос на фразу «Я хорошо знаю Agile-методы» — «А вы пробовали набрать этот термин в русской раскладке?» (Спойлер: получится Фпшду).
Могу дать даже полтора совета по найму человека, из которого можно вырастить Инженера:
— берите человека, который никогда не работал по этой специальности. Поверьте, хорошего инженера по качеству сманить с насиженного места тяжелее, чем программиста,
— не верьте в дипломы о профильном образовании. В нашей стране не учат на эту специальность — это тоже призвание в первую очередь.
— если в команде есть уже Инженер — дайте претенденту на вакансию тестовое задание в той области, которую он не знает. На неделю. За неделю справится — умеет учиться. Научим.
— если нет — тоже дайте. Проверьте. Только учить придется самим. Всей толпой, да. Как учили меня. Тут, кстати, будет действовать ваша правда — покажите человеку Ваш пост, поясните, ПОЧЕМУ это неправильно. За месяц испытательного срока поймете, способен ли он стать тем, что я написал выше.
— не стесняйтесь увольнять тех, кто не прошел. Хреновый программист — это терпимо. Пиная его в нужном направлении (а это уже задача ведущего по проекту) — можно получить Продукт. Но направление пинания должен задавать Инженер по качеству — и code review, да.
— и самое главное — научите себя. Этот инженер прикрывает вашу спину. Он будет отвечать за все ваши ошибки раньше вас. Если он пришел с чем-то, что он делает не так — покажите и объясните. Да, программисты не любят писать подробные инструкции. Но если QE говорит, что ему непонятен один момент, очевидный для вас — поверьте, конечному пользователю это будет еще менее очевидно.
UFO just landed and posted this here
… но качественное ПО должно отработать любой некорректный ввод от пользователя…
Зависит от очень многих обстоятельств. Финансы, область ПО, состояние команды, темпы добавления функциональности и пр. Одно дело когда пишется ПО для космической программы или медицинского оборудования, когда ошибки недопустимы или будут стоит огромных денег после выпуска продукта. И совершенно другое когда это сайт или десктопная игрушка. Исправление ошибок ест ресурсы разработчиков. Решение на что важнее, использовать эти ресурсы на «ПО должно отработать любой некорректный ввод от пользователя» или «ПО должно развиватся чтобы угнатся за конкурентами, или уложится в нужные бизнесу сроки» принимается в зависимости от текущей ситуации.
Качество состояние не бинарное, либо качественный либо нет.
Просто не люблю категоричность. Гибче надо быть, не бывает абсолютных правил тут.
Качество состояние не бинарное, либо качественный либо нет.
Просто не люблю категоричность. Гибче надо быть, не бывает абсолютных правил тут.
«А проверить каждое поле на смесь направления написания на английском и иврите? А...? А...? » — а это нужно продукту? А сколько будет стоить разработка функционала который закроет этот «баг»? Какой функциональностью придется пожертвовать или на сколько отложить сроки запуска продукта?
Если продукт должен поддерживать иврит, или арабский способ ввода — это должно быть в требованиях, и любому тестировщику должно придти в голову проверить это. Нет тут ничего особенного, геиального и героического. А если не должен — то вы как минимум этим «багом» зря потратили свое время и украли 10-30 минут работы менеджера и/или разработчика (если «баг» не будут править) или значительно больше, и смешали все планы (если будут).
Если вы считаете что ПО должно поддерживать иврит (или видите что просто забыли об этом), нужно добитьсяб чтобы это добавили в требования (если есть возможность), до разработки.
Так что ничего удивительного, что разработчики взвывают и плачут от таких работников и таких «багов», а фактически неописанных (и иногда бесмысленных) требований. За редкими исключениеми, конечно, эти «баги» только отвлекают от работы и не стоят потраченного на них времени. Я не призываю не проводить негативное тестирование, но когда оно становится целью тестировщика это печально. Если речь не идет конечно о критических к ошибкам областях.
Если продукт должен поддерживать иврит, или арабский способ ввода — это должно быть в требованиях, и любому тестировщику должно придти в голову проверить это. Нет тут ничего особенного, геиального и героического. А если не должен — то вы как минимум этим «багом» зря потратили свое время и украли 10-30 минут работы менеджера и/или разработчика (если «баг» не будут править) или значительно больше, и смешали все планы (если будут).
Если вы считаете что ПО должно поддерживать иврит (или видите что просто забыли об этом), нужно добитьсяб чтобы это добавили в требования (если есть возможность), до разработки.
Так что ничего удивительного, что разработчики взвывают и плачут от таких работников и таких «багов», а фактически неописанных (и иногда бесмысленных) требований. За редкими исключениеми, конечно, эти «баги» только отвлекают от работы и не стоят потраченного на них времени. Я не призываю не проводить негативное тестирование, но когда оно становится целью тестировщика это печально. Если речь не идет конечно о критических к ошибкам областях.
Это не моеИнициатива наказуема) Но вообще, если у вас есть время поработать за Колю или Самару, то почему бы нет
Разработчик сказал, что так и задуманоА про требования слышали?) Или откуда разработчик знает, что так задумано?
Оно не работало, но вдруг заработало — видимо все в порядкеЕсли проблема не воспроизводится, то это не проблема
У разработчиков проблема не повторяетсяА вам какое дело? Показали в своём окружении (даже видео можно снять), пусть разработчики и разбираются.
Да ну, еще такую ерунду репортитьА за что вам индекс (коэффициент) трудового участия добавляют? За воспроизводимые проблемы, наверное.
С чего бы это ему не работать на другом движке БД, другой ОС?Выше было про требования…
Было непонятно, но разработчик объяснилТак это разработчик пользоваться продуктом будет? Или может заказчик, который тоже не сразу разберётся?
Фича? Я проверил, кнопка работает, все в порядкеДа, да, сценарий использования тестер сам придумал, требований-то нет.
> А вам какое дело? Показали в своём окружении (даже видео можно снять), пусть разработчики и разбираются.
Со всем согласен кроме этого, если тестировщик не может воспроизвести ошибку на других станциях — почему этим должен заниматься программист?
Со всем согласен кроме этого, если тестировщик не может воспроизвести ошибку на других станциях — почему этим должен заниматься программист?
Вообще это вопрос ответственности. Но у программиста больше возможностей понять причину возникновения ошибки.
Канер рассказывает, что их разработчики чинили четыре из пяти «у меня не воспроизводится».
А техническое решение проблемы — отдавать программистам снапшот системы(вместе с операционкой), на которой воспроизводится дефект. Жаль, не всегда возможно.
Канер рассказывает, что их разработчики чинили четыре из пяти «у меня не воспроизводится».
А техническое решение проблемы — отдавать программистам снапшот системы(вместе с операционкой), на которой воспроизводится дефект. Жаль, не всегда возможно.
У программиста, возможно, больше причин понять проблему, но вешать на него все ошибки (включая некритические), которые не может понять/воспроизвести тестировщик — зачем тогда тестировщик нужен? Можно сразу переправлять все ошибки пользователя. Утрированно, но все же
Тестировщик не может воспроизвести в собственном окружении — я бы повесил баг на него до повторения. Программист тут разве что советом помось может.
Тестировщик видит проблему и может повторить, но не понимает, что/как происходит, — тут уже и программиста не грех привлечь вплотную. Или — сесть вместе разбираться: программист лучше знает кишки продукта, а тестировщик — тестового окружения. Вместе справятся.
Тестировщик видит проблему и может повторить, но не понимает, что/как происходит, — тут уже и программиста не грех привлечь вплотную. Или — сесть вместе разбираться: программист лучше знает кишки продукта, а тестировщик — тестового окружения. Вместе справятся.
> Тестировщик не может воспроизвести в собственном окруженииНо тут ситуация когда тестировщик проблему не может повторить на другой машине (хотя бы одной единственной — той, что у разработчика) — кто ответственный?
Отправил случайно.
> Тестировщик видит проблему и может повторить, но не понимает, что/как происходит
Ну тут явно уже можно вешать на программиста, верно
> сесть вместе разбираться: программист лучше знает кишки продукта, а тестировщик — тестового окружения
А тут уже вопрос критичности ошибки/бага
> Тестировщик видит проблему и может повторить, но не понимает, что/как происходит
Ну тут явно уже можно вешать на программиста, верно
> сесть вместе разбираться: программист лучше знает кишки продукта, а тестировщик — тестового окружения
А тут уже вопрос критичности ошибки/бага
>>Инициатива наказуема
Человек должен знать, «чье это», если это не его. По крайней мере, должен существовать некий централизованный источник данных об ответственностях. Менеджер, эксель-табличка, файл из проджекта, список тасков в ишью-трекере — неважно, но источник быть должен.
>>А про требования слышали?) Или откуда разработчик знает, что так задумано?
Разница между «так в требованиях» и «разработчик сказал» — огромная. У QA должна быть спека требований и он должен её интерпретировать сам, а не со слов разработчика.
>>Если проблема не воспроизводится, то это не проблема
Нет, это проблема. Пусть и не с большим приоритетом. Забыв о ней, есть шанс нарваться на проблемы после, в случае, если она, например, скапливается с «накапливающейся погрешностью», например, с медленно текущей памятью.
Человек должен знать, «чье это», если это не его. По крайней мере, должен существовать некий централизованный источник данных об ответственностях. Менеджер, эксель-табличка, файл из проджекта, список тасков в ишью-трекере — неважно, но источник быть должен.
>>А про требования слышали?) Или откуда разработчик знает, что так задумано?
Разница между «так в требованиях» и «разработчик сказал» — огромная. У QA должна быть спека требований и он должен её интерпретировать сам, а не со слов разработчика.
>>Если проблема не воспроизводится, то это не проблема
Нет, это проблема. Пусть и не с большим приоритетом. Забыв о ней, есть шанс нарваться на проблемы после, в случае, если она, например, скапливается с «накапливающейся погрешностью», например, с медленно текущей памятью.
Хочу написать о приоритетах тестирования. Тестировщики большую часть времени тратят как раз на поиск маловероятных багов. Вроде смешанного ввода латиницы и иврита. Только вот забывают проверить наиболее часто встречающиеся строки на целевом алфавите.
Забывают, что всегда, в первую очередь, надо проводить позитивное тестирование. Надо проверять, чтобы самое важное и используемое работало. А только потом, если останется время, можно пофантазировать и удивлять разработчиков знанием дизасемблера и падениями программы при изменении значения в ячейке памяти. Такие баги никому не нужны. Тестировщики тратят свое время, время менеджмента и время программистов на решение маловероятных ошибок.
Если система должна работать на x32, то не нужно ее тестировать на солярке или win 8 x64!
Забывают, что всегда, в первую очередь, надо проводить позитивное тестирование. Надо проверять, чтобы самое важное и используемое работало. А только потом, если останется время, можно пофантазировать и удивлять разработчиков знанием дизасемблера и падениями программы при изменении значения в ячейке памяти. Такие баги никому не нужны. Тестировщики тратят свое время, время менеджмента и время программистов на решение маловероятных ошибок.
Если система должна работать на x32, то не нужно ее тестировать на солярке или win 8 x64!
С одной стороны — позитивный сценарий обязан работать, когда фича пришла в тестирование.
С другой — с тестировщиков это ответственности не снимает. Помогайте расставлять приоритеты. Пусть тестировщики показывают high-level план тестирования фичи разработчикам (аналитикам, и прочим заинтересованным лицам) — это всегда полезно.
С другой — с тестировщиков это ответственности не снимает. Помогайте расставлять приоритеты. Пусть тестировщики показывают high-level план тестирования фичи разработчикам (аналитикам, и прочим заинтересованным лицам) — это всегда полезно.
Мне вас жаль, вы никогда не встречали хороших тестировщиков, у которых такие проблемы не возникают.
Некоторые пункты хочется распечатать и повесить на стенку около тестеров. Надеюсь, они не читают этот коммент.
Так же можно написать статью «Легкий способ провалить программирование». Я сам работаю в QA, — и у нас в команде ниразу не слышал подобной околесицы. Не повезло вам с коллегами, увы.
А шО сразу Самара?
Sign up to leave a comment.
Легкий способ провалить тестирование