Слава Лукьяненко EdWing

Вот еще одна в апреле (Питер): http://www.wgdevforum.net/

Оставлю эту инфу тут тоже.
По поводу:
«Т.е. у человека при всем желании проголосовать за проект так просто не получится, и как с этим бороться для нас пока не понятно…»

Используйте ссылку вида:
steam://steamcommunity.com/sharedfiles/filedetails/?id=425876040

и проект гринлайта будет открываться в стиме напрямую. Файрфокс умеет открывать, хром не всегда.

developer.valvesoftware.com/wiki/Talk:Steam_browser_protocol вот тут подробнее про протокол можно почитать
www.exploit-db.com/docs/22008.pdf и вот тут

Относительно миграции из тестера в геймдизы — достаточно утопичный план на полгода-год.
По факту, если вас нанимает компания, да еще и с нуля — она рассчитывает на вас в первую очередь как на тестера и должна отбить затраты на ваш найм и обучение. Полгода-год — это утопия! %)

Интересно, но меховатости немного — выглядит так, будто наложили Clarity в фотошопе на картинку (при близком рассмотрении).
Издали же — как дома с котиками ^^'

«В QA должны быть юзеры максимально приближенные к реальным» Ну нет :)
В QA должны быть люди, которые должны уметь придумать как померить качество продукта (смотрете, не «протестировать», а «померить качество») наиболее эффективно и наименее трудозатратно. Может выпустить в общие тест игру, может научиться пользовать фишай и делать кодревью, может проектировать юнит-тесты, может молиться на иконостас с Гейбом.
QA и тестировщики — это разное. И стрёмно думать, что для многих QA ограничивается только тестированием :)

То есть, суть пробелмы доносится через 3 «прокси» с большой ЗП и головной болью?
Эффективные коммуникации!

А может в этой ситуации стоит повысить уровень тестировщика. рассказать ему что такое MVC, как работает django или еще что-то полезное?
В таком случае и догадки будут осознанные :)
А еще можно давать доступ к исходникам и возможность поковыряться. Тогда может быть вам еще и советы давать будут — мотивирует свой уровень поднять. :)

Глупости. Сказки несостоявшейся «обезьянки», которая держится за свое место и ноет в бложик.
Слухи их других компаний о «тестировщиках» — это далеко не первый параметр, по которому происходит найм.

Нравится работать бессмысленно — ваше личное дело, только вот плакаться по такому глупо.

Надо менять работу. Вот и весь сказ.

Каждый код — хорошая описочка ;)

Каждый год одна и та же историческая справка. :3
С праздником, коллеги!)

Хм, идея слабо отличается от en.cx
Чем ваша платформа лучше\выгоднее?

Попробуйте выставить целевой язык «английский» и прослушайте еще раз.

Не стал бы ее советовать начинающим.
Она настолько тривиальна, что у них может сформироваться «комплекс гуру» за два-три дня.

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

Обобщая, в каких ситуациях это нужно: когда у нас в системе используются сложные составные сущности, взаимодейсвтие которых раскрывается в многостраничных талмудах архитектуры или раскрывается скупо в тестовой документации — разумно использовать анализ кода (эту идею я выдвигал в своем докладе на SQA8, но, к сожалению, так и не выступил с ним вживую — не позволил проект вырваться в Харьков).

Ваша точка зрения разумнее.
Приму к сведению :)

Кажется именно это, но другими словами я и написал выше.

Разные взгляды. Меня учили, что разработчик — то кто занимается непосредственно разработкой, программист — разработчик + тот кто выполняет смежные задачи разработки (например, специалист занимающийся юнит-тестированием).

Думаю, все равно мысль я свою донес: хороший тестировщик должен уметь программировать.

А вам не кажется, что вы не учли простого факта: что из тестеров должны расти ТМы?

По вашему описанию — есть мозг (ТМ), есть руки (тестеры). Мозг руководит — руки делают.
Теперь вклбчим человеческий фактор — как долго руки останутся руками? Если долго — насколько они будут эффективны спустя полгода?
Описанная вами схема на моих глазах работает только с новичками. Получив некоторые опыт — они загораются идеями и простым тестированием и валидацией дефектов от них не отделаешься.

