завести тикет в 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 приходится «отвоевывать должный авторитет» и «добиваться от разработчиков продуктивного взаимодействия»… надо будет попробовать написать мотивационно-руководствующую статью о своем опыте и взгляде на эту тему :)
1) Есть понимание(ИМХО) что юниты пишут разрабы, а тестер, если в силах — помогает, дописывает, подсказывает. Но как подойти к тому, что бы их разработчики хотя бы начали писать?
В случае, когда на проекте их нет и разработчики не горят желанием их писать, а предложения от QA слышать не хотят, начинать работу нужно с менеджеров. Если на проекте введены позиции Quality Assuarance, это априори подразумевает организационную работу от этих людей по обеспечению высокого качества продукта. QA следует пообщаться с менеджерами:
— объяснить важность и нужность таких тестов (я не могу представить себе менеджера, который бы не согласился с этим)
— предложить стратегию по внедрению
(Варианты: 1. PR без автотестов не может получить апрув; 2. PR должен иметь хотя бы один апрув от QA(а они смотрят автотесты) )
— проявить настойчивость
А уж когда менеджеры официально поддержали и огласили, что «все, ребята, теперь работаем именно так», то тут уже разработчикам ничего не остается, как делать то, что нужно делать. Но и с ними мотивационную работу провести стоит ;) в идеале, у них у самих должен быть интерес делать качественный продукт. Я, наоборот, знала одного разработчика, который считал, что он настолько самодостаточный и классный, что ему подстраховка от QA не нужна. «Да, если вы завтра все исчезнете, я и не замечу, — говорил он, полушутя, — я свой функционал на 90 процентов покрываю тестами». :) А мне такая мотивация даже нравится.
И как организовывать эти тесты, если продукт постоянно меняется(как пример — банковское ПО)?
У нас тоже постоянно что-то меняется, модифицируется. Но каждый разработчик, работая над куском функционала, неизменно чинит и поддерживает старые тесты, если они с новым кодом не работают. Его работа над текущим функционалом не может быть закончена, если есть сломанные тесты, просто потому что тесты автоматически крутятся на CI, которая интегрирована в github. И пока все его тесты не будут пройдены, github не даст ему смержить его обновление в master. В его PR будет светится сообщение: «Some checks were not successful. All check runs on this pull request must run successfully to enable automatic merging.» В этом и прелесть тестов в коде продукта, их постоянно поддерживает вся команда — по-другому нельзя.
Интересная статья, классная подача. Спасибо!
завести тикет в 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 приходится «отвоевывать должный авторитет» и «добиваться от разработчиков продуктивного взаимодействия»… надо будет попробовать написать мотивационно-руководствующую статью о своем опыте и взгляде на эту тему :)
В случае, когда на проекте их нет и разработчики не горят желанием их писать, а предложения от QA слышать не хотят, начинать работу нужно с менеджеров. Если на проекте введены позиции Quality Assuarance, это априори подразумевает организационную работу от этих людей по обеспечению высокого качества продукта. QA следует пообщаться с менеджерами:
— объяснить важность и нужность таких тестов (я не могу представить себе менеджера, который бы не согласился с этим)
— предложить стратегию по внедрению
(Варианты: 1. PR без автотестов не может получить апрув; 2. PR должен иметь хотя бы один апрув от QA(а они смотрят автотесты) )
— проявить настойчивость
А уж когда менеджеры официально поддержали и огласили, что «все, ребята, теперь работаем именно так», то тут уже разработчикам ничего не остается, как делать то, что нужно делать. Но и с ними мотивационную работу провести стоит ;) в идеале, у них у самих должен быть интерес делать качественный продукт. Я, наоборот, знала одного разработчика, который считал, что он настолько самодостаточный и классный, что ему подстраховка от QA не нужна. «Да, если вы завтра все исчезнете, я и не замечу, — говорил он, полушутя, — я свой функционал на 90 процентов покрываю тестами». :) А мне такая мотивация даже нравится.
У нас тоже постоянно что-то меняется, модифицируется. Но каждый разработчик, работая над куском функционала, неизменно чинит и поддерживает старые тесты, если они с новым кодом не работают. Его работа над текущим функционалом не может быть закончена, если есть сломанные тесты, просто потому что тесты автоматически крутятся на CI, которая интегрирована в github. И пока все его тесты не будут пройдены, github не даст ему смержить его обновление в master. В его PR будет светится сообщение: «Some checks were not successful. All check runs on this pull request must run successfully to enable automatic merging.» В этом и прелесть тестов в коде продукта, их постоянно поддерживает вся команда — по-другому нельзя.
Мое видение таково. Надеюсь, оно вам поможет.