Comments 40
Быть QA это круто, это интересно и познавательно… Но что делать в ситуации, если тестировщик захотел стать QA, а такой должности в компании нет. И вот он пытается на этапе обсуждения требований заказчика что-то свое предложить, но его не слушают, пытается объяснить разработчику, как будет удобнее для пользователя сделать кнопку, форму и т.д. — разработчик говорит — этого нет в ТЗ. Рассказывает в никуда про автоматизацию и юнит тесты. В общем пытается сделать качество продукта более высоким, но безрезультатно.
Что делать вот в такой ситуации? Увольняться? Давить? Писать предложения руководству? Забить и плыть по течению?
Поделитесь, пожалуйста, опытом, сталкивались ли вы с чем-то подобным и есть ли какие-то универсальные решения?
Увольняться?
This
Faenor Нужно набрать себе репутацию. Когда ты найдешь несколько раз неочевидные вещи, которые окажутся на деле критическими — с твоим мнением начнут считаться. Но последнее слово все равно за лидом.
Ну и нужно общаться с разработчиками, чтобы понимать их классификацию проблем и критичности.
Вообще могу посоветовать немножко вникнуть в разработку продукта. Станешь лучше понимать устройство приложения, сможешь лучше понимать как чейнджлог соотносится с компонентами приложения, какие компоненты могут вызывать какие типы ошибок. Это следующий уровень. Тогда общение с разработчиками станет намного интереснее и полезнее и вам и им.
Рассказывает в никуда про автоматизацию и юнит тестыTогда и такие темы будут не просто так рассказываться. Ты попробуешь написать сам какой нибудь юнит-тест, начнешь ковырять Jenkins, пилить автоматизацию приемочного тестирования, и т.д. Только сделать и показать. А говорить и надеяться, что кто-то вдохновится речью на какие-то телодвижения — ну это только в фильмах бывает.
Но если ты это сделаешь — как взлетит твоя репутация, ты будешь «хранителем тайного знания».
Научись делать что-нибудь очень хорошо, легко и непринужденно. Я например научился хорошо формулировать багрепорты, и воспроизводить ошибки (во многом за счет понимания внутреннего устройства системы) и ко мне приходят когда разработчикам нужно написать багрепорт на внешную систему, или им пришел репорт и они не могут разобрать «почерк» тестировщика, что ему надо вообще. Могу помочь отфутболить репорт и красиво сформулировать причину. Могу перепроверить какой-то баг для разработчика, снять трейс и указать на подозрительные места в нем. Это экономит им время — а мне капает опыт и репутация.
Еще нужно быть в курсе над чем сейчас работают программисты. Или хотя бы всегда иметь доступ к этой информации. Не только следить за своими репортами, а за ходом всей разработки. Читать багтрекер.
Короче, нужно брать все в свои руки. Изменить процессы можно только изнутри. Своими руками. У нас было несколько таких, кто приходил на должность типа «коуча», вещал умные вещи про то как надо, но ни пальцем не притронулся к проекту. Не сделал ничего для продукта. Для меня теперь это быстрый тест на эффективность человека в новой должности. Если «марает» руки — будет толк, если нет — не будет.
Люблю цитировать Ларри Уолла: «Три высших добродетели программиста — лень, нетерпение и спесь». И когда я только вливался в среду, я почувствовал это все на себе. Со временем я адаптировался, вырос. Характер разработчиков так и не изменился, но изменился я. И отношения у нас замечательные.
Ну собственно вариантов ровно два на мой взгляд: ты либо работаешь, собираешь информацию и доказываешь почему то, что ты хочешь делать полезно и нужно, либо увольняешься. Если руководство адекватно и в состоянии воспринимать конструктивные предложения подкрепленные фактами — тебя выслушают и скорее всего начнут что-то делать. Если руководство в принципе не готово слушать никаких предложений по улучшению, то я не знаю какой смысл трепать всем нервы и продолжать там работать.
Но да, доказать полезность изменения процесса — это очень не просто и требует больших приложенных усилий даже если тебя готовы слушать. Просто потому что менять процесс — дорого и значит изменение должно в результате принести больше пользы чем на него было потрачено средств.
Из практических советов: поговорить со своей командой и попробовать внести изменения в качестве эксперимента. С заранее известным его сроком, заранее обсужденными возможными выгодами и неудобствами и постоянным контролем. После такого эксперимента можно с результатами идти уже выше.
Статья отличная!, последний пример про гуглодок вообще сюрреализм какой-то) Тестировщик должен прежде всего уметь общаться со всей командой.
Нет не должен. А вот к Тим Лиду большой вопрос, что за бардак у него в рабочей группе.
Быть QA это круто, это интересно и познавательно… Но что делать в ситуации, если тестировщик захотел стать QA, а такой должности в компании нет.
Хорошо бы понимать что есть QA и должность не обязательна должна быть.
Может быть и роль.
Кстати мало людей фанатеют от гостов и стандартов. А для QA они основа в работе…
И вот он пытается на этапе обсуждения требований заказчика что-то свое предложить, но его не слушают, пытается объяснить разработчику, как будет удобнее для пользователя сделать кнопку, форму и т.д. — разработчик говорит — этого нет в ТЗ. Рассказывает в никуда про автоматизацию и юнит тесты. В общем пытается сделать качество продукта более высоким, но безрезультатно.
Не занимаются QA удобством продукта для пользователя.
Более того если этого нет в ТЗ именно QA первый скажет стопе. Вносите в ТЗ, вот тогда и будем разговарить, нет процесса на измение тз? Ок, счас будуте.
QA — это в первую очередь нацеленность на бизнес и на процессы.
Не занимаются QA удобством продукта для пользователя
Занимаются
Этот вид тестирования называется usability
Если у вас в компании так, то тогда у меня для вас плохие новости :)
Есть такой фасет в нефункционально тестировании. И?
Да есть тестировщики специализирующиеся на нем, но именно тестировщики, они обычно одновременно юзабилити занимаются. Но это не то чем занимается QA
Нет, QA специалисты не занимаются QC, а уж тем более тестированием.
Если у вас в компании так, то тогда у меня для вас плохие новости :)
QA сейчас могут заниматься практически чем угодно, общепринятого определения кто это и что они конкретно делают на данный момент в мире не существует. Если в вашей организации считают иначе, то у меня для вас плохие новости :) (на самом деле нет, ваше право в общем-то)
part of quality management (3.2.8) focused on providing confidence that quality requirements will be fulfilled
Такая активность как QА направлена на стандартизацию процессов с целью обеспечить гарантию того, что установленные для ПО требования будут удовлетворены.
Перевожу: QA инженеры (По сути, эту роль можно возложить на любого человека, который знает стандарты и отраслевые, и стандарты внутренние) занимаются превентивной деятельностью. Они налаживают процессы разработки, тестирования и внедрения ПО таким образом, чтобы минимализировать шанс его несоответствия требованиям и стандартам. Для этого пользуются внедрением разнообразных метрик качества продукта и способов их проверки (что и называется QC, которое выполняется уже, как правило, отдельными людьми).
Тестирование же — это просто деятельность, направленная на ОБНАРУЖЕНИЕ несоответствий ПО требованиям, т.е инструмент для такого процесса как QC.
Хотя, в современных «шлеп-шлеп и в продакшн» конторах, конечно же, никто и не пытается поинтересоваться что с чем едят и, как минимум, попытаться отличить
На самом деле есть русская версия ISO: www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:ru:term:3.2.11
Выдержки:
— 3.2.11
обеспечение качества
quality assurance
часть менеджмента качества (3.2.8), направленная на создание уверенности в том, что требования (3.1.2) к качеству будут выполнены
— 3.2.10
управление качеством
quality control
часть менеджмента качества (3.2.8), направленная на выполнение требований (3.1.2) к качеству
— 3.2.8
менеджмент качества
quality management
скоординированная деятельность по руководству и управлению организацией (3.3.1) применительно к качеству (3.1.1)
Примечание 1 к записи: Руководство и управление применительно к качеству обычно включает разработку политики в области качества (3.2.4) и целей в области качества (3.2.5), планирование качества (3.2.9), управление качеством (3.2.10), обеспечение качества (3.2.11) и улучшение качества (3.2.12).
Первое — определение процесса обеспечения качества, второе — процесс управления качеством. Все это является состовляющей менеджмента качества, также как и планирование и многое другое. Это не определение должности человека.
В большинстве компаний есть отдел качества, который занимается как раз Менеджментом этого самого качества. Т.е. те же самые люди, что настроили процесс, могут заниматься и тестированием. Может действительно отдельную статью об этом написать…
В одном с вами не соглашусь. Не знаю компаний (конечно, я не утверждаю, что их нет в принципе), где одна и та же команда выполняла бы и QA, и QC. QA — это все-таки про стандарты (при чем тех самых процессов тоже), их разработку и внедрение. Если речь идет о QC и тестировании — согласен, изучили стандарты, построили процессы, наладили коммуникации — и вперед тестировать. А роль QA на практике в большинстве компаний ложится на плечи архитектам и всяким там R&D менеджерам и иже с ними, которые уже внедряют метрики, описывают стандарты, соглашения, проводят код ревью т.д.
Интересно было бы узнать названия хотя бы некоторых из этого вашего большинства компаний, где те люди, которые тестируют ПО, занимаются так же разработкой стандартов или ХОТЯ БЫ участвуют в код-ревью девелопмента) Да, несомненно, они могут принимать участие в этих процессах косвенно или факультативно, но они не являются главными инфлюэнсерами.
По поводу написания статьи — согласен, иногда чувствуется острая необходимость прояснить и трактовать все понятия, объяснить их применение на практике, но тем, кто и не хочет разбираться в тонкостях — вряд ли поможет.
В целом, приятно пообщаться с человеком, который понимает чем он занимается
Я же написал: "общепризнанного". Вы можете сколько угодно ссылаться на всяческие стандарты но пока люди вокруг реально не начнут поголовно использовать именно это определение — это именно вы будете вне сообщества, а не наоборот. Толку то от того что вы будете применять труъ определение если вас никто не поймет. А уж если начать говорить о понимании людей не связанных со всем этим напрямую — руководством например, то там все совсем плохо.
И это может быть кнопка не в том месте или другая мелочь с точки зрения разработчика
Заводить дефект на положение кнопки это не дело тестировщика, он максимум может вынести этот вопрос на обсуждение с дизайнером
Зависит от процесса. Где-то нужно идти и обсуждать с дезайнером, где-то — уведомить овнера, менеджера или лида, где-то — завести тикет. Все эти варианты возможны, зависит от того как в целом работа устроена. Например у нас никто не смотрит на количество тикетов с типом баг и заводить их можно сколько душе угодно. Все некритичные тикеты будут рассмотрены при планировании спринта, что-то уйдет в глубокий бэклог, что-то пойдет в работу сразу, что-то поменяется на фичу или просто отсеется. Если что-то прямо совсем критичное — то и сразу в работу может пойти, но тут надо не просто тикет завести, а еще и послать его всем причастным.
Не всегда важно чтобы можно было концы найти и прочитать что именно обсуждалось. Понятно что когда оно все где-то залогировано, то это хорошо, но это реально не всегда нужно. Особенно если команда нормально умеет общаться и работать и вопрос реально в "подвинуть кнопку" (у меня кстати реально такой случай был — двигали кнопку из одного угла в другой потому что всплывающие нотификации всплывали поверх).
У меня обычно примерно такое правило: если не очень критично — я напишу в общем чате или вообще устно обсужу. Если никто не пошевелился отреагировать — завожу формальный тикет и поехали по процессу. Памяти на пару дней у меня хватает, все важное записываем сразу, особых проблем за два года в этой компании еще ни разу не возникло (относительно конкретно этого момента).
Всё, что идёт далее, сугубо моё личное мнение. Давайте не будем мешать всё в кучу. На самом деле есть разница между тестировщиком и QA, не надо менять одно на другое. Тестирование приложения — это по сути констатация его состояния. Вот это работает, а вот это не работает. Тестировщики не делают приложение лучше, разработчики делают. QA, в отличие от тестировщиков, вовлечен в процессы производства программного обеспечения. В том плане, что он может обосновать, как впихнуть тестирование в процесс производства таким образом, чтобы оно помогало поддерживать качество продукта в течение всего цикла производства. Это, естественно, включает коммуникации со всеми людьми, занятыми в процессе. Например, умение обосновать, как автоматизация тестирования сократит время нахождения ошибок, и, соответственно, снизит стоимость исправлений и повысит качество продукта. Или зачем тестировать требования, и как это правильно сделать, что сильно коррелирует, опять же, со стоимостью исправлений. Или объяснить пирамиду уровней тестирования разработчикам, и что реально должны делать юнит-тесты, и зачем, и почему важно покрытие кода, и так далее. Да, в чем-то эти две вещи пересекаются (я бы сказал, одно входит в другое), но они не тождественно равны.
На практике есть люди, которых называют QA, которые даже не понимают, о чем по существу тестирование, и не понимают многих простых вещей, например, что шаг тест-кейса это создание конкретного состояния приложения и валидация этого состояния. Или что не надо влезать в написание требований, а надо их тестировать, предварительно обосновав, зачем и какой эффект в долгосрочной перспективе это даёт. Или что такое приоритезация областей тестирования, и чем продакт риск отличается от проджект риска. В двух словах, тестирование — о текущем состоянии приложения, QA — о том, как эффективно обеспечивать производство качественного продукта, используя тестирование как инструмент оценки качества этого продукта. Извините за большой комментарий, и добра вам, коллега.
«QA — это, по сути, адвокат пользователя.»
Как мне кажется, введение и вывод друг другу противоречат. Все-так забота об удобстве пользователя — это всего лишь часть задач QA. В первую очередь тестирование дает фидбек о состоянии продукта. А если состояние продукта не устраивает заказчика, то уже он принимает решение о внесении изменений в требования, а не так:
«Если путем этой нехитрой манипуляции сознанием выяснится, что приложение чем-то не устраивает, то надо заводить тикет.»
А противоречие есть: если фиксить то, что не устраивает тестировщика — то можно получить удобную, но не нужную заказчику фигню.
Как мне кажется, введение и вывод друг другу противоречат
По-моему они как раз замечательно друг друга дополняют. Тестировщик смотрит на то, что нужно заказчику, сравнивает с тем, что сделано и при расхождении об этом говорит. Это не все его задачи, но противоречия тут никакого нет.
Даже самый плохонький тестировщик не должен так делать. Первое что нужно объяснить новорожденному тестировщику — твоя задача не найти мильон багов. Твоя задача — проверить что программа выполняет свои функции. И только когда есть уверенность что выполняет — можно переходить к 9999999 кружкам и запятым в About.
Кто такой хороший QA?