×Закрыть

Есть ли еще разница между тестером(тестировщиком ПО) и QA?

Столкнулся с такой ситуацией, что тестеров (тестировщик ПО) иногда называют QA. Может потому что звучит красивее... Или солиднее... Или это правильная тенденция — объединение двух этих похожих специализаций?

В умных книжках написано, что quality assurance —

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

То есть, это не совсем тестерская работа...

Сохранилась ли еще эта разница? Или теперь QA = тестер?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Сорри за запоздалый коммент, летом был занят, прочёл только что.

Терминология, как мне пришлось заметить, никак не отражает украинских и прочих реалий. Однако, по некоторым данным, есть такое принятое понятие Product Assurance — это всё, кроме разработки и менеджмента, что нужно, чтобы создать законченный и годный продукт. Сюда входит все методы тестирования (исполнения с целью найти ошибку), учёт/планирование изменений, прочие контроли (без исполнения) на всех этапах и QA, который, по этой терминологии, занимается тем, что выстраивает, контролирует и оценивает сам процесс разработки (а не код, не документацию и т.п.). Это так в теории, откуда этот термин, как колобок, укатился. Далее пошёл результаты практического осмысления. Слово QA почему-то понравилось, хотя в контексте 90% разработок означает тестинг.

Почему тестинг а не «Обеспечение Качества» (если переводить дословно QA). Почему QC а не QA? Потому, что все пытаются сказать, что делают качественно, а делают как подешевле, потому, работа по обеспечению качества 90% (увы) делается не исходя из требований такового, а «чтобы клиент не нашёл первым». Потому, что качество — дорого (и, главное — не очень линейно) стоит, и за поддержку можно взять более гарантировано.

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

Но качество где-то есть. Оно не может не есть. Просто термин чаще означает тестинг.

Для того, чтобы научиться делать качественные продукты, надо много экспериментировать на всех уровнях. Просто писать красивый код или тестировать — это не достаточно, здесь важно всё. Главное — видеть в процессе разработки причины, приводящие к неудачам в финальном продукте или сервисе, срыву сроков, недовольству клиентов — это я называю QA. А вы уж, как хотите, первоначальный смысл термина я объяснил.

Nikita Knysh все правильно написал, даже не знаю что тут еще можно добавить.
Если вы QC (он же тестировщик ПО), но любите называть себя QA по любым причинам — это ваше дело.

Если вы QA, то прекрасно понимаете в чем разница, и по сути QC входит в QA, то есть попросту говоря «тестировщик ПО» (он же QC) является составляющей понятия QA, но это далеко не единсвенный род деятельности QA-я. Как-то так.

В вообще, название должности — это формальность. Главное что и как вы делаете, чего это «стоит» и куда вы движитесь.

«Существует 4 вида тестовых групп:
— Группа контроля качества(QC) — следит за соблюдение стандартов.
— Группа обеспечения качества(QA) — пытается тем или иным способом гарантировать соблюдение стандартов.
— Служба тестирования(Testing Services) — ищет и документирует ошибки.
— Служба поддержки разработки выполняет ряд технических задач, и в том числе тестирование.»

(Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений.)

Так что возник еще один вопрос: QC=Testing Services?

Из этой цитаты следует, что нет :)
Соответствие стандартам и отсутсвие багов — не одно и то же :)

Я честно говоря впервые слышу чтобы «баг райтеров» и «баг файндеров» выделяли в какие-то там отдельные группы. Это все обязанности QC. На счет последнего пункта — вообще не понял о чем речь идет.
Я тебе объясню проще: QA это самое глобальное понятие в работу QA входит очень много чего, все что ты описал ниже — подгруппы этого понятия, по крайней мере в моем видении (точно также как некоторые люди не понимают разницу между HR и Recrutier, т.к. считают что девочки которые зовут на собеседование — HR-ы).

1. Начинаешь ты обычно с того что выполняешь поставленные таски, находишь баги, пишешь баги, отчитываешься, вновь выполняешь поставленные таски и т.д.
2. Дальше круг твоих обязанностей расширяется, изначально хотя бы до того что ты сам себе можешь ставить таски и планировать\анализировать свою работу.
3. Дальше ты начинаешь немного больше понимать и уже занимаешься созданием тест документации всех видов и мастей и, возможно, контролем выполнения тасков другими людьми.
Вот ИМХО тут заканчивается QC, если ты идешь дальше, то начинаешь выполнять уже в той или иной степени функции QA-я, т.е. внедрять то, чего до тебя не было, модернизировать имеющиеся и разрабатывать новые подходы к продукту, рабочему процессу и т.д., увеличивать КПД работы проекта(-ов), и т.д.

