Пардон, откуда же преподавателей найдут для подготовки преподавателей? 2 тысячи резюме и на выходе лишь 5ро? Не быстро же однако. Плюс непрактикующий преподаватель производит обычно выпускника неспособного к практике…
В Индии, на которую ссылаются тут, начальный набор преподавателей создавали до 98 года уже посылая на учебу в те же США. Ну и потом уже по целевым программам массово. Теряя многих невозвращенцев, конечно. В общем не за 10 лет все это строилось совсем как тут описано.
Вещь, конечно, интересная. Но вызывает изумление список претензий к известным инструментам авторизации тестирования. Я работаю на Selenium и откровенно не понимаю в чем проблема с автоматической прогонкой теста в разных браузерах, получением отчетности по каждой верификации и уж тем более о каких юнит тестах в этом случае идет речь.
В общем не убедили. Тем более что продемонстрирован только механизм записи и воспроизведения действий, никакой проверки действий я не увидил. Ну а идентификаторы… Не буду спешить с выводами но хотелось бы посмотреть как это все заработает на реальном сайте, а не специально созданном под такого рода тест.
Не без того, были такие опасения и есть. Не понял про первые N мегабайт только — вроде подключение стабильно на этой скорости работает. И за 40 в месяц реальные 15 мегабит + ТВ — вполне достойная цена как по мне. Особенно если принять во внимание цены на мобильную связь, где конечно ужас что творится.
Статья очень порадовала, как-то упустил выход сервиса в мир если честно. Помню что у него есть еще как минимум два конкурента, никто названия на напомнит? Технология более чем перспективная и желанная для производителей т.к. 1) позволяет убрать ограничения на железо пользователя, 2) переводит всех с разового платежа за игру и связанного с этим пиратства на тотальную подписку и абонентскую плату. А это очень вкусный пирог стоящий вложений.
Единственное что удивило — это описание проблем с скоростью сети. Да, об этом постоянно тут жалуются, но речь при этом идет в основном о скорости и стабильности _мобильного_ интернета. Если у вас базовый инетернет-пакет от какого Comcast, то да, это будет 1.5 мегабита за 25$ в месяц и это будет повод для растроиств. Но зачем брать стандартный базовый пакет в стране, где все построенно на скидках, пакетных предложениях и промопериодах? Даже сейчас на том же Комкасте основное предложение — 15 мегабит за 20 долларов в месяц. И пусть там написано что это промоакция на 6 месяцев — безо всяких действий с моей стороный она длится уже больше года и включает базовый пакет телевидения. Причем реальная связь с сервером в Сан Франциско прямо сейчас из Маунтин Вью — 10 мегабит на скачку, 3 на закачку. В общем сложно жаловаться как по мне.
Спасибо за комментарии. Но как раз осмысление приведенных выше вопросов подталкивает к тому чтобы не тратить время даже на общение с менеджерами uTest. Ну как минимум в моем случае. Альтернативой выглядит контрактник-профессионал, что будет чуть дороже но гораздо надежнее. А если учесть издержки на указанные мною моменты как-то подготовка документации и т.п. — то может и так уж дешевле.
1) как вы сами верно подметили сборка таким образом «уходит в народ» без возможности даже уличить виновника пропажи. Контрактник же — конкретный человек, даже если работает удаленно. Ясно с кого спросить.
2) Тут можно называть как хочешь, поиском багов или обеспечением качества, но в любом случае к приложению даже среднего уровня сложности придется приложить какую-то документацию, которую придется содать (да, у нас и инструкции для пользователя нет :) ). То есть если это стартапный проект который предлагает что-то новое, без очевидных аналогов — придется объяснять как это работает. Контрактнику можно объяснить за час демонстрации и в любой момент ответить на его звонок-вопрос.
3) Окружение — ценный и недешевый ресурс. Контрактник может работать на общем тестовом окружении, подчиняясь общему режиму работы (циклу билдов к примеру). Краудсореры хороши, как вы подметили, свой способностью работать ночь, в выходные, постоянно — с ними делить окружение невыгодно, слишком много помех для наших собственных работ.
4) Вы бы видели как спорили у нас на работе два таких носителя языка — один из Мексики, второй вроде с Коста-Рики. Как оказалось в их версиях испанского [monetary] remittance совершенно по разному переводится, какие-то там мне недоступные культурные особенности. Другое дело, проверить против бумажки с утвержденным текстом, конечно…
5) Уф, тут опять же проблемка — мне чтобы протестировать один use case нужно пройти его с 4 разными телефонными номерами, просто проверяя позитивные случаи. После этого эти 4 телефоных номера в каких то частях приложения можно использовать для тестирования, для каких-то — придется регистрировать пользователя заново и использовать новый телефон. Не думаю что у всех краудсорсеров есть несколько телефонов, им просто придется вставлять какие-то произвольные, а уж если решат поискать баги в валидаторе телефонного номера… А между тем реальные люди будут получать вполне конктреные смски «Такой-то перевел вам столько то денег, позвоните в такую-то фирму по такому-то телефону».
В общем, все это можно списать на мой частный случай. И это будет верно. Но вместе с тем мне не очень легко представить некий обобщенный случай приложений, которые удобно тестировать краудсорсингом. По трем основным причинам, наверное: 1) у краудсорсеров нет нужных ресурсов, 2) с ними сложно быстро решать вопросы, уточнять, комментировать, 3) наладить работу с краудсорсерами и принять результаты требует достаточно существенных расходов.
Довольно часто на рабочий e-mail приходят рекламки от этого проекта. И в принципе такого рода помощь могла бы быть полезной (я сам QA, но у нас есть несколько узких мест, где краудсорсинг сильно бы помог). Поэтому особенно интересен вопрос со стороны заказчика. Вот какие сомнения меня одолевают:
проект хорош для веб приложений, но что делать со stand alone?
документация — в нашей небольшой команде все очень динамично, поэтому документации практически нет, она мгновенно устаревает и в ней практически нет смысла. Если отдавать кому-то на тестирование — придется достаточно много подготовить, как минимум подробный тест сценарий
для внешнего тестирования пришлось бы выделять отдельное тестовое окружение — пара серверов, несколько наборов ключей и т.п. Это тоже ест ресурсы и время
про то что нужно выделить время на управление заказом, разбор и анализ багов и т.п. — самоочевидный факт
локализация — вещь для проверки не такая простая, когда речь идет о формулировках, диктуемой маркетингом терминологии и т.п.
как гарантировать что телефонные номера, которые будут использовать тестировщики, будут принадлежать именно им? В противном случае приложение будет честно высылать уведомления на телефоны ничего не подозревающих людей, создавая проблемы с юридическим притензиями в том числе
Это лишь пример того, какие моменты могут останавливать от размещения заявок на данном проекте, лично меня и нашу компанию. Насколько я понимаю, часть проблем можно конечно обойти, но в целом на прокте имеет смысл размещать заказы только очень узкому кругу клиентов. Может быть кто-то приведет примеры что именно предлагается там для тестирования?
То есть добываем «солнечное электричество» в Сахаре, допустим даже на месте перегоняем его в метан теряя 40% на КПД, потом татимся на перевозку метана ну в ту же Германию, допустим по газопроводу. В Германии все тот же метан перегоняем обратно в электричество на ТЭЦ теряя еще сколько-то на КПД и доставляем к конечному потребителю наконец. Что-то многовато потерь с учетом того что в эту Сахару еще как-то воду подвозить нужно, а она в тех краях подороже электричества может быть.
Можно присоединиться к последующим ораторам. В целом действительно неплоха, но и в самом деле неспешна. Не то чтобы сильно мешало, но над этим стоило бы поработать.
Баги-таски к коммитам подключаются на ура — ставишь в коммент к коммиту номер бага-таска в особом синтаксисе и это тикет переходит в Test (типа как готово к тестированию). Особенность — заточеность под agile методологию и в частности scrum. Это видно во всем от особого тула Scrum Report и ведения майлстоунов, до системы организации тикетов. Мне нравится, но для традиционных QA (о моя бедная начальница) может быть очень раздражающим bug life cycle заточенный под тесную интеграцию с разработчиками и их тасками. Ну и так как баги — это только подвид тикетов наряду с тасками, не очень удобно встроенными графиками мониторить все это. Ну это с моей QA колокольни.
Хранение кода как по мне — отлично, все что нужно svn кладовка делает. Wiki… ну не сказал бы что сильно глючит. Плюс вчерав вот был новый релиз, добавили рюшечек и отимпрувили кодохранилища.
Assembla — поддерживает svn/git, собственная система тикетов, менеджмент проектов, вики, traс для желающих, несколько простраств для разных департаментов или проектов ну и прочие плюшки
Вы еще добавьте о такой распространненой практике как прохождение в community college ряда предметов «по дешевке» и без вступительных экзаменов (набор кредитов в общем) и последующий трансфер на 3-4 год бакалаврской программы в более престижном университете. Насколько я в курсе — наиболее оптимальный вариант получения респектабельной degree того или иного престижного университета. Ну в плане стоимости как минимум. Сами часом не так планируете?
Вопрос в «эвалюации» диплома. В большинсве случаев местные которы приравнивают нашего специалиста к местному магистру. Для этого собираются документы, приложение к диплому с указанием часов по каждому предмету, и все это переводится в кредитную систему с сопоставлением с местными предметами по названию. Вот по количеству часов-кредитов и выходит магистр.
Идея с фитболом показалась ужасной сначала (как же на нем сидеть без спинки то? на что откинуться?). Потом показал жене и она объяснила что у них на работе (в Гугле) эти фитболы разбросаны везде обсолютно в качестве сидений. И хотя большинство сидит за сталами на креслах, но если нужно что-то где-то обсудить вне своего рабочего места, то либо берут с собой фитбол, либо по пути подбирают и катят его к назначенному месту.
Это смотря что вы имеете ввиду — сама бизнес модель, безопасность транзакций или что вообще? В общем, если есть конкретные вопросы — пишите в личку, что смогу — отвечу. Тем более что я все же на американском рынке работаю, могут быть и отличия.
Посылать полные реквизиты карточки по СМС? Ужас какой… Наша контора работает с мобильными трансферами денег. Так чтобы соответствовать требованиям безопасности в этой области мы даже не сможем позволять аутентификацию через отправку пароля смской. Вместо нее придется ставить IVR. Пользователь получит входящий звонок, и милый женский голос предложит набрать на клавиатуре пароль. А дальше шифрование и т.п. на серверной стороне IVR партнера, сравнение хешей с нашим сервером и ответ по API — получена аутентификация или нет.
В общем очень удивлся такому раскладу с отправкой номера карты по смс
В Индии, на которую ссылаются тут, начальный набор преподавателей создавали до 98 года уже посылая на учебу в те же США. Ну и потом уже по целевым программам массово. Теряя многих невозвращенцев, конечно. В общем не за 10 лет все это строилось совсем как тут описано.
Спасибо за статью!
В общем не убедили. Тем более что продемонстрирован только механизм записи и воспроизведения действий, никакой проверки действий я не увидил. Ну а идентификаторы… Не буду спешить с выводами но хотелось бы посмотреть как это все заработает на реальном сайте, а не специально созданном под такого рода тест.
Единственное что удивило — это описание проблем с скоростью сети. Да, об этом постоянно тут жалуются, но речь при этом идет в основном о скорости и стабильности _мобильного_ интернета. Если у вас базовый инетернет-пакет от какого Comcast, то да, это будет 1.5 мегабита за 25$ в месяц и это будет повод для растроиств. Но зачем брать стандартный базовый пакет в стране, где все построенно на скидках, пакетных предложениях и промопериодах? Даже сейчас на том же Комкасте основное предложение — 15 мегабит за 20 долларов в месяц. И пусть там написано что это промоакция на 6 месяцев — безо всяких действий с моей стороный она длится уже больше года и включает базовый пакет телевидения. Причем реальная связь с сервером в Сан Франциско прямо сейчас из Маунтин Вью — 10 мегабит на скачку, 3 на закачку. В общем сложно жаловаться как по мне.
1) как вы сами верно подметили сборка таким образом «уходит в народ» без возможности даже уличить виновника пропажи. Контрактник же — конкретный человек, даже если работает удаленно. Ясно с кого спросить.
2) Тут можно называть как хочешь, поиском багов или обеспечением качества, но в любом случае к приложению даже среднего уровня сложности придется приложить какую-то документацию, которую придется содать (да, у нас и инструкции для пользователя нет :) ). То есть если это стартапный проект который предлагает что-то новое, без очевидных аналогов — придется объяснять как это работает. Контрактнику можно объяснить за час демонстрации и в любой момент ответить на его звонок-вопрос.
3) Окружение — ценный и недешевый ресурс. Контрактник может работать на общем тестовом окружении, подчиняясь общему режиму работы (циклу билдов к примеру). Краудсореры хороши, как вы подметили, свой способностью работать ночь, в выходные, постоянно — с ними делить окружение невыгодно, слишком много помех для наших собственных работ.
4) Вы бы видели как спорили у нас на работе два таких носителя языка — один из Мексики, второй вроде с Коста-Рики. Как оказалось в их версиях испанского [monetary] remittance совершенно по разному переводится, какие-то там мне недоступные культурные особенности. Другое дело, проверить против бумажки с утвержденным текстом, конечно…
5) Уф, тут опять же проблемка — мне чтобы протестировать один use case нужно пройти его с 4 разными телефонными номерами, просто проверяя позитивные случаи. После этого эти 4 телефоных номера в каких то частях приложения можно использовать для тестирования, для каких-то — придется регистрировать пользователя заново и использовать новый телефон. Не думаю что у всех краудсорсеров есть несколько телефонов, им просто придется вставлять какие-то произвольные, а уж если решат поискать баги в валидаторе телефонного номера… А между тем реальные люди будут получать вполне конктреные смски «Такой-то перевел вам столько то денег, позвоните в такую-то фирму по такому-то телефону».
В общем, все это можно списать на мой частный случай. И это будет верно. Но вместе с тем мне не очень легко представить некий обобщенный случай приложений, которые удобно тестировать краудсорсингом. По трем основным причинам, наверное: 1) у краудсорсеров нет нужных ресурсов, 2) с ними сложно быстро решать вопросы, уточнять, комментировать, 3) наладить работу с краудсорсерами и принять результаты требует достаточно существенных расходов.
Это лишь пример того, какие моменты могут останавливать от размещения заявок на данном проекте, лично меня и нашу компанию. Насколько я понимаю, часть проблем можно конечно обойти, но в целом на прокте имеет смысл размещать заказы только очень узкому кругу клиентов. Может быть кто-то приведет примеры что именно предлагается там для тестирования?
Баги-таски к коммитам подключаются на ура — ставишь в коммент к коммиту номер бага-таска в особом синтаксисе и это тикет переходит в Test (типа как готово к тестированию). Особенность — заточеность под agile методологию и в частности scrum. Это видно во всем от особого тула Scrum Report и ведения майлстоунов, до системы организации тикетов. Мне нравится, но для традиционных QA (о моя бедная начальница) может быть очень раздражающим bug life cycle заточенный под тесную интеграцию с разработчиками и их тасками. Ну и так как баги — это только подвид тикетов наряду с тасками, не очень удобно встроенными графиками мониторить все это. Ну это с моей QA колокольни.
Хранение кода как по мне — отлично, все что нужно svn кладовка делает. Wiki… ну не сказал бы что сильно глючит. Плюс вчерав вот был новый релиз, добавили рюшечек и отимпрувили кодохранилища.
В общем очень удивлся такому раскладу с отправкой номера карты по смс
А если нужно создать лист с конкретным количеством рядов-колонок? В этом случае рецепт автора выглядит достаточно эффективным. Нет?