Оставлю эту инфу тут тоже.
По поводу: «Т.е. у человека при всем желании проголосовать за проект так просто не получится, и как с этим бороться для нас пока не понятно…»
Относительно миграции из тестера в геймдизы — достаточно утопичный план на полгода-год.
По факту, если вас нанимает компания, да еще и с нуля — она рассчитывает на вас в первую очередь как на тестера и должна отбить затраты на ваш найм и обучение. Полгода-год — это утопия! %)
Интересно, но меховатости немного — выглядит так, будто наложили Clarity в фотошопе на картинку (при близком рассмотрении).
Издали же — как дома с котиками ^^'
«В QA должны быть юзеры максимально приближенные к реальным» Ну нет :)
В QA должны быть люди, которые должны уметь придумать как померить качество продукта (смотрете, не «протестировать», а «померить качество») наиболее эффективно и наименее трудозатратно. Может выпустить в общие тест игру, может научиться пользовать фишай и делать кодревью, может проектировать юнит-тесты, может молиться на иконостас с Гейбом.
QA и тестировщики — это разное. И стрёмно думать, что для многих QA ограничивается только тестированием :)
А может в этой ситуации стоит повысить уровень тестировщика. рассказать ему что такое MVC, как работает django или еще что-то полезное?
В таком случае и догадки будут осознанные :)
А еще можно давать доступ к исходникам и возможность поковыряться. Тогда может быть вам еще и советы давать будут — мотивирует свой уровень поднять. :)
Глупости. Сказки несостоявшейся «обезьянки», которая держится за свое место и ноет в бложик.
Слухи их других компаний о «тестировщиках» — это далеко не первый параметр, по которому происходит найм.
Кейсов много, во многом они зависят от контекста проекта.
В моей практике, например, был случай, когда ошибка возникала в многопоточной обработке некоторой сущности. То есть в реальных условиях проявлялась в одном случае на (боюсь соврать, но...) миллион.
Это вскрылось во время пристального изучения кода тестировщиками (специфика проекта позволяла и во многом одобряла белый ящик), и соответственно верифицировалась через код ревью ими же.
***
Случай, конечно, нетривиальный, но много багов было найдено подобным образом в рамках проекта (анализ кода там был неотъемлемой составляющей для понимания работы системы вцелом).
Обобщая, в каких ситуациях это нужно: когда у нас в системе используются сложные составные сущности, взаимодейсвтие которых раскрывается в многостраничных талмудах архитектуры или раскрывается скупо в тестовой документации — разумно использовать анализ кода (эту идею я выдвигал в своем докладе на SQA8, но, к сожалению, так и не выступил с ним вживую — не позволил проект вырваться в Харьков).
Разные взгляды. Меня учили, что разработчик — то кто занимается непосредственно разработкой, программист — разработчик + тот кто выполняет смежные задачи разработки (например, специалист занимающийся юнит-тестированием).
Думаю, все равно мысль я свою донес: хороший тестировщик должен уметь программировать.
А вам не кажется, что вы не учли простого факта: что из тестеров должны расти ТМы?
По вашему описанию — есть мозг (ТМ), есть руки (тестеры). Мозг руководит — руки делают.
Теперь вклбчим человеческий фактор — как долго руки останутся руками? Если долго — насколько они будут эффективны спустя полгода?
Описанная вами схема на моих глазах работает только с новичками. Получив некоторые опыт — они загораются идеями и простым тестированием и валидацией дефектов от них не отделаешься.
Попробуйте прочитать статью как «Сферический тестировщик в вакууме, каким он должен быть?» — тогда позиция Натальи вам станет ближе.
P.S. Извините, наболело. По-крайней мере меня всегда удивляли люди, которые чтобы внести дефект с повышенным приоритето — звонили ТМу, который вышел пообедать. Даже не смотря на то, что функционал имеет особую важность в продукте.
Согласен.
Просто понятие «программист» — несколько шире, чем «разработчик». Я хотел указать именно на это: хороший тестировщик должен уметь программировать.
Выскажу, в чем я не согласен с п.6, пока коллега молчит:
Сказать «Я эксперт» — можно в разном контексте (см. пункт 7). Например, когда в борьбе за тендер нужна оценка какого-то специалиста два года занимавшегося тестированием биллинговых систем — мы, да и сам специалист, может назвать себя экспертом в данной области.
Просто потому что нам нужна «экспертная оценка в данной области».
***
А в целом же, я понимаю, что суть 6 пункта в том, что говорить «Я настолько крутой тестировщик, что аж дальше некуда» — мягко говоря глупо. (:
Другое видение:
у вас есть возможность обеспечить ТОЛЬКО хорошее функциональное тестирование (что поделать, если бюджет мал — отсальное забрали спиногрызы-разработчики).
Я не спорю, что тестировать нужно все.
Но иногда, когда пытаешься предложить кастомеру автоматизацию или перфоманс — он отказывается просто потому что выйдет out of money.
Тестировать нужно то, что наиболее критично. А если позволяют деньги — то и все остальное :)
Для создания ОС, очень полезны навыки:
*Реконструкция сайта HTML
*Создание видеоролика о компании
*Реконструкция сайта на CMS (в частности на Drypal)
*Веб дизайн
Очень странное у вас представление об отделе тестирования, если честно. У нас «индусов» на реальные проекты не пускают два месяца, пока не научатся самостоятельно выполнять анализ требований и составлять скоуп необходимых требований.
Но положим даже так — изначально мы говорили о нежелательности практики увольнения «специалистов» в пользу бюджета. Индуса трудно назвать специалистом.
P.S. Как интересно скатилась тема от личной мотивации до управления командой тестирования…
Лучше договориться с заказчиком\работниками\саппортом о сдвиге сроков, превышении рабочего времени, задержки выплат, чем уволнять хороших сотрудников.
Хороший менеджер, в том числе и тест-менеджер, должен видеть далеко и предугадать когда стоит остановить рекрутинг, а не когда стоит начать увольнения.
Само собой :)
Но если сравнивать зарплаты Senior QA и Senior Developer — выигрыш, я уверен, будет в сторону разработчика.
Думаю со средними показателями ситуация будет аналогична.