Тестирование ПО (Тестировщик, QA инженер)

ABM_I:

DenisN89:

И что из вышеперечисленных пунктов является обеспечением качества?
1, 2, 3, 4, обе пятерки это организация тестирования, а не обеспечение качества. Пункт 6 вообще чаще всего не касается технических специалистов напрямую, не им решать. 7 какого рода отзывы?

Все из вышеперечисленного является обеспечением качества. Анализ, планирование, выполнение, риски. Именно эти вещи напрямую влияют на качество. Почему подобные вопросы возникают у людей? Потому, что сами не были на позыциях управления. Читали скорее всего много какой то мутной литературы, в которой 99% воды. Сами не принимали проекты и не сдавали. Не нанимали людей и не обучали. Еще раз повторюсь, если у Вас есть какие то особые примеры относящиеся к QA, о которых не было сказано - приведите, вместе посмотрим.

Ещё раз, это все относится к тестированию. Риски продукта могут частично заранее быть известны, часть по результатам тестирование. Планирование и анализ тестирования, а не обеспечения качества.
И на качество продукта по сути тестирование влияет ничуть не больше чем разработка. И уж куда меньше влияет на качество чем влияет бизнес.
Quality assurance вообще порочная терминология, применимо к разработке программного обеспечения. Это все от стандарта 9001, который изначально вырос из индустриальных стандартов, а потом начали его пробовать на все натянуть. И вот там qa это фактически те, кто обеспечивают уверенность в том, что требования по качеству будут выполнены. Условно, какую марку стали использовать для деталей, как освещение на фабрике организовать и прочее.
Тестирование не работает с этим. Тестирование работает с тем, чтобы донести существующие и потенциальные проблемы до бизнеса. Тестировщик нив коем разе не может и не будет выбирать технологии, с помощью которых будет реализован продукт, архитектуру и прочее. Все что может сделать тестировщик, это хорошо подготовится к своей работе и повысить качество своей работы, а не продукта

bagick:

DenisN89, зависит от квалификации и опыта тестировщика. Ваши "ни в коем случае" как раз и есть очень удобная позиция - моя хата с краю - пусть взрослые дяди решают

Вы несёте ответственность за бизнес? Вы знаете, какое решение глобально лучше подойдёт для решения бизнес задачи? Вероятнее всего нет, почему тогда тестировщику этим заниматься?

bagick:

Обычно если ты аргументированно предлагаешь улучшения процесса\продукта - тебя слушают

И где в этом находится QA? Замечания может любой делать? Все qa? Где в этом собственно говоря assurance?

bagick:

Но да, чаще всего видишь ситуацию, когда люди осознанно сами себя ставят как QC - так намного удобнее - палкой издалека потыкал и домой пошёл.

Очень смешно, когда тестировщики считают себя обеспечивателями качества. На собесах люблю такое спрашивать. Как речь доходит до того, как качество обеспечили, сразу потухают. Ну вот нашли Вы баги, сделали предложения по улучшению. Из приняли, Вы qa? А если не приняли, то не QA?
Расскажите, как можно обеспечить качество не принимая никаких решений касательно продукта? Ведь по хорошему, даже приоритеты багам тестировщик не должен ставить

DenisN89,
1. Нормальный QA в курсе продукта над которым работает (а работает он начиная с процесса формирования требований к продукту) и не хуже бизнеса (а зачастую лучше PM или разработчиков) в нем ориентируется. Я уже не говорю о кейсах, когда у QA есть релевантный отраслевой опыт - в этом случае он будет знать продукт глубже бизнеса.
2. Судя по Вашему тексту - Вы достаточно смутно ориентируетесь в том для чего нужно QA вообще и тестирование в частности (ну и так - почитайте разницу между priority и severity и кто за что отвечает, может беспричинный смех пройдет).
3. По поводу зависимости приняли/не приняли баг - QA/не QA. У меня как у QA всегда есть возможность стопнуть релиз, если я считаю, что не сделаны какие либо критичные вещи. Бизнес и/или PM могут настоять, но при этом моя задача в том чтобы они осознавали все последствия от своих действий, а не тупо релизились на авось.
4. Продукт меняют, процессы выстраивают. Баги в процессах решаются банальной перепиской и поэтапной эскалацией. У Вас в голове какая то дикая смешанная в кашу иерархическая система, которая не учитывает различный опыт и способности людей.