Ну а «идти» можно много куда, вплоть до глубокого White box-а, нагрузочного тестирования beckend-ов, автоматизации процессов тестирования, разработки глобальных тест планов (когда проекта еще нет и ты у старта, с 0 так скажем), стратегий тестирования под специфику того или иного продута, подготовкой работы команды тестирования еще по сути до старта продукта, разработки концепции будущего тестирования как таковой, оптимизации других, уже существующих процессов на других проектах, переговорах с заказчиками, оптимизации продукта под пользователя, корреляцией с дэвелоперами по Unit-тестам, ревьювам спецификаций с заказчиком и дискуссиями на тему «вот так вот делать не надо, лучше давайте рассмотрим вот такие варианты», отслеживать мир IT на предмет новых программ, технологий и т.д. и т.п.

Если ты работаешь, даже сверх гениально, ни ничего не меняешь (читай — не улучшаешь) во всех этих процессах, это QC, т.е. ты просто контролируешь чтобы то что делается кем-то соответствовало тому что надо получить «на выходе» заказчику или end user-у, все.
QC, опять же, в моем понимании, не предусматривает творческой работы, а лишь той которая скажет соответствует ли продукт заданным «свыше» критериям, или нет.
И вот в моем понимании все что выходит за рамки «поставленного рабочего процесса» — это QA. И помимо, этот человек кроме тех. навыков, должен обладать хорошими способностями менеджера, уметь находить общий язык и контакт с людьми и заказчиком\боссом (outsouce\productowner) и иметь «свежий взгляд» на вещи, должен любить свой продукт и знать его лучше всех и т.д. Короче на самом деле высококлассный QA специалист — это золото для продукта, но их не так много, как хотелось бы, и стать таким специалистом очень не просто, но стремиться — однозначно стоит!
Тут главное чтобы работа — нравилась: будет нравится — будет интересно, будет интересно — будешь стараться, будешь стараться — будет получатся, будет получатся — будешь расти, будешь расти — будешь больше зарабатывать и карабкаться по «лестнице» вверх.

Надеюсь я донес свою мысль :)

Я честно говоря впервые слышу чтобы «баг райтеров» и «баг файндеров» выделали в какие-то там отдельные группы.

Наверное, в больших структурах это возможно. Но, наверное, эти группы все равно взаимодействуют.

У нас в команде, например, процесс нахождения багов отделен от процесса их «оцентки» («triage»), где принимается решение о том, насколько баг критичен и когда (а иногда — и кто конкретно) его будут фиксить. Но отдельныой группы для оценки нет. В triage участвуют представители всех дисциплин в команде, и это не обязательно одни и те же люди.

Тестер, как правило, занимается тем, что называется Quality Control (QC): ищет баги, составляет картину качества ПРОДУКТА на настоящее время.
Quality Assurance («обеспечение качества»), оно же, по большому счету, «управление качеством» — это постоянный анализ и улучшение ПРОЦЕССА с целью повышения качества производимого продукта.

То есть имеем спираль из QC и QA: сделали -> проконтролировали качество -> проанализировали результаты контроля -> улучшили процесс -> сделали еще раз.

QA-ем часто занимаются не тестеры, а менеджеры из других направлений, такие как PM-ы или QA-менеджеры («менеджеры по качеству»).

Тестеров называют QA-ями по двум причинам: либо по незнанию терминологии, либо когда в организации тестеры сильно вовлечены в QA, а не только в QC.

отличное пояснение

Разница, безусловно, есть!!!

«Тестер» это электроизмерительный прибор, а QA — это то что вы написали.

«В задачи группы тестирования (Testing Services) входит поиск ошибок и недостатков программы, их описание и предоставление этой информации всем, кому она необходима.» (Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений.)

Может в этом и проблема — название круче... Software Developer и QA, а не какой-то электроизмерительный прибор...

Подписаться на комментарии