Тестирование дизайна страниц на соответствие с ТЗ, должен ли это делать тестировщик?!


(f@zen>) #1

Добрый день! Есть у меня вопрос, так как я один тестер в компании, мне дали еще обязанности проверять после дизайнера страницы, нарисованные (перед утверждением), на наличие элементов а также , дизайн, логику и т.д чтобы соответствовало как в ТЗ.
Как вы считаете это входит в обязанности или нет или за дополнительную плату?


(Sergey Korol) #2

Мануальщики тестируют мокапы. wink А если вы единственный тестер в компании, то думаю, что вам стоит задуматься над сменой компании. Рабство отменили уже давно.


(Mykhailo Poliarush) #3

Формально обязанности определяются в каждой компании по своему. На любого сотрудника можно повесить различные задачи. Все зависит от ... многих факторов.

Но если кто-то в менеджементе решил что Вы должны это делать, то вам остается или принять или не принимать такое решение.

Не стоит просто молчать, просто подойдите к руководству и расскажите, что Вы не хотите этим заниматься, или хотите но за деньги. А вот когда руководство выскажет свои аргументы, тогда и можно что-то обсуждать.


(Artur Korobeynyk) #4

А почему вы разделяете тестировщиков на мануальщиков и автоматизаторов? Задача тестировщика - улучшение качества продукта путем поиска багов на ранних стадиях разработки. Автоматизированное или мануальное тестирование - это только средства для достижения цели. Тестировщик должен сам решать, какое из орудий нужно использовать в данный момент. Автоматизированное тестирование - это не позиция, это скил.

Ну и по вопросу - да, считайте что это раннее тестирование. Найти недостающий элемент для нормальной работы проэкта на картинке до утверждения будет гораздо дешевле, чем после внедрения дизайна. А уменьшение цены ошибок тоже входит в обязанности тестировщика. Просто это не нужно превращать в какой-то ритуал с десятком документов. Нарисовал, сели вместе, желательно вместе с архитектором приложения, прикинули что мокап под функционал подходит и отдали дальше на утверждение.


(f@zen>) #5

Я с Вами вполне согласен. Спасибо за полный ответ.


(Sergey Korol) #6

Тестировщик ничего не улучшает, тестировщик предоставляет информацию о том самом выше упомянутом уровне качества продукта. К тому же, поиск багов - далеко не единственная задача тестировщика. Более того, данный процесс тоже ничего не улучшает. Или вы считаете, что если найдете N багов в приложении, оно станет качественней?

А разделяю я эти 2 направления ровно потому, почему это делают и все остальные: ввиду совершенно разного скоупа задач и уникальных особенностей, присущих человеку и машине. Требования и мокапы лучше тестировать человеку, ввиду того, что машина с этим просто напросто не справится (во всяком случае пока). Спросите - почему это не делать автоматизатору? Потому что мануальному тестировщику не нужно поднимать инфраструктуру, проектировать архитектуру тестового фреймворка, изучать технологии, которые будут применяться на проекте, настраивать CI / SC и т.п. На каждом этапе разработки у каждого есть свой скоуп задач. И если вам, как автоматизатору, больше нечем заняться, кроме как тестировать требования / мокапы - ради Бога, it's up to you. На более поздних этапах же, вы, как автоматизатор, так же вряд ли будете находить время на написание и саппорт "бумажных" тест кейсов / чеклистов и т.п., ибо у вас и своих проблем хватать будет. Я не верю в универсальных солдат, которые за 8 часовой рабочий день будут справляться и с manual, и с automation скоупом задач. Так что если человека взяли на позицию автомейшена, то тестирование мокапов (если он на это таки решится) будет производиться разве что в его же свободное время. Тут и ванговать не надо.


(Руслан) #7

:sob:


(Artur Korobeynyk) #8

Это как машина не едет, она сжигает бензин

Да, когда баги пофиксят. А если не найду эти N багов, оно станет качественней?

Зато они в вас верят

И снова, если это позиция аутомейшина, которую я не воспринимаю, то мокапами он заниматься не будет. А для меня позиция - это тестировщик, а аутомейшин - это скил. Я не дополнительные программы для заказчика делаю, я помогаю улучшить качество его основного продукта и поддерживать это качество на должном уровне.

Скажите это UI тестировщикам, по такой логике у них только одно свободное время. И кстати, они тоже пользуются автоматизированными тулами, иногда, ну там теория графов, сети Петри для получения тупиковых вариантов, когда один элемент никогда не будет показан, распознавание образов - для поиска тех же элементов. Те же сети Петри и для проверки требований могут быть использованны. Но ведь это не программирование, это алгоритмы, автоматизатор их может и не знать, а хорошему тестировщику такое знание не помешает.


(f@zen>) #9

Я могу сказать что как раз я как мануальный нежели автомейшен, да уровень какой-то есть у меня.Однако на данный момент автоматизацией не занимаюсь, смысла в этом нет, как сказал начальник. Поэтому моя состоит задача
1. Кросс тест
2. Юзабилити (UI)
3. Тестирование безопасности
4. Функциональное тестирование
5. Логическое тестирование (по госту начальника)
ну и теперь хотят мне мокапы тестить (чтобы дизайнер ни чего не пропустил с сравнении с ТЗ), а я это просто проверяю


(Sergey Korol) #10

Все просто: как сформулировали мысли, так вас и поняли. Если бы вы так отвечали на собеседовании на manual QA, вас бы сразу забросали помидорами. wink

Скажите это представителям компаний, открывающим везде такие позиции. Они с вами с удовольствием подискутируют. Еще забыли упомянуть о тестировании в Гугле, где знание в совершенстве хотя бы 1 языка программирования для "тестировщика" - это must have. Мораль сей басни - у каждой компании своя философия в отношении тестирования. Так что спор, что вы затеяли - бесполезен.

Очередной флейм? wink

А что значит UI-тестировщик? Т.е. manual / automation - это не камильфо, зато UI-тестировщик - допустимое разделение?

Все это лишь теория... Если бы все было так просто, наверное, кто-то уже такое реализовал бы, не так ли? wink


(Sergey Korol) #11

Ну если вы в основном занимаетесь ручным тестированием, то это вполне себе нормальный таск. wink


(Александр Шиповалов) #12

Я же напротив, с этим более чем согласен. Более того, он предоставляет даже информацию не о качестве - он должен предоставить информацию на основании которой PM, сможет решить - соответствует ли продукт ожиданиям заказчика. Заказчики бывают разные. У меня были люди, которые чуть ли не думали картинками и им в первую очередь было важно как выглядит - причем в первую очередь на MAC, есть люди для которых в первую очередь важен правильно работающий функционал - пусть и без pixel perfect. Был продукт, в котором клиента больше всего интересовало как будет работать OpenGraph API...у каждого клиента свои мысли об идеальном продукте.


(Александр Шиповалов) #13

По сабжу - да входит. Вполне себе нормальная задача. Если мануально - то глазками если автоматизированно то можно каким нибудь Sikulli и (или) Galen...


(Alsu Vadimovna) #14

Мне кажется, что проверять макеты на логику - это в ваших интересах. Иначе вы можете получить сделанную задачу на тест с неправильной логикой. Если в вашей компании еще и работают по Agile, то да, это очень нужная и важная задача. Кроме того, макеты обычно согласовываются с заказчиком.
Другое дело, что проверять макеты на то, нарисовано по сетке или нет - это уже вопросы к дизайнеру и его компетентности.


(Alex Okrushko) #15

Как Тест Инженер, который в данный момент работает в Гугле, немного разъясню. Даже в Гугле есть мануальные тестеры, хотя они практически исключительно контрактники и не являются сотрудниками компании. Они просто идут по тест кейсам, написанными ТЕ. Мануальное тестирование в принципе используется не часто и только для конкретных целей. Для остальных категорий (Test Engineer (TE) и Software Engineer in Test (SET)) знание программирования вообще обязательно, без него даже интервью не пройти.