Оставлю эту инфу тут тоже.
По поводу: «Т.е. у человека при всем желании проголосовать за проект так просто не получится, и как с этим бороться для нас пока не понятно…»
Относительно миграции из тестера в геймдизы — достаточно утопичный план на полгода-год.
По факту, если вас нанимает компания, да еще и с нуля — она рассчитывает на вас в первую очередь как на тестера и должна отбить затраты на ваш найм и обучение. Полгода-год — это утопия! %)
Интересно, но меховатости немного — выглядит так, будто наложили Clarity в фотошопе на картинку (при близком рассмотрении).
Издали же — как дома с котиками ^^'
«В QA должны быть юзеры максимально приближенные к реальным» Ну нет :)
В QA должны быть люди, которые должны уметь придумать как померить качество продукта (смотрете, не «протестировать», а «померить качество») наиболее эффективно и наименее трудозатратно. Может выпустить в общие тест игру, может научиться пользовать фишай и делать кодревью, может проектировать юнит-тесты, может молиться на иконостас с Гейбом.
QA и тестировщики — это разное. И стрёмно думать, что для многих QA ограничивается только тестированием :)
А может в этой ситуации стоит повысить уровень тестировщика. рассказать ему что такое MVC, как работает django или еще что-то полезное?
В таком случае и догадки будут осознанные :)
А еще можно давать доступ к исходникам и возможность поковыряться. Тогда может быть вам еще и советы давать будут — мотивирует свой уровень поднять. :)
Глупости. Сказки несостоявшейся «обезьянки», которая держится за свое место и ноет в бложик.
Слухи их других компаний о «тестировщиках» — это далеко не первый параметр, по которому происходит найм.
Кейсов много, во многом они зависят от контекста проекта.
В моей практике, например, был случай, когда ошибка возникала в многопоточной обработке некоторой сущности. То есть в реальных условиях проявлялась в одном случае на (боюсь соврать, но...) миллион.
Это вскрылось во время пристального изучения кода тестировщиками (специфика проекта позволяла и во многом одобряла белый ящик), и соответственно верифицировалась через код ревью ими же.
***
Случай, конечно, нетривиальный, но много багов было найдено подобным образом в рамках проекта (анализ кода там был неотъемлемой составляющей для понимания работы системы вцелом).
Обобщая, в каких ситуациях это нужно: когда у нас в системе используются сложные составные сущности, взаимодейсвтие которых раскрывается в многостраничных талмудах архитектуры или раскрывается скупо в тестовой документации — разумно использовать анализ кода (эту идею я выдвигал в своем докладе на SQA8, но, к сожалению, так и не выступил с ним вживую — не позволил проект вырваться в Харьков).
Разные взгляды. Меня учили, что разработчик — то кто занимается непосредственно разработкой, программист — разработчик + тот кто выполняет смежные задачи разработки (например, специалист занимающийся юнит-тестированием).
Думаю, все равно мысль я свою донес: хороший тестировщик должен уметь программировать.
А вам не кажется, что вы не учли простого факта: что из тестеров должны расти ТМы?
По вашему описанию — есть мозг (ТМ), есть руки (тестеры). Мозг руководит — руки делают.
Теперь вклбчим человеческий фактор — как долго руки останутся руками? Если долго — насколько они будут эффективны спустя полгода?
Описанная вами схема на моих глазах работает только с новичками. Получив некоторые опыт — они загораются идеями и простым тестированием и валидацией дефектов от них не отделаешься.
Попробуйте прочитать статью как «Сферический тестировщик в вакууме, каким он должен быть?» — тогда позиция Натальи вам станет ближе.
P.S. Извините, наболело. По-крайней мере меня всегда удивляли люди, которые чтобы внести дефект с повышенным приоритето — звонили ТМу, который вышел пообедать. Даже не смотря на то, что функционал имеет особую важность в продукте.
По поводу:
«Т.е. у человека при всем желании проголосовать за проект так просто не получится, и как с этим бороться для нас пока не понятно…»
Используйте ссылку вида:
steam://steamcommunity.com/sharedfiles/filedetails/?id=425876040
и проект гринлайта будет открываться в стиме напрямую. Файрфокс умеет открывать, хром не всегда.
developer.valvesoftware.com/wiki/Talk:Steam_browser_protocol вот тут подробнее про протокол можно почитать
www.exploit-db.com/docs/22008.pdf и вот тут
По факту, если вас нанимает компания, да еще и с нуля — она рассчитывает на вас в первую очередь как на тестера и должна отбить затраты на ваш найм и обучение. Полгода-год — это утопия! %)
Издали же — как дома с котиками ^^'
В QA должны быть люди, которые должны уметь придумать как померить качество продукта (смотрете, не «протестировать», а «померить качество») наиболее эффективно и наименее трудозатратно. Может выпустить в общие тест игру, может научиться пользовать фишай и делать кодревью, может проектировать юнит-тесты, может молиться на иконостас с Гейбом.
QA и тестировщики — это разное. И стрёмно думать, что для многих QA ограничивается только тестированием :)
Эффективные коммуникации!
В таком случае и догадки будут осознанные :)
А еще можно давать доступ к исходникам и возможность поковыряться. Тогда может быть вам еще и советы давать будут — мотивирует свой уровень поднять. :)
Слухи их других компаний о «тестировщиках» — это далеко не первый параметр, по которому происходит найм.
С праздником, коллеги!)
Чем ваша платформа лучше\выгоднее?
Она настолько тривиальна, что у них может сформироваться «комплекс гуру» за два-три дня.
В моей практике, например, был случай, когда ошибка возникала в многопоточной обработке некоторой сущности. То есть в реальных условиях проявлялась в одном случае на (боюсь соврать, но...) миллион.
Это вскрылось во время пристального изучения кода тестировщиками (специфика проекта позволяла и во многом одобряла белый ящик), и соответственно верифицировалась через код ревью ими же.
***
Случай, конечно, нетривиальный, но много багов было найдено подобным образом в рамках проекта (анализ кода там был неотъемлемой составляющей для понимания работы системы вцелом).
Обобщая, в каких ситуациях это нужно: когда у нас в системе используются сложные составные сущности, взаимодейсвтие которых раскрывается в многостраничных талмудах архитектуры или раскрывается скупо в тестовой документации — разумно использовать анализ кода (эту идею я выдвигал в своем докладе на SQA8, но, к сожалению, так и не выступил с ним вживую — не позволил проект вырваться в Харьков).
Приму к сведению :)
Думаю, все равно мысль я свою донес: хороший тестировщик должен уметь программировать.
По вашему описанию — есть мозг (ТМ), есть руки (тестеры). Мозг руководит — руки делают.
Теперь вклбчим человеческий фактор — как долго руки останутся руками? Если долго — насколько они будут эффективны спустя полгода?
Описанная вами схема на моих глазах работает только с новичками. Получив некоторые опыт — они загораются идеями и простым тестированием и валидацией дефектов от них не отделаешься.
Попробуйте прочитать статью как «Сферический тестировщик в вакууме, каким он должен быть?» — тогда позиция Натальи вам станет ближе.
P.S. Извините, наболело. По-крайней мере меня всегда удивляли люди, которые чтобы внести дефект с повышенным приоритето — звонили ТМу, который вышел пообедать. Даже не смотря на то, что функционал имеет особую важность в продукте.