Comments 29
Хорошая статья.
Кратко: уважайте друг друга, и не хамите.
Кратко: уважайте друг друга, и не хамите.
Отдел обеспечения качества (QA) занимается поиском багов в ПО.
а отдел разработки по такой логике занимается созданием багов в ПО?
Вообще, да. Вы хотите сказать, что кто-то кроме разработчиков в состоянии внести баги в ПО?)
дизайнеры, бизнес-аналитики…
UFO just landed and posted this here
Интересно было бы услышать пример, как дизайнеру внести баг в ПО. Только если дизайнер не знаю, сам клиентской версткой не занимается, и таким образом, не создает код.
Если что, в моем понимании «косяк проектирования/юзабилити» != «баг». Т.е. то что в макете кнопка ховером не отмечена — я бы багом не назвал. Если дело только в этом, тогда могу согласиться с вами)
Если что, в моем понимании «косяк проектирования/юзабилити» != «баг». Т.е. то что в макете кнопка ховером не отмечена — я бы багом не назвал. Если дело только в этом, тогда могу согласиться с вами)
в моем понимании косяк проектирования… != «баг».
Любая логическая ошибка в приложении — это косяк проектирования, на то или ином уровне абстракции.
Опечатка? В чем косяк проектирования?
Я про то, что обычно вполне конкретный человек получает
-макеты от дизайнера
-спеки аналитика
-DoD-ы от продакт оунера
и именно он воплощает ошибки в программе)
Ни разу не слышал чтобы просчеты на этапе постановки задачи кто-то называл «баги», это именно косяки, просчеты, ошибки проектирования, и тп.
«баг дизайна?» если у вас такой существует — то тогда я просто мягко с вами соглашусь и не буду дальше спорить, вопрос только в терминологии и не более.
Я про то, что обычно вполне конкретный человек получает
-макеты от дизайнера
-спеки аналитика
-DoD-ы от продакт оунера
и именно он воплощает ошибки в программе)
Ни разу не слышал чтобы просчеты на этапе постановки задачи кто-то называл «баги», это именно косяки, просчеты, ошибки проектирования, и тп.
«баг дизайна?» если у вас такой существует — то тогда я просто мягко с вами соглашусь и не буду дальше спорить, вопрос только в терминологии и не более.
Опечатка — это не решение программиста, она связана с механическим написанием кода, а не проектированием.
Убивает пистолет или человек, который держит его в руке? Программист реализует ТЗ, а не пишет его.
Вопрос исключительно терминологический. Во многих компаниях эти сущности называют более корректно: дефекты. Ведь причинами: «Оно не работает так, как мы хотим» могут быть различные факторы, в том числе, но не ограничиваясь «багами».
конкретный человек получает… и именно он воплощает ошибки в программе)
Убивает пистолет или человек, который держит его в руке? Программист реализует ТЗ, а не пишет его.
Ни разу не слышал чтобы просчеты на этапе постановки задачи кто-то называл «баги»
Вопрос исключительно терминологический. Во многих компаниях эти сущности называют более корректно: дефекты. Ведь причинами: «Оно не работает так, как мы хотим» могут быть различные факторы, в том числе, но не ограничиваясь «багами».
Астрологи объявили неделю гороскопов для айтишников. Количество статей про классификации людей на Хабре выросло вдвое…
Следует довести до него, что разработчики являются просто людьми, а всем людям свойственно ошибаться. Отдел QA должен компенсировать это естественное человеческое свойство разработчиков, действуя как защита от ошибок, влияющих на клиентов.
и
Отдел обеспечения качества (QA) занимается поиском багов в ПО.
Сдается мне, и автор текста, и переводчик слабо представляют себе и процесс разработки и роль QA в нем.
Серьезно, работал много где, но ни разу не встречал конфликтов, описанных в Угнетенный.
Особенно учитывая:
>>Печально, что эта ситуация является скорее нормой, чем исключением. Разница только в >>степени враждебности.
Люди конечно разные попадались, но открытые конфликты по причине ты тестировщик, он разработчик — не встречались.
P.S.: а вот кто настоящий зануда в IT, так это ДБА.
Особенно учитывая:
>>Печально, что эта ситуация является скорее нормой, чем исключением. Разница только в >>степени враждебности.
Люди конечно разные попадались, но открытые конфликты по причине ты тестировщик, он разработчик — не встречались.
P.S.: а вот кто настоящий зануда в IT, так это ДБА.
Ну а где же тот самый «идеальный тестировщик»? Я себя в этом списке не нашла… хотя может я вообще классификации не поддаюсь)
Поэтому крайне важно, чтобы работу менее компетентных разработчиков тестировали в последнюю очередь или чтобы она не попалась паникёру.
О нет, никогда не откладывайте тестирование работы менее компетентных разработчиков на последнюю очередь. Не надо с этого начинать, верно. Но если откладывать, то возрастут шансы на последнем этапе получить какой-то неприятный сюрприз — хотя всё остальное, казалось бы, не предвещало беды.
Познавательная статья, теперь знаю на что обращать внимание и чему стоит подучиться.
Какая замечательная статья. Читаешь и перед глазами возникают конкретные образы бывших и теперешних коллег.
чем больше ошибок вы обнаружите, тем лучше выполняете свою работу
На одной работе было что-то такое. Бывают люди, которые при таких требованиях стремятся относить к багам то, что ими не является, любую недосказанноость додумывать в свою пользу.
Например, на основе информации из базы надо сгенерировать текст по некоторому шаблону, пример полного текста указан в задаче. Задача отклоняется по причине "в тексте не выводится информация из такого-то поля", хотя в требованиях про него ничего не написано, просто в некоторых других шаблонах оно есть, без уточнений у постановщика задачи или у программиста. Это попадает в статистику по задачам, тестеру плюс, программисту минус. Приходилось писать постановщикам, мол, напишите ему что вам так и надо.
Sign up to leave a comment.
Проблемные личности среди тестировщиков