Я сначала сам приехал сюда, потом привёз маленьких детей, и им уже на месте делал тут статус PR. Так можно. Но бумажек — уйма. Консультанты берут за это 2-3 тысячи канадских долларов. Я делал сам. Первый раз — неправильно. Второй — осилил. Потратил на это реально несколько дней плотной работы, оформляя документы. В сумме наверное пару недель. Вот недавно получил PR для них.
Живу в Канаде 4 года.
Тут, конечно, неплохо.
Но автор явно не в теме.
Да, для канадцев всегда существует возможность уехать в США, ведь для этого не нужно будет получать какие-либо специальные разрешения или визы.
Это не так. Зарплаты в Канаде значительно ниже, чем в США. Поэтому желающих уехать в США много. Но в США канадцам ехать можно только как туристам. Если на границе пограничник обнаружит ваши намерения ехать в США работать — запрет на въезд в США лет на 5-10.
Для программистов есть специальный пункт в NAFTA, что их могут пустить в США поработать год.
Но «не нужно будет получать какие-либо специальные разрешения или визы» — это вы фантазируете.
в Канаде намного проще и дешевле, чем в Сан-Франциско.
Канада большая.
Настолько большая, что в северных провинциях жить не только дешево, но государство ещё и доплачивать вам будет, если вы согласитесь там жить. Вот только желающих мало.
А вот если захотите жить немного южней, то «проще и дешевле» — это миф.
Стоимость жизни в Ванкувере уступает только стоимости жизни в Силиконовой долине. Очень дорого.
В Торонто немного дешевле, но не сильно.
В Монтреале дешево, но там не говорят по английски и зарплаты раза в два ниже чем в Ванкувере и Торонто.
Здесь нет коррупции хоть на уровне рядового полицейского, хоть на уровне премьер-министра.
Ага, вы в курсе, что нынешний премьер всё никак не может отмахаться от причастности к корупционному скандалу SNC-Lavalin? А так да — все тут белые и пушистые.
Вы никогда не встретитесь здесь с проявлением национализма
Про провинцию Квебек слышали? Они даже референдум проводили, потому что хотят быть отдельной страной.
Если вы говорите по английски и не говорите по французски, то заехав в Квебек вы быстро поймёте, что и ксенофобия и национализм здесь никуда не делись.
Я это всё не к тому, что Канада — плохая страна.
Я живу в Ванкувере, и тут неплохо.
Но рая на земле нет. Будьте реалистами.
А как надо выставлять — боком?
Не ходи дети, в Африку гулять…
Кто-нибудь может по русски пересказать вот это предложение:
отправить специально сформированный запрос службе удаленных рабочих столов целевых систем, используя RDP (сам протокол RDP при этом не является уязвимым).
Специальный запрос на RDP может его сломать, но при этом RDP неуязвим. Это как?
так в том-то и дело, что «не отвлекая от самого тестирования» лучше всего получается у Excel.
Все остальные инструменты отвлекают очень серьёзно.
Например, у вас есть сценарий:
— открыть приложение в браузере
— залогиниться
— сделать 3-4 CRUD операции
— разлогиниться
И вам надо тестировать это в 3-4 браузерах.
Если вы это делаете в Excel — это выделать мышкой регион и нажать Ctrl-V 3-4 раза.
Если вы это делаете в любой системе — вы не можете там сделать Ctrl-V на все шаги. Вы должны каждый шаг: 1) открыть, 2) ввести результат, 3) отправить. После каждого шага надо ждать, пока веб-сервер ответит (даже если это немного — это всё равно складывается).
В результате Excel уделывает любую систему раз в 10 по времени, которое тестеры надо потратить на то, чтобы ввести результаты.
Другой вариант:
допустим у вам в тест-кейсах есть какие-то детали, связанные с окружением: может имя сервера, или ожидаемый текст сообщения в ответе и т.д.
И если это поменялось, и надо изменить больше одного тест-кэйса, то в Excel — это «Find and Replace».
А вот в «полезном инструменте» это превращается в ад, когда надо вручную открыть и исправить стопятьсот кэйсов. Или сделать экспорт в Excel, исправить там, и импортировать обратно ;-) Это если у инструмента есть вменяемый импорт-экспорт
Статья на самом деле полезная, удалять не надо. Это очень полезно быть в курсе того, какие инструменты сегодня есть на рынке.
Я нередко наблюдал такую картину:
— в компании есть тестеры, которые тем или иным образом занимаются тестирование
— возникает «проблема». Проблемы, связанных с процессом может быть две:
а) тестеры прохлопали серьёзный баг, которые выкатили в продакшен (отправили клиенту, ...) и теперь начинают разбираться — а чем там тестеры занимались, кто виноват… Ну а тестеры прикрывают себе заднее место, никто не может понять кто и что тестировал. И тогда начальство решает: поставить систему, чтобы всё было видно: кто и что тестировал, и что не тестировали.
б) каждый раз, когда готовиться релиз, тестеры заваливают сроки. От них невозможно получить надёжного ответа на вопрос: что уже сделано и сколько осталось? И тогда начальство требует, чтобы им сделали дэшборды, чтобы там это всё было видно и «прозрачно».
В обоих случаях тестеры получают головную боль, потому что им теперь нужно в той или иной системе заниматься внесением мета-информации (кто, что, когда, какой результат)… Аджайл быстро перестаёт быть аджайлом, процесс формализуется. Со сроками становится ещё хуже, а заднее место прикрывать тестеры всё равно как-нибудь сумеют. На дэшборды никто не смотрит до следующего фэйла, а при фэйле — там ясности не добавляется.
В корне этих проблем: все эти инструменты нагружают тестеров не очень полезной и нудной деятельностью с довольно большим оверхедом.
Тех же целей (разделение ответственности и более прозрачное планирование) можно достичь с намного более меньшим оверхедом использую более простые инструменты: Excel или чеклисты в MarkDown файлах
P.S. В прошлом году, я был на StarEast conference (наверное самая большая конференция тестеров в США), и там один мужик представлял очередную подобную систему. Так он показательно начал свою презентацию с таких слов:
Если вы всё ещё используете Excel для хранения тест протоколов и тест репортов, то вы живёте в прошлом веке. Пора уже купить наш супер-современный инструмент, и наступит вам счастье.
С его слов я понял, что они (продажники таких систем) знают, что большинство тестеров сидит в Excel, и очень не хотят переходить ни на какие «современные инструменты». Потому что уже проходили.
Было бы интересно сделать опрос. Вангую, что больше половины используют Excel / Google Spreadsheet.
1. Вот как раз в Excel можно открыть файл с тысячей кэйсов и легко с ними работать, скролить через все, сделать поиск по всем и сразу увидеть. Ни одна из веб-систем и близко не приближается в плане удобства к Excel.
Посмотреть 1000 кэйсов в Excel нетрудно, а вот кликать через пагинацию в веб-приложении — боль.
Смотреть на пироги-репорты — занятие тоже довольно бессмысленное (хотя в Excel это тоже делается легко).
3. нет, такой возможности нет. Но вроде бы не особо и надо. Если что боле-менее серьёзное, то баги есть в JIRA.
1.В чём проблема с большой базой кэйсов?
Я работал в медицинской компании, там были десятки тест протоколов и тысячи репортов. Хранили в Excel, Excel хранили в Confluence — там была система документооборота заточенная под требования аудита.
Вместо Confluence можно и другие системы использовать, если там есть версионность и некоторые фишки аудита (типа NextCloud)
2. Очень редко у меня были случаи когда нужно добавлять картинки. Но и в Excel и в Google Spreadsheet картинки вставлять можно.
3. Что такое «история по прогонам»? Мы работаем в контексте версий (вот репорты для этой версии) или в контексте PR (вот репорт для этого PR).
Обычно структура такая:
— есть regression suite (протокол), который обязательно нужно прогнать перед релизом, и может быть посреди цикла, если изменения большие.
— и есть отдельные протоколы на features. Разрабатываем и тестируем feature A, то значит её протокол и создаём (обновляем) и используем.
Работаю QA 8 лет.
В разных компаниях в США.
Видел разные системы.
Мой вывод: если у вас больше 5 тест кейсов, то все эти системы добавляют слишком много оверхеда (лишней головной боли), и без них — лучше, чем с ними.
2 самых эффективных способа держать в порядке тест кейсы и репорты:
1) Excel (или Google Spreadsheets). Да, да. Кто бы что ни говорил, редактировать в Excel гораздо проще, чем во всех этим тулзах, где разные тесты и поля на разных экранах, и что-то надо делать так, а что-то по другому.
2) MD (MarkDown) файлы с тест кэйсами, которые хранятся вместе с основной репой.
Тут процесс такой:
— тест планы хранятся в репе вместе с продуктом, поэтому они всегда правильной версии
— когда нужно что-то тестировать, то репорт сохраняется:
* а) в комментариях к PR, который вы тестируете. И это очень ЛОГИЧНО: это такой ручной критерий именно этого PR. ИЛИ
* б) в JIRA таске (или какой-то другой системе, которую вы используете). Так что вы всегда можете найти этот репорт, потому что эта таска находится в правильном проекте, с правильной версией, назначенной на нужного человека и т.д… Если вы смотрите на статус спринта, то вы видите там задачу «Manual QA», вы можете её открыть, посмотреть, что уже сделано и т.д.
Я не знаю, если вопрос именно про OpenStreet,
Но для Гугло-карт есть коммерческий плагин (есть бесплатный уровень), который позволяет написать несколько строчек адресов в Google Sheets, и получить карту с этими адресами:
Разница в том, что PHP защита от переживаний о глобальном состоянии — это на уровне языка. Принципиально невозможно, чтобы один запрос (web request) повлиял на контекст другого запроса.
В PHP принципиально нет возможности написать программу, в которой переменную изменяет код в разных потоках.
Да, с глобальным переменными можно накосячить и в одном потоке.
Поэтому ваша отсылка — "в том числе и в PHP фрейморках" — некорректна: от PHP фрейморков в этом плане ничего не зависит, это свойство самого PHP.
PHP часто ругают, и даже заслуженно.
Но. PHP практически полностью избавляет программиста от забот параллельного исполнения кода. Поэтому PHP-программисты особо не парясь используют глобальные переменные. Никакой другой язык этого бы не простил.
Я имею в виду параллельные web-requests, которые приходят на сервер.
Да, ценой не очень рационального использования памяти.
Да, возможности сохранять и передавать данные между запросами довольно ограниченные.
В общем, это уже лопата, но ещё не трактор. Лопату можно доверить и зелёному подростку, а вот трактор — нет.
И сколько там солдатов из стройбатов заменяют экскаватор?
Я сначала сам приехал сюда, потом привёз маленьких детей, и им уже на месте делал тут статус PR. Так можно. Но бумажек — уйма. Консультанты берут за это 2-3 тысячи канадских долларов. Я делал сам. Первый раз — неправильно. Второй — осилил. Потратил на это реально несколько дней плотной работы, оформляя документы. В сумме наверное пару недель. Вот недавно получил PR для них.
Тут, конечно, неплохо.
Но автор явно не в теме.
Это не так. Зарплаты в Канаде значительно ниже, чем в США. Поэтому желающих уехать в США много. Но в США канадцам ехать можно только как туристам. Если на границе пограничник обнаружит ваши намерения ехать в США работать — запрет на въезд в США лет на 5-10.
Для программистов есть специальный пункт в NAFTA, что их могут пустить в США поработать год.
Но «не нужно будет получать какие-либо специальные разрешения или визы» — это вы фантазируете.
Канада большая.
Настолько большая, что в северных провинциях жить не только дешево, но государство ещё и доплачивать вам будет, если вы согласитесь там жить. Вот только желающих мало.
А вот если захотите жить немного южней, то «проще и дешевле» — это миф.
Стоимость жизни в Ванкувере уступает только стоимости жизни в Силиконовой долине. Очень дорого.
В Торонто немного дешевле, но не сильно.
В Монтреале дешево, но там не говорят по английски и зарплаты раза в два ниже чем в Ванкувере и Торонто.
Ага, вы в курсе, что нынешний премьер всё никак не может отмахаться от причастности к корупционному скандалу SNC-Lavalin? А так да — все тут белые и пушистые.
Про провинцию Квебек слышали? Они даже референдум проводили, потому что хотят быть отдельной страной.
Если вы говорите по английски и не говорите по французски, то заехав в Квебек вы быстро поймёте, что и ксенофобия и национализм здесь никуда не делись.
Я это всё не к тому, что Канада — плохая страна.
Я живу в Ванкувере, и тут неплохо.
Но рая на земле нет. Будьте реалистами.
Не ходи дети, в Африку гулять…
Кто-нибудь может по русски пересказать вот это предложение:
Специальный запрос на RDP может его сломать, но при этом RDP неуязвим. Это как?
Все остальные инструменты отвлекают очень серьёзно.
Например, у вас есть сценарий:
— открыть приложение в браузере
— залогиниться
— сделать 3-4 CRUD операции
— разлогиниться
И вам надо тестировать это в 3-4 браузерах.
Если вы это делаете в Excel — это выделать мышкой регион и нажать Ctrl-V 3-4 раза.
Если вы это делаете в любой системе — вы не можете там сделать Ctrl-V на все шаги. Вы должны каждый шаг: 1) открыть, 2) ввести результат, 3) отправить. После каждого шага надо ждать, пока веб-сервер ответит (даже если это немного — это всё равно складывается).
В результате Excel уделывает любую систему раз в 10 по времени, которое тестеры надо потратить на то, чтобы ввести результаты.
Другой вариант:
допустим у вам в тест-кейсах есть какие-то детали, связанные с окружением: может имя сервера, или ожидаемый текст сообщения в ответе и т.д.
И если это поменялось, и надо изменить больше одного тест-кэйса, то в Excel — это «Find and Replace».
А вот в «полезном инструменте» это превращается в ад, когда надо вручную открыть и исправить стопятьсот кэйсов. Или сделать экспорт в Excel, исправить там, и импортировать обратно ;-) Это если у инструмента есть вменяемый импорт-экспорт
Я нередко наблюдал такую картину:
— в компании есть тестеры, которые тем или иным образом занимаются тестирование
— возникает «проблема». Проблемы, связанных с процессом может быть две:
а) тестеры прохлопали серьёзный баг, которые выкатили в продакшен (отправили клиенту, ...) и теперь начинают разбираться — а чем там тестеры занимались, кто виноват… Ну а тестеры прикрывают себе заднее место, никто не может понять кто и что тестировал. И тогда начальство решает: поставить систему, чтобы всё было видно: кто и что тестировал, и что не тестировали.
б) каждый раз, когда готовиться релиз, тестеры заваливают сроки. От них невозможно получить надёжного ответа на вопрос: что уже сделано и сколько осталось? И тогда начальство требует, чтобы им сделали дэшборды, чтобы там это всё было видно и «прозрачно».
В обоих случаях тестеры получают головную боль, потому что им теперь нужно в той или иной системе заниматься внесением мета-информации (кто, что, когда, какой результат)… Аджайл быстро перестаёт быть аджайлом, процесс формализуется. Со сроками становится ещё хуже, а заднее место прикрывать тестеры всё равно как-нибудь сумеют. На дэшборды никто не смотрит до следующего фэйла, а при фэйле — там ясности не добавляется.
В корне этих проблем: все эти инструменты нагружают тестеров не очень полезной и нудной деятельностью с довольно большим оверхедом.
Тех же целей (разделение ответственности и более прозрачное планирование) можно достичь с намного более меньшим оверхедом использую более простые инструменты: Excel или чеклисты в MarkDown файлах
P.S. В прошлом году, я был на StarEast conference (наверное самая большая конференция тестеров в США), и там один мужик представлял очередную подобную систему. Так он показательно начал свою презентацию с таких слов:
С его слов я понял, что они (продажники таких систем) знают, что большинство тестеров сидит в Excel, и очень не хотят переходить ни на какие «современные инструменты». Потому что уже проходили.
Было бы интересно сделать опрос. Вангую, что больше половины используют Excel / Google Spreadsheet.
Посмотреть 1000 кэйсов в Excel нетрудно, а вот кликать через пагинацию в веб-приложении — боль.
Смотреть на пироги-репорты — занятие тоже довольно бессмысленное (хотя в Excel это тоже делается легко).
3. нет, такой возможности нет. Но вроде бы не особо и надо. Если что боле-менее серьёзное, то баги есть в JIRA.
Я работал в медицинской компании, там были десятки тест протоколов и тысячи репортов. Хранили в Excel, Excel хранили в Confluence — там была система документооборота заточенная под требования аудита.
Вместо Confluence можно и другие системы использовать, если там есть версионность и некоторые фишки аудита (типа NextCloud)
2. Очень редко у меня были случаи когда нужно добавлять картинки. Но и в Excel и в Google Spreadsheet картинки вставлять можно.
3. Что такое «история по прогонам»? Мы работаем в контексте версий (вот репорты для этой версии) или в контексте PR (вот репорт для этого PR).
Обычно структура такая:
— есть regression suite (протокол), который обязательно нужно прогнать перед релизом, и может быть посреди цикла, если изменения большие.
— и есть отдельные протоколы на features. Разрабатываем и тестируем feature A, то значит её протокол и создаём (обновляем) и используем.
В разных компаниях в США.
Видел разные системы.
Мой вывод: если у вас больше 5 тест кейсов, то все эти системы добавляют слишком много оверхеда (лишней головной боли), и без них — лучше, чем с ними.
2 самых эффективных способа держать в порядке тест кейсы и репорты:
1) Excel (или Google Spreadsheets). Да, да. Кто бы что ни говорил, редактировать в Excel гораздо проще, чем во всех этим тулзах, где разные тесты и поля на разных экранах, и что-то надо делать так, а что-то по другому.
2) MD (MarkDown) файлы с тест кэйсами, которые хранятся вместе с основной репой.
Тут процесс такой:
— тест планы хранятся в репе вместе с продуктом, поэтому они всегда правильной версии
— когда нужно что-то тестировать, то репорт сохраняется:
* а) в комментариях к PR, который вы тестируете. И это очень ЛОГИЧНО: это такой ручной критерий именно этого PR. ИЛИ
* б) в JIRA таске (или какой-то другой системе, которую вы используете). Так что вы всегда можете найти этот репорт, потому что эта таска находится в правильном проекте, с правильной версией, назначенной на нужного человека и т.д… Если вы смотрите на статус спринта, то вы видите там задачу «Manual QA», вы можете её открыть, посмотреть, что уже сделано и т.д.
Ага
А потом выкачивать их оттуда сутками, если надо восстановиться
Ну это верно только если у каждого человека уникальный сет (set) демографических атрибутов (битов). Что конечно же не так.
Но для Гугло-карт есть коммерческий плагин (есть бесплатный уровень), который позволяет написать несколько строчек адресов в Google Sheets, и получить карту с этими адресами:
www.thexs.ca/xsmapping
gsuite.google.com/marketplace/app/mapping_sheets/736233853391
Но похоже там переход на 12.0 связан не столько с тем, что они добавили, а с тем, что убрали: у них 17 deprecations (Устаревшие фичи) в этой версии.
Раньше был такой сервис Page2Rss. Потом закрылся…
В отличии от США, где аэропорты расположены в городах. То есть там проще «заховаться» в место подходящее для атаки.
Разница в том, что PHP защита от переживаний о глобальном состоянии — это на уровне языка. Принципиально невозможно, чтобы один запрос (web request) повлиял на контекст другого запроса.
В PHP принципиально нет возможности написать программу, в которой переменную изменяет код в разных потоках.
Да, с глобальным переменными можно накосячить и в одном потоке.
Поэтому ваша отсылка — "в том числе и в PHP фрейморках" — некорректна: от PHP фрейморков в этом плане ничего не зависит, это свойство самого PHP.
Но. PHP практически полностью избавляет программиста от забот параллельного исполнения кода. Поэтому PHP-программисты особо не парясь используют глобальные переменные. Никакой другой язык этого бы не простил.
Я имею в виду параллельные web-requests, которые приходят на сервер.
Да, ценой не очень рационального использования памяти.
Да, возможности сохранять и передавать данные между запросами довольно ограниченные.
В общем, это уже лопата, но ещё не трактор. Лопату можно доверить и зелёному подростку, а вот трактор — нет.
И сколько там солдатов из стройбатов заменяют экскаватор?
Ну конечно, какая же современная функциональность без философии?
Привет маркетологам.
Вот только пользователям от аналитики ни холодно, не жарко. И логгирование до лампочки. Да и других сервисов под это дело полно.
А вот Маркет и Push Notifications — для пользователя весьма чувствительно.
Про admob тоже верно отмечено. Чтобы разработчики были заинтересованы — наверное это тоже один из критических сёрвисов с их точки зрения.