Pull to refresh
48
0
Слава Лукьяненко @EdWing

User

Send message
Вот еще одна в апреле (Питер): 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. Извините, наболело. По-крайней мере меня всегда удивляли люди, которые чтобы внести дефект с повышенным приоритето — звонили ТМу, который вышел пообедать. Даже не смотря на то, что функционал имеет особую важность в продукте.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Registered
Activity