Попробуйте прочитать статью как «Сферический тестировщик в вакууме, каким он должен быть?» — тогда позиция Натальи вам станет ближе.

P.S. Извините, наболело. По-крайней мере меня всегда удивляли люди, которые чтобы внести дефект с повышенным приоритето — звонили ТМу, который вышел пообедать. Даже не смотря на то, что функционал имеет особую важность в продукте.

Согласен.
Просто понятие «программист» — несколько шире, чем «разработчик». Я хотел указать именно на это: хороший тестировщик должен уметь программировать.

Например, чтобы очень хорошо автоматизировать тестирование.

То есть по вашему из стремления правильно спроектировать тест не появится знание проекта?

Показательтный пример, когда правильный тестировщик первые дни\недели на проекте остается на пару часов дольше, чтобы лучше изучить проект.

Выскажу, в чем я не согласен с п.6, пока коллега молчит:
Сказать «Я эксперт» — можно в разном контексте (см. пункт 7). Например, когда в борьбе за тендер нужна оценка какого-то специалиста два года занимавшегося тестированием биллинговых систем — мы, да и сам специалист, может назвать себя экспертом в данной области.
Просто потому что нам нужна «экспертная оценка в данной области».
***
А в целом же, я понимаю, что суть 6 пункта в том, что говорить «Я настолько крутой тестировщик, что аж дальше некуда» — мягко говоря глупо. (:

Согалсен, по-моему менее затратно будет доверить такую работу опытному тестировщику.
А подход интересный…

А я запоминал через анекдот, где Чапаев объяснял Петьке, что красные тут, а по другую сторону реки — белые. :)

Другое видение:
у вас есть возможность обеспечить ТОЛЬКО хорошее функциональное тестирование (что поделать, если бюджет мал — отсальное забрали спиногрызы-разработчики).

Я не спорю, что тестировать нужно все.
Но иногда, когда пытаешься предложить кастомеру автоматизацию или перфоманс — он отказывается просто потому что выйдет out of money.

Тестировать нужно то, что наиболее критично. А если позволяют деньги — то и все остальное :)

На «тестировать ВСЕ» нужен очень хороший бюджет.

Он как бы говорит «Chill out, baby!» :)

Ни о чем.
Покрутили голым интерфейсом, показали синхронизацию с гугл-акком, засветили дропбокс… и?
Ничего нового.

ОФФ: у вас приятные обои. Не подскажете что за они?)

Думаю ничто не мешает выдрать из видео-аудио.
Больше каналов восприятия — не значит хуже)

Побольше у нас, поменьше у юзера, все взаимосвязано (:
С праздником!

Добавьте тестировщиков в профессии — цены вам не будет (:

Да! (:

Для создания ОС, очень полезны навыки:
*Реконструкция сайта HTML
*Создание видеоролика о компании
*Реконструкция сайта на CMS (в частности на Drypal)
*Веб дизайн

Не совсем ясна разница в ролях «Инноватор» и «Исследователь», а также «Судья» и «Согласователь»?
Или они дублируются, потому что являются ключевыми?

Очень странное у вас представление об отделе тестирования, если честно. У нас «индусов» на реальные проекты не пускают два месяца, пока не научатся самостоятельно выполнять анализ требований и составлять скоуп необходимых требований.

Но положим даже так — изначально мы говорили о нежелательности практики увольнения «специалистов» в пользу бюджета. Индуса трудно назвать специалистом.

P.S. Как интересно скатилась тема от личной мотивации до управления командой тестирования…

Лучше договориться с заказчиком\работниками\саппортом о сдвиге сроков, превышении рабочего времени, задержки выплат, чем уволнять хороших сотрудников.
Хороший менеджер, в том числе и тест-менеджер, должен видеть далеко и предугадать когда стоит остановить рекрутинг, а не когда стоит начать увольнения.

Ужасный подход: уволнять из-за недостатка средств.
Найти и\или воспитать хорошего специалиста дороже выйдет в итоге.

Само собой :)
Но если сравнивать зарплаты Senior QA и Senior Developer — выигрыш, я уверен, будет в сторону разработчика.
Думаю со средними показателями ситуация будет аналогична.