у нас, у приезжих, есть спасительная Non-Habitual Tax Residents (NHR), благодаря ей в течение 10 лет подоходный налог не превышает 20%, а так, да, до 48% доходит подоходный налог по прогрессивной шкале
ежупонятный случай, скорее всего) знаю, что у одной семьи есть околоайтишный бизнес, который они релоцировали в Португалию, легче налоговое бремя. Другая семья - творческих профессий, типа актеры-режиссеры, не уверена как точно зарабатывают)
Спасибо за статью, очень откликаются все сложности, хоть я и переехала в Португалию. И, конечно, знать это все - очень помогает при релокации. В португальском классе сына двое детей из Германии, их семьи переехали сюда пару лет назад. При общении отметили, что в Португалии им легче жить финансово.
завести тикет в jira на доработку текста тикета в jira, хаха)) программисты и ленятся, поэтому этим занимаюсь я, что тоже весьма неплохо ведь я часть технической команды.
Google SETs are test developers, responsible for assisting SWEs with the unit test portion of their work and also in writing larger test frameworks to assist SWEs in writing small and medium tests to assess broader quality concerns.
примечание: Software Engineers in Test == SET Software Engineer == SWE
Считаю, это хорошим подкреплением того, что в своей статье я достаточно верно рассмотрела вопрос Кто такой Software Engineer in Test. Да, рассмотрение поверхностное, и в разных компаниях допускаются отклонения, поэтому вариации нужно уже смотреть на месте работы.
Без сомнения бизнесу важнее результат, но быть грамотным - это приятно и красиво; этакий уровень комфортной работы, когда ты с командой общаешься на одном языке и понимаешь друг друга с полуслова :)
Да, тоже встречала коллег, путающихся в терминах, чаще всего, это те, кто не следит за «актуальной IT теорией». Нам всем, наверно, нужно учиться в режиме нон стоп, чтоб успевать за нашим миром, не у всех получается))
Во-первых, я смотрю только на англоязычные определения, для меня это язык оригинала. То, что на русском, к сожалению может содержать вольности перевода и терять свою точность. Отсюда ISTQB чаще всего рекомендуют сдавать на английском.
Во-вторых, смотрите, в основе всех определений лежит test. И согласно глоссарию test = test case. Пусть мы тестируем функционал А.
Test case для него — это заполненная табличка, где колонки называются input values, preconditions, expected results, postconditions.
Дальше нужно знать, что с этой таблицей делать, чтобы любой мог взять test case и отметить его как passed или failed. Тут на помощь придет test procedure = test script и он будет выглядеть условно так:
step 1: возьми input data
step 2: встать в окошко
step 3: нажми кнопку
step 4: запомни результат
step 5: сравни с expected data
Этим любым может быть фреймворк для тестирования, что на практике желательно (тогда скрипт — это программный код), а может быть ручной тестировщик (тогда скрипт — руководство к действию).
Все упомянутое, вместе с описанием функционала, который тестируете будет большой документ test specification.
У меня получилось, test=test case -> test procedure=test script -> test specification
Не знаю, ответила ли я на ваш вопрос, но возможно, дала немного пищи для размышления. Удачи с ISTQB, образование — дело хорошее!
Спасибо за мысли на тему :) На сколько я знаю, Software Engineer in Test — это формулировка типичная для google. Я работаю удаленно в распределенной команде, и весь наш менеджмент — это англичане, возможно, им привычнее такой вариант. Спасибо за отсылку на hh и полезный комментарии про Software Development Engineer in Test. Думаю, это одно и то же.
Вы правы, я не осуществляла отдельную проверку орфографии. Текстовый редактор Хабра не предоставляет такой возможности, а услугами отдельных сервисов я не стала пользоваться.
В этом тексте примерно 2280 слов или 12900 символов без пробелов, после вашего комментария я исправила 7 орфографических ошибок и 1 пунктуационную.
На оставшиеся, не видные моему замыленному глазу, вы всегда можете воспользоваться возможностью хабра:
Если нашли опечатку в посте, выделите ее и нажмите Ctrl+Enter, чтобы сообщить автору.
Спасибо, что обратили мое внимание на опечатки. Впредь буду внимательнее.
Если ключевое здесь, что «И времени на освоение новой технологии нет» то я бы перешла на формат «требовать автотестов от разработчиков». Согласна, что для того, чтобы самому писать на новом языке программирования нужно подучиться. Тем не менее, я верю, что тот, кто хоть раз сам писал автотесты способен «прочитать» какие кейсы разработчик сейчас покрыл, а какие упустил, «язык автотестов» на многих языках программирования схож. Если прочитать не удается, я бы настаивала на включение в описание PR списка разработанных автотестов и ориентировалась на него. Я считаю, это полное право и обязанность команды QA максимально быть осведомленным о покрытии продукта автотестами, иначе вся идея Quality assurance теряется…
Если мы рассматриваем ситуацию жесткой ограниченности во времени всей команды, в том числе и девелопера, то я бы в ходе ревью настаивала на покрытии интеграционными автотестами критически/стратегически важных сценариев. А на все остальные сценарии документировала отдельные таски, чтобы сделать их позже. В любом проекте бывают спокойные периоды, когда нет дедлайнов — тогда и стоит акцентировать внимание Product Manager/Team Lead/Scrum Master-ов на том, чтобы включать в работу эти таски: посложнее — пусть делают разработчики, на самых простых — учиться самой.
Читая вопросы, которые поступают (не конкретно ваш), все чаще наталкиваюсь на мысль, что, как и 10 лет назад, так и сейчас во многих проектах остается проблема, что QA приходится «отвоевывать должный авторитет» и «добиваться от разработчиков продуктивного взаимодействия»… надо будет попробовать написать мотивационно-руководствующую статью о своем опыте и взгляде на эту тему :)
у нас, у приезжих, есть спасительная Non-Habitual Tax Residents (NHR), благодаря ей в течение 10 лет подоходный налог не превышает 20%, а так, да, до 48% доходит подоходный налог по прогрессивной шкале
и язык надо учить португальский :D моя боооль
Но в Германии тоже придется немецкий осваивать, конечно
ежупонятный случай, скорее всего) знаю, что у одной семьи есть околоайтишный бизнес, который они релоцировали в Португалию, легче налоговое бремя. Другая семья - творческих профессий, типа актеры-режиссеры, не уверена как точно зарабатывают)
Спасибо за статью, очень откликаются все сложности, хоть я и переехала в Португалию. И, конечно, знать это все - очень помогает при релокации.
В португальском классе сына двое детей из Германии, их семьи переехали сюда пару лет назад. При общении отметили, что в Португалии им легче жить финансово.
Интересная статья, классная подача. Спасибо!
завести тикет в jira на доработку текста тикета в jira, хаха)) программисты и ленятся, поэтому этим занимаюсь я, что тоже весьма неплохо ведь я часть технической команды.
спасибо за вдумчивое прочтение, наверное, термин negative testing вместо invalid testing был бы привычнее, однако, это синонимы.
negative testing
Testing a component or system in a way for which it was not intended to be used.
Synonyms: dirty testing, invalid testing
Источник https://glossary.istqb.org/en/search/invalid
спасибо за мысль; ваш опыт работы с интуицией интересен ) здесь я как раз предлагаю способы развить аналитическое мышление, интуиция станет бонусом.
Очень классное оформление статьи! Спасибо за юмор)))
По-моему, супер круто! Если бы я была начинающим, то точно хотела бы стать частью такого сообщества. А звучит-то как душевно «Хомячки» ))
И вам @lxsmkv и @conopus спасибо за дискуссию! Для меня важный вывод - в будущем подкреплять подобный материал ссылками на первоисточники.
Я вернулась сейчас к уважаемой многими книге-бестселлеру How Google Tests Software: Whittaker, James, Arbon, Jason и глава 2 так и называется Software Engineer in Test, вот дословное определение на странице 16:
Google SETs are test developers, responsible for assisting SWEs with the unit test portion of their work and also in writing larger test frameworks to assist SWEs in writing small and medium tests to assess broader quality concerns.
примечание:
Software Engineers in Test == SET
Software Engineer == SWE
И вот, например, GitLab говорит. что у них тоже есть Software Engineer in Test и список обязанностей впечатляет
Считаю, это хорошим подкреплением того, что в своей статье я достаточно верно рассмотрела вопрос Кто такой Software Engineer in Test. Да, рассмотрение поверхностное, и в разных компаниях допускаются отклонения, поэтому вариации нужно уже смотреть на месте работы.
Интересно. Это интуитивное понимание или вы встречали такие определения в какой-то литературе?
Без сомнения бизнесу важнее результат, но быть грамотным - это приятно и красиво; этакий уровень комфортной работы, когда ты с командой общаешься на одном языке и понимаешь друг друга с полуслова :)
Привет! Спасибо за поддержку! Наконец-то время и желание писать совпали))
Во-первых, я смотрю только на англоязычные определения, для меня это язык оригинала. То, что на русском, к сожалению может содержать вольности перевода и терять свою точность. Отсюда ISTQB чаще всего рекомендуют сдавать на английском.
Во-вторых, смотрите, в основе всех определений лежит test. И согласно глоссарию test = test case. Пусть мы тестируем функционал А.
Test case для него — это заполненная табличка, где колонки называются input values, preconditions, expected results, postconditions.
Дальше нужно знать, что с этой таблицей делать, чтобы любой мог взять test case и отметить его как passed или failed. Тут на помощь придет test procedure = test script и он будет выглядеть условно так:
step 1: возьми input data
step 2: встать в окошко
step 3: нажми кнопку
step 4: запомни результат
step 5: сравни с expected data
Этим любым может быть фреймворк для тестирования, что на практике желательно (тогда скрипт — это программный код), а может быть ручной тестировщик (тогда скрипт — руководство к действию).
Все упомянутое, вместе с описанием функционала, который тестируете будет большой документ test specification.
У меня получилось, test=test case -> test procedure=test script -> test specification
Не знаю, ответила ли я на ваш вопрос, но возможно, дала немного пищи для размышления. Удачи с ISTQB, образование — дело хорошее!
В этом тексте примерно 2280 слов или 12900 символов без пробелов, после вашего комментария я исправила 7 орфографических ошибок и 1 пунктуационную.
На оставшиеся, не видные моему замыленному глазу, вы всегда можете воспользоваться возможностью хабра:
Спасибо, что обратили мое внимание на опечатки. Впредь буду внимательнее.
Если ключевое здесь, что «И времени на освоение новой технологии нет» то я бы перешла на формат «требовать автотестов от разработчиков». Согласна, что для того, чтобы самому писать на новом языке программирования нужно подучиться. Тем не менее, я верю, что тот, кто хоть раз сам писал автотесты способен «прочитать» какие кейсы разработчик сейчас покрыл, а какие упустил, «язык автотестов» на многих языках программирования схож. Если прочитать не удается, я бы настаивала на включение в описание PR списка разработанных автотестов и ориентировалась на него. Я считаю, это полное право и обязанность команды QA максимально быть осведомленным о покрытии продукта автотестами, иначе вся идея Quality assurance теряется…
Если мы рассматриваем ситуацию жесткой ограниченности во времени всей команды, в том числе и девелопера, то я бы в ходе ревью настаивала на покрытии интеграционными автотестами критически/стратегически важных сценариев. А на все остальные сценарии документировала отдельные таски, чтобы сделать их позже. В любом проекте бывают спокойные периоды, когда нет дедлайнов — тогда и стоит акцентировать внимание Product Manager/Team Lead/Scrum Master-ов на том, чтобы включать в работу эти таски: посложнее — пусть делают разработчики, на самых простых — учиться самой.
Читая вопросы, которые поступают (не конкретно ваш), все чаще наталкиваюсь на мысль, что, как и 10 лет назад, так и сейчас во многих проектах остается проблема, что QA приходится «отвоевывать должный авторитет» и «добиваться от разработчиков продуктивного взаимодействия»… надо будет попробовать написать мотивационно-руководствующую статью о своем опыте и взгляде на эту тему :)