Если честно — у меня язык не поворачивается говорить QC, и даже мысли такой не возникает. Исторически это не сложилось в нашей стране, не буду говорить про мир, не готов спорить. Мне достаточно того, что я всегда говорю только «тестировщик» без прочих вариантов, содранных с языка оригинала и означающих прибор для измерений.
Мы живем в обществе и подчиняемся его законам. Для сравнения, поиск на сайте хаха по двум буквам выдает: QC — 14 вариантов, QA — 143 варианта.
Из 14 только 8 относятся к данной области, смотрите, кто это:
Junior Test engineer,
Инженер по тестированию ПО,
Координатор по контролю качества (Quality Assurance/ Quality Controll Coordinator).
QA Controller / Контролер по обеспечению качества
Руководитель группы инженеров по тестированию
Quality Control Manager
Quality Control Manager (Concrete Industry)
Manager of Document and Quality Control
Конечно, профессионалы должны быть выше «толпы», но высоко отрываться позволительно лишь академическим личностям, а не практикам, иначе окружающие не будут понимать… ИМХО
Мы все обмениваемся личными мнениями и опытом. И это хорошо. Действительно, повод для статьи — непонимание и нежелание ПМ использовать независимых тестировщиков, а желание поручить тестирование своим разработчикам.
Тестирование системы как черного ящика не имеет никакого отношения к пониманию кода, но общее понимание устройства — необходимо. И часто — достаточно. И не факт, что совершенствуясь в понимании устройства — некто, не имея таланта или тяги к тестированию как деструктивному подходу — сможет соревноваться в процессе разрушения. ИМХО.
У меня был лишь один студент за 8 лет, кто ушел в разработчики, правда и студентов было мало :-) менее 10. Не поддерживаю такого подхода — ставить неопытных на тестирование — это примитивно, безответственно и неэффективно. Другое дело, что расти как профессионал нужно с простых, элементарных активностей. Но это другая песня, про наставничество, линейный рост в профессии.
Как всегда, между начальниками, пытаемся найти компромисс, иначе — кто-то лишний. Доказываем сначала полезность тестирования как процесса, затем эффективность тестировщиков — как специалистов, затем — автоматизацию, как интенсификацию, далее и всегда — совершенствование процессов…
Признателен за эту фразу — «изучить логику начальника».
JIRA — очень удобно и гибко, HP Mercury QC (TestDirector). А также HP Mercury LR, QTP, Confluence, Sybase PowerDesigner… Про инструменты можно отдельно опросить всех, правда перечень может быть слишком громоздок…
Ваш подход близок к идеалистичному, примерно так происходит в Google — они даже называют эту роль не тестировщиком, а программистом тестов, или типа того. Это оправдано для многих организаций, готовых инвестировать в кадры. НО, для индустриальных компаний, которые занимаются массовой разработкой, такой подход невозможен. У них большая текучка кадров, множество однотипных проектов, для которых экономически оправдан конвейерный подход.
Здесь этот термин был применён для дистанцирования от процесса разработки. Чтобы подчеркнуть, что программист отработал, пора сдавать/принимать систему. Кто её тестирует после этого — вот вопрос топика.
Иногда, для того, чтобы минимизировать затраты на тестирование, можно обосновать сокращённое, регрессионное тестирование — что изменения в системе не требуют полномасштабного системного тестирования.
Есть ещё несколько определений и подходов:
через структуру системы (состоит из интегрированных модулей/компонентов):
1. белый ящик — известен код модуля или компонента
2. серый ящик — известен код некоторых модулей / компонентов
3. чёрный ящик — код не известен, не доступен или не рассматривается. Проверяется корректность реализации всех требований к системе в целом.
по стадиям разработки:
1. модульное тестирование или тестирование компонент — выполняют разработчики. Тестировщики не могут обладать всем комплексом знаний о разработке. Иначе, получится нонсенс — для тестирования модуля проверяющему надо иметь подготовку, не хуже автора. Поэтому используются инспекции и аудит прочими разработчиками.
2. интеграционное тестирование — когда некоторые модули готовы к интеграции. Цель — проверить их взаимодействие. Иногда что-то из этого могут делать тестировщики, но основная задача — не столько проверить, сколько отладить работу модуля — для разработчика.
3. система собрана — системное тестирование. Разработчикам, в общем, не требуется участвовать, т.к. проверка проходит через высокоуровневые спецификации — через те документы, по которым ставились задачи разработчикам, через проектную документацию, и через пользовательскую документацию. Проверяется корректность реализации требований к системе.
Это тестирование системы в целом. Чаще всего подразумевают — функциональное тестирование, хотя, в общем-то, могут быть и другие — нефункциональные — виды тестирования системы в целом: нагрузочное, безопасности и пр.
Основное, что это не тестирование модулей или компонент, т.е. без рассмотрения кода.
1. Под это даже методологию придумали — для экстремалов, как говорится.
2. Если не хотят потратиться на тестировщиков, то на них и не разорятся. Разорятся на ком-то другом...(игра слов, каламбур, смеяться, минусы не ставить :-)
Спасибо за «совет», но у меня своя точка зрения на этот вопрос. Это не баг, а фича — поддержка тут ни при чем. Повлиять на разработчика через ТАКОЕ сообщество — намного вероятнее чем через рутинный запрос, которых миллион. По-моему, два года прошло, прежде чем появились кнопки по сохранению отдельных вложений.
Смешная аналогия нашей "правды жизни", браво! Существует не только "нашенский" опыт, есть и остальной мир, в котором, кроме чести, кредитной и бизнес истории, есть и механизмы открытости и проверки для исключения мздоимства и прочей чернухи, осуждаемой в обществе.
Думаю, что корректнее говорить о степени сравнимости с аналогичными работниками, а не о "незаменимости". Правда жизни в том, что незаменимых нет (аксиома). В случае, если работник является сверх-квалифицированным, супер-эффективным и опытным "деятелем" для бизнеса, а не только специалистом - в этом случае самое элегантное решение - дать ему акции, ввести в состав акционеров, или, очень редко, и не всегда полезно, ввести в состав высших управленцев.
Ребячество и квасной патриотизм, конечно, но завлекает - как же немцам да не насолить :) Напрасно никто не перевел последний пункт Alles Schrott, надо было за него голосовать :) Кстати, увиденное сейчас сильно отличается от указываемых всеми цифр:
Lada 1119 50.27%
Умным руководителям компаний, направлений, отделов всегда нужны умные выпускники! Другое дело, что спецов по массовым ИТ-специальностям "неправильно готовят" в ВУЗах, а подготовка молодых ученых нужна редким фирмам. Но это отдельная песня :-)
Пишите, юноша, интересно и старикам...
Судя по описанию, видения "тамошних" частных школ и университетов, у вас нет?
Мы живем в обществе и подчиняемся его законам. Для сравнения, поиск на сайте хаха по двум буквам выдает: QC — 14 вариантов, QA — 143 варианта.
Из 14 только 8 относятся к данной области, смотрите, кто это:
Junior Test engineer,
Инженер по тестированию ПО,
Координатор по контролю качества (Quality Assurance/ Quality Controll Coordinator).
QA Controller / Контролер по обеспечению качества
Руководитель группы инженеров по тестированию
Quality Control Manager
Quality Control Manager (Concrete Industry)
Manager of Document and Quality Control
Конечно, профессионалы должны быть выше «толпы», но высоко отрываться позволительно лишь академическим личностям, а не практикам, иначе окружающие не будут понимать… ИМХО
Тестирование системы как черного ящика не имеет никакого отношения к пониманию кода, но общее понимание устройства — необходимо. И часто — достаточно. И не факт, что совершенствуясь в понимании устройства — некто, не имея таланта или тяги к тестированию как деструктивному подходу — сможет соревноваться в процессе разрушения. ИМХО.
У меня был лишь один студент за 8 лет, кто ушел в разработчики, правда и студентов было мало :-) менее 10. Не поддерживаю такого подхода — ставить неопытных на тестирование — это примитивно, безответственно и неэффективно. Другое дело, что расти как профессионал нужно с простых, элементарных активностей. Но это другая песня, про наставничество, линейный рост в профессии.
Признателен за эту фразу — «изучить логику начальника».
victor435.habrahabr.ru/blog/45759/
Иногда, для того, чтобы минимизировать затраты на тестирование, можно обосновать сокращённое, регрессионное тестирование — что изменения в системе не требуют полномасштабного системного тестирования.
через структуру системы (состоит из интегрированных модулей/компонентов):
1. белый ящик — известен код модуля или компонента
2. серый ящик — известен код некоторых модулей / компонентов
3. чёрный ящик — код не известен, не доступен или не рассматривается. Проверяется корректность реализации всех требований к системе в целом.
по стадиям разработки:
1. модульное тестирование или тестирование компонент — выполняют разработчики. Тестировщики не могут обладать всем комплексом знаний о разработке. Иначе, получится нонсенс — для тестирования модуля проверяющему надо иметь подготовку, не хуже автора. Поэтому используются инспекции и аудит прочими разработчиками.
2. интеграционное тестирование — когда некоторые модули готовы к интеграции. Цель — проверить их взаимодействие. Иногда что-то из этого могут делать тестировщики, но основная задача — не столько проверить, сколько отладить работу модуля — для разработчика.
3. система собрана — системное тестирование. Разработчикам, в общем, не требуется участвовать, т.к. проверка проходит через высокоуровневые спецификации — через те документы, по которым ставились задачи разработчикам, через проектную документацию, и через пользовательскую документацию. Проверяется корректность реализации требований к системе.
Основное, что это не тестирование модулей или компонент, т.е. без рассмотрения кода.
2. Если не хотят потратиться на тестировщиков, то на них и не разорятся. Разорятся на ком-то другом...(игра слов, каламбур, смеяться, минусы не ставить :-)
Lada 1119 50.27%
Пишите, юноша, интересно и старикам...
Судя по описанию, видения "тамошних" частных школ и университетов, у вас нет?