_NiKiToS_:

1949287:

Здравствуйте! Собираюсь пойти на курсы тестирование ПО

Выбираю из нескольких, поделитесь отзывами, кто их проходил:

1. It-academy, 108 уч. часов
2. Компьютерная академия шаг, программа включает ручное тестирование и автоматизацию на Java
3. QA-academy, 7 лекций и 5 практических занятий
4. Stormnet, 64 уч. часов

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

Вопрос так же актуальный. It-academy - самый дорогой курс, но по всем отзывам моё окружение советует туда.
Есть ли реальный тестировщики, которые могут посоветовать из 4-ех вариантов?

Платные курсы QA Academy я бы не советовал. Смотрел их методичики, разговаривал с выпускниками - боль и огорчение.

bagick:

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

И? Это позволяет принимать бизнес решения? Печально, если у Вас так. То, что тестировщик знает бизнес логику позволяет ему лучше тестировать, а не обеспечивать качество.

bagick:

Судя по Вашему тексту - Вы достаточно смутно ориентируетесь в том для чего нужно QA вообще и тестирование в частности (ну и так - почитайте разницу между priority и severity и кто за что отвечает, может беспричинный смех пройдет

Прекрасно это знаю, а также прекрасно знаю, что в джировских проектах по умолчанию severity отсутствует. Соответственно далеко не все заводят дополнительное поле и оставляют одно поле priority

bagick:

У меня как у QA всегда есть возможность стопнуть релиз, если я считаю, что не сделаны какие либо критичные вещи. Бизнес и/или PM могут настоять, но при этом моя задача в том чтобы они осознавали все последствия от своих действий, а не тупо релизились на авось.

То есть даже тут Вы себе противоречите, у Вас нет возможности стопнуть релиз. Стопнуть релиз может бизнес. И, как я уже выше писал, задача тестирования предоставить информацию заинтересованным лицам. А потом уже лица будут думать, что делать, естественно, основываясь на предоставленной информации.. Выходить с проблемами или задержать релиз.

bagick:

Продукт меняют, процессы выстраивают. Баги в процессах решаются банальной перепиской и поэтапной эскалацией. У Вас в голове какая то дикая смешанная в кашу иерархическая система, которая не учитывает различный опыт и способности людей.

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

bagick:

DenisN89, Искренне соболезную пользователям Вашего большого опыта. Не вижу смысла продолжать жонглировать терминами.

При чем тут жонглирование терминами? Тут как раз про профессию и про специфику. Я работал в 6 компаниях, в продуктовых и аутсорсе. Ни в одной не было, чтобы тестировщик обеспечивал качество. Да и стопнуть релиз ни один тестировщик не мог (стопался продукт оунером или ПМом после ознакомления с результатами тестирования, но никогда тестировщиком)
Что вообще по вашему качество?
P.S. ну и для заметки, я не считаю, что тестирование это что-то простое и банальное. Это сложная вещь, со своими нюансами. Я просто за то, чтобы не начинали историю с quality assurance в рамках тестирования, потому что это совсем разные вещи

DenisN89:

Я работал в 6 компаниях, в продуктовых и аутсорсе. Ни в одной не было, чтобы тестировщик обеспечивал качество. Да и стопнуть релиз ни один тестировщик не мог (стопался продукт оунером или ПМом после ознакомления с результатами тестирования, но никогда тестировщиком)

Без обид, но приводить эмпирический опыт в качестве аргумента - дело унылое. То, что вы были на позициях рядового искателя багов никак не означает, что все остальные специалисты в этой сфере занимаются аналогичными действиями.

Запрос на качество идет от бизнеса, и его специфики и целей. Где то качество продукта - вопрос третичный, на первом месте идет набор аудитории и красивая продажа картинок прототипов инвесторам. А где то от качества напрямую зависит, купят ли твой продукт, или нет. Там совсем другая картина. И совсем другие специалисты нанимаются.

З.Ы. Да, обычный тестировщик обычно не имеет права ничего стопать. Только на позицию обеспечения качества обычных тестировщиков никто и не берет, это как на позицию СТО ставить мидла веб-разработчика. Поставить можно, толку - ноль.

DenisN89:

Я могу точно также привести мнение очень больших авторитетов в отрасли.
Нигде тестировщики не стопают релизы и не обеспечивают качество.
И кстати рядовым искателем очень давно не работаю.

насколько я помню, вы тот самый мега опытный сотрудник, который не в курсе блата в ИТ компаниях? Если вы считаете, что не являетесь рядовым искателем, то это не значит, что так и есть
п.с. в плэйтике тестеры стопают релизы

DenisN89:

Я могу точно также привести мнение очень больших авторитетов в отрасли.

Угу, лично знаком с некоторыми из них. Они все занимаются консалтингом, и их нанимают как раз для обеспечения качества со всеми полномочиями от бенефициаров бизнеса. Так что или вы не поняли их мнения, или лукавите.

DenisN89:

Нигде тестировщики не стопают релизы и не обеспечивают качество.
И кстати рядовым искателем очень давно не работаю.

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

DenisN89:

В том и дело. Бизнес может обеспечить качество, а тестировщик нет.

О да, СEO или инвестор идет обеспечивать качество. Лично. О чем вы? Бизнес оперирует баблом, виженом проекта и задает векторы развития. Если задан вектор на качество - появляется QA. Если вектор - аутсорсим зайкам веб прилаги с максимальной маржой - там он нафиг не нужен.

DenisN89:

Может ли тестировщик решить, какие баги исправлять, а какие нет?

Да конечно, обладая полным видением системы и работая в тесной связке со всеми участниками процесса (от задания фичи ПО и получения уточненных требований от БА, до конечной реализации ввиде кода) - его понимание приоритетов дефектов и их бизнес импакта - одно из лучших в команде продукта. Разумеется итоговый план фиксов будет составлен с учетом имеющихся ресурсов и приоритетов фичей, но значительная (иногда большая) часть этого решения - от QA.

DenisN89:

Может ли тестировщик перенести релиз, если считает, что нужно больше времени на тестирование/фиксы?

Да, обязательно, если компанией принят вектор на качество продукта для конечного пользователя. Ксли он выпустит сырой билд в прод - возникнут вопросы. Серьезные.

DenisN89:

Может ли тестировщик решить, что лучше для продукта и как стоит поменять функциональность?

Да, при наличии ресурсов, и разумеется с обсуждением со всеми заинтересованными лицами. Мы же в команде работаем. Точно так же, как ПО новые фичи забрасывает через обсуждение с командой.

DenisN89:

Может ли тестировщик выделить бюджет на тренинг персонала, на найм подходящих сотрудников?

Конечно. Если задан вектор на качество, все понимают, что это стоит денег и инвестиций в персонал. Обычно проблем с этим в таких компаниях нет. Ну совесть иметь конечно надо, если вы в веб разработке начнете пробивать командировки на геймскон - тут возникнут вопросики.

DenisN89:

Опять же, не обычный тестировщик тоже ничего не сможет стопнуть. Допустим критично выпустить продукт до праздников и заработать деньги. Сможет не обычный тестировщик перенести релиз с начала ноября на конец декабря?

Да, переносил лично с такого важного майлстоуна. Имевшийся архитектурный косяк однозначно говорил, что мы наглухо упадем по нагрузке, и бизнес импактом будет недоступность сервиса в пиковое время продаж. Потерянная выгода даже при приблизительных расчетах (сегмент DAU * AOV) перекрывала профиты, плюс репутационный ущерб. У бизнеса вопросов не возникло по этой причине.

chupa123:

который не в курсе блата в ИТ компаниях?

А это вы о чем?

DenisN89:

Не имеет. Потому что есть PO, продукт менеджер или другой человек связанный с продуктом, который может принимать решение. Этот человек знает бизнес цели, знает продукт с точки зрения востребованности фичей, понимает аналитику по продукту.

Забудьте про галерное мышление с какими то ПМами и прочими прокси. В эффективных продуктовых командах QA имеют прямую задачу контролировать выпуск релизов, и останавливать их если есть проблемы. Причем принцип - сначала останавливаем, потом решаем что делать. Потому что бизнесовый чувак (в лице Продакт Оунера) оперирует бизнесовыми планами и рисками, но не может, в силу отсутствующей квалификации, оперировать техническими. Поэтому и идет работа в команде. А не как в бодишопах - рабы гребут, а Вася ПМ решает релиз или нет, не понимая вообще ничерта в технической части, и чем это грозит в дальнейшем, ибо его волнует только свое KPI, а ответственность он потом активно будет скидывать, если пошли проблемы.
Что до бизнес целей и тп - их должна знать вся продуктовая команда. Только так можно эффективно работать.

DenisN89:

Тестировщик может стопнуть что-то только если он совмещает свою позицию с позицией в бизнесе.

Разумеется. Зачем бизнесу, ориентированному на качество продукта, на такой позиции пассивная макака? Там сидит человек, который имеет опыт в этом бизнесе, плюс технические знания. Его мнению доверяет бизнес. Отсюда и оценка рисков и импакта с совокупной большей эффективностью, чем у ПО, который по бизнесу получше, но технические риски оценивать может только по принципу "спрошу у васяна и накину 30%". Конечно все зависит от модели компании, где то эта роль выделена на специального релиз менеджера, который собирает риски и статусы со всех заинтересованных лиц, агрегирует, и затем принимает решение. Где то это опытный QA. Где то это нафиг не нужно, и там катят на прод все, что смогло запуститься на тестовом стенде, ибо ПМ торчит боссу абяцанку, что в пятницу (лол) задеплоим все, мамой клянусь...

DenisN89:

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

Я в таких местах работал и работаю. И вижу в чем вы ошибаетесь. Вы воспринимаете бизнес как конечную инстанцию, что верно для бодишопов и компаний, где качество идет не в приоритете (например для некоторых стартапов ключевой фактор - скорость выхода на рынок прототипа, там все затачивается именно под выброс релиза как можно раньше, с кучей компромиссов по функциональности и качеству продукта). Если же для компании качество имеет первостепенную важность - тут многие полномочия делегируются бизнесом соответствующим людям (которых сначала долго ищут и нанимают). Например ПО не имеет права вообще вмешиваться в процесс релиза. Аппрув на деплой дает только responsible qa. Да, если он отменяет релиз, ему надо подкрепить свою позицию, чтобы было понятно почему возникла проблема, как ее будем решать и как избежать ее появления в дальнейшем. Но право принятие решения - у него. А не у ПО или ПМа (коих может и не быть, для продуктовых команд они зачастую совершенно лишнее звено).

DenisN89:

И вот заинтересованное лицо говорит "нет". Много тогда тестировщик нарешает по фичам?

Просто так лицо сказать "нет" не может. Таковы договоренности. Позицию надо аргументировать. Чья аргументация правильнее, то решение и принимается. При конфликте - элевация выше.

DenisN89:

Иду к боссам, говорю, нужна конфа, а мне в ответ, что на этот год не предусмотрено. Сотрудников за свой счёт мне отправлять?

Я писал выше - там, где вектор на качество и эффективность, у бизнеса есть понимание того, что это стоит денег. Если "не предусмотрено" - понимания нет. Все просто.

DenisN89:

Если бы бизнес сказал, что выпускаем все равно, могли бы вы стопнуть?

У меня разрешение от CEO. Соответственно только СЕО может сказать "выпускаем все равно, тут без этого нам вилы". В таком случае конечно выпускать будем, все очевидно, все риски принимает на себя он, как главный в бизнесе. Только такого не было ни разу, так как оный СЕО полномочия мне давал не просто так. Точно так же как приоритеты и бизнес цели по конкретной фиче доводятся до всей команды, для более точной оценки рисков всеми.

DenisN89:

Я смотрю, многие считают, что решает тестировщик, но тут же оговариваются, если согласны заинтересованные лица. Так если все зависит от заинтересованных лиц, то что тогда решает тестировщик?

Вы не поняли. Решение об остановке (красный флаг) принимает тестировщик здесь и сейчас. Потом собирается команда, и коллегиально решается что теперь делать, как делать и когда делать, на основании сложности проблемы, приоритета деплоя фичи, таймфрейма на деплой и прочих параметров. Это очевидно, так как это командная работа. Тестировщик - не абсолютная истина. Точно так же, как ПМ или кто то еще - не абсолютная истина. В этом отличие от вашей концепции, где абсолютной истиной в принятии решений является абстрактный бизнес в лице ПМа, что характерно для аутсорса и авторитарных управленческих структур (характерных например для азиатов), со всеми последующими приколами, когда оный ПМ будет скидывать с себя ответственность за это.

DenisN89:

Там были разговоры, что кого-то не брали на работу, потому что все по блату и все места в айти так заняли, что хороший человек со стороны не может войти

Ну это бред, инфа сотка.

DenisN89:

В стартапе из 5 человек разве что. Или там, где бизнесу не интересны результаты. Речь не о проджект менеджерах, а о продукт менеджере (который иногда и продукт оунером может быть).
То есть человек, который развивает продукт или его части. Занимается разработкой функциональности, ответственен за продукт.

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

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

DenisN89:

И где тут остановка релиза со стороны тестирования? Находится предполагаемо критичный баг (допустим в регрессионной проверке), поднимается вопрос, человек бизнеса а итоге или останавливает релиз и переносит, или говорит, что можно идти так. Естественно, опираясь на предоставленные сведения. Но нельзя сказать, что это тестировщик остановил и перенес релиз.

Еще раз перечитайте эту часть моего поста. Вы явно не мне отвечаете.

DenisN89:

Бизнес ориентирован на достижение бизнес целей, а качество продукта вещь субъективная.

Выше описано, что для многих бизнес цель - максимальное качество для конечного пользователя.

DenisN89:

Бизнес всегда конечная инстанция, потому что бизнес является тем, что движет компанией. И приоритет у бизнеса это извлечение прибыли. Разговоры о качестве это шелуха. Если продукт приносит прибыль, пользователи им довольны, Тоти продукт можно назвать качественным. Поэтому, финальное слово всегда за бизнесом. Бизнес несёт риски, соответственно и бизнес принимает решение. А не Вася-тестировщик, который решил себя обеспечивателем качества назвать для увеличения чсв.

У вас отсутствует планирование в долгосрочной перспективе, что типично для нашего рынка. Прибыль здесь и сейчас - это признак говноменеджера, или менеджера родом из СНГ, где риски потерят бизнес таковы, что нужен ROI не длиннее года, и все бабки сразу выводить.

DenisN89:

А вот это полная глупость. Одно дело перенести на 2 часа, другое на несколько дней и тем более спринтов. Надумал тестировщик, что проблема серьезная, стопнул выпуск перед праздниками, в результате не успели подать на ревью до закрытия аппстора, соответственно не успели с рождественским обновлением на рождество (это как пример). Деньги потеряны, а проблема могла быть и не значительной.

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

DenisN89:

Ладно, звучит "нет, в данный момент это не а приоритете". Эскалировать? Рассказывать бизнесу, что должно быть в приоритете? С таким подходом успешные проекты не строятся.

Как вам будет угодно.

DenisN89:

В компании до 50 человек работает? Даже тут видно, что за бизнесом финальное слово. Но если компания и проекты крупные, то из бизнеса есть не только сео, потому что напрямую сео не будет руководить сотнями, а Тоти тысячами людей. И речь не об аутсорсе, а о продуктовых компаниях, причем вполне успешных.

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

DenisN89:

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

Я видел неоднократное увольнение ПО. Про отечественных ПМов даже не упоминаю, это расходник. Все причины - околонулевой риск менеджемент, эстимейшены наобум, при срабатывании риска - "это не я, это все они". Классика

DenisN89:

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

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

DenisN89:

В таком случае, qa это вся команда?

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