testomat.io управление авто тестамиДобрый день! Есть у меня вопрос, так как я один тестер в компании, мне дали еще обязанности проверять после дизайнера страницы, нарисованные (перед утверждением), на наличие элементов а также , дизайн, логику и т.д чтобы соответствовало как в ТЗ.
Как вы считаете это входит в обязанности или нет или за дополнительную плату?
Мануальщики тестируют мокапы. 
А если вы единственный тестер в компании, то думаю, что вам стоит задуматься над сменой компании. Рабство отменили уже давно.
Формально обязанности определяются в каждой компании по своему. На любого сотрудника можно повесить различные задачи. Все зависит от … многих факторов.
Но если кто-то в менеджементе решил что Вы должны это делать, то вам остается или принять или не принимать такое решение.
Не стоит просто молчать, просто подойдите к руководству и расскажите, что Вы не хотите этим заниматься, или хотите но за деньги. А вот когда руководство выскажет свои аргументы, тогда и можно что-то обсуждать.
1 лайк
А почему вы разделяете тестировщиков на мануальщиков и автоматизаторов? Задача тестировщика - улучшение качества продукта путем поиска багов на ранних стадиях разработки. Автоматизированное или мануальное тестирование - это только средства для достижения цели. Тестировщик должен сам решать, какое из орудий нужно использовать в данный момент. Автоматизированное тестирование - это не позиция, это скил.
Ну и по вопросу - да, считайте что это раннее тестирование. Найти недостающий элемент для нормальной работы проэкта на картинке до утверждения будет гораздо дешевле, чем после внедрения дизайна. А уменьшение цены ошибок тоже входит в обязанности тестировщика. Просто это не нужно превращать в какой-то ритуал с десятком документов. Нарисовал, сели вместе, желательно вместе с архитектором приложения, прикинули что мокап под функционал подходит и отдали дальше на утверждение.
Я с Вами вполне согласен. Спасибо за полный ответ.
Тестировщик ничего не улучшает, тестировщик предоставляет информацию о том самом выше упомянутом уровне качества продукта. К тому же, поиск багов - далеко не единственная задача тестировщика. Более того, данный процесс тоже ничего не улучшает. Или вы считаете, что если найдете N багов в приложении, оно станет качественней?
А разделяю я эти 2 направления ровно потому, почему это делают и все остальные: ввиду совершенно разного скоупа задач и уникальных особенностей, присущих человеку и машине. Требования и мокапы лучше тестировать человеку, ввиду того, что машина с этим просто напросто не справится (во всяком случае пока). Спросите - почему это не делать автоматизатору? Потому что мануальному тестировщику не нужно поднимать инфраструктуру, проектировать архитектуру тестового фреймворка, изучать технологии, которые будут применяться на проекте, настраивать CI / SC и т.п. На каждом этапе разработки у каждого есть свой скоуп задач. И если вам, как автоматизатору, больше нечем заняться, кроме как тестировать требования / мокапы - ради Бога, it’s up to you. На более поздних этапах же, вы, как автоматизатор, так же вряд ли будете находить время на написание и саппорт “бумажных” тест кейсов / чеклистов и т.п., ибо у вас и своих проблем хватать будет. Я не верю в универсальных солдат, которые за 8 часовой рабочий день будут справляться и с manual, и с automation скоупом задач. Так что если человека взяли на позицию автомейшена, то тестирование мокапов (если он на это таки решится) будет производиться разве что в его же свободное время. Тут и ванговать не надо.
1 лайк
Это как машина не едет, она сжигает бензин
Да, когда баги пофиксят. А если не найду эти N багов, оно станет качественней?
Зато они в вас верят
И снова, если это позиция аутомейшина, которую я не воспринимаю, то мокапами он заниматься не будет. А для меня позиция - это тестировщик, а аутомейшин - это скил. Я не дополнительные программы для заказчика делаю, я помогаю улучшить качество его основного продукта и поддерживать это качество на должном уровне.
Скажите это UI тестировщикам, по такой логике у них только одно свободное время. И кстати, они тоже пользуются автоматизированными тулами, иногда, ну там теория графов, сети Петри для получения тупиковых вариантов, когда один элемент никогда не будет показан, распознавание образов - для поиска тех же элементов. Те же сети Петри и для проверки требований могут быть использованны. Но ведь это не программирование, это алгоритмы, автоматизатор их может и не знать, а хорошему тестировщику такое знание не помешает.
Я могу сказать что как раз я как мануальный нежели автомейшен, да уровень какой-то есть у меня.Однако на данный момент автоматизацией не занимаюсь, смысла в этом нет, как сказал начальник. Поэтому моя состоит задача
- Кросс тест
- Юзабилити (UI)
- Тестирование безопасности
- Функциональное тестирование
- Логическое тестирование (по госту начальника)
ну и теперь хотят мне мокапы тестить (чтобы дизайнер ни чего не пропустил с сравнении с ТЗ), а я это просто проверяю
Все просто: как сформулировали мысли, так вас и поняли. Если бы вы так отвечали на собеседовании на manual QA, вас бы сразу забросали помидорами.
Скажите это представителям компаний, открывающим везде такие позиции. Они с вами с удовольствием подискутируют. Еще забыли упомянуть о тестировании в Гугле, где знание в совершенстве хотя бы 1 языка программирования для “тестировщика” - это must have. Мораль сей басни - у каждой компании своя философия в отношении тестирования. Так что спор, что вы затеяли - бесполезен.
Очередной флейм?
А что значит UI-тестировщик? Т.е. manual / automation - это не камильфо, зато UI-тестировщик - допустимое разделение?
Все это лишь теория… Если бы все было так просто, наверное, кто-то уже такое реализовал бы, не так ли?
Ну если вы в основном занимаетесь ручным тестированием, то это вполне себе нормальный таск.
3 лайка
Я же напротив, с этим более чем согласен. Более того, он предоставляет даже информацию не о качестве - он должен предоставить информацию на основании которой PM, сможет решить - соответствует ли продукт ожиданиям заказчика. Заказчики бывают разные. У меня были люди, которые чуть ли не думали картинками и им в первую очередь было важно как выглядит - причем в первую очередь на MAC, есть люди для которых в первую очередь важен правильно работающий функционал - пусть и без pixel perfect. Был продукт, в котором клиента больше всего интересовало как будет работать OpenGraph API…у каждого клиента свои мысли об идеальном продукте.
По сабжу - да входит. Вполне себе нормальная задача. Если мануально - то глазками если автоматизированно то можно каким нибудь Sikulli и (или) Galen…
Мне кажется, что проверять макеты на логику - это в ваших интересах. Иначе вы можете получить сделанную задачу на тест с неправильной логикой. Если в вашей компании еще и работают по Agile, то да, это очень нужная и важная задача. Кроме того, макеты обычно согласовываются с заказчиком.
Другое дело, что проверять макеты на то, нарисовано по сетке или нет - это уже вопросы к дизайнеру и его компетентности.
Как Тест Инженер, который в данный момент работает в Гугле, немного разъясню. Даже в Гугле есть мануальные тестеры, хотя они практически исключительно контрактники и не являются сотрудниками компании. Они просто идут по тест кейсам, написанными ТЕ. Мануальное тестирование в принципе используется не часто и только для конкретных целей. Для остальных категорий (Test Engineer (TE) и Software Engineer in Test (SET)) знание программирования вообще обязательно, без него даже интервью не пройти.