Комментарии 9
Отличная статья, несколько ситуаций видел вживую, и одну даже практикую (со строгими правилами для тестировщиков), хотя моя схема не такая жесткая. Правила и регламенты нужны для упрощения взаимопонимания между тестировщиками т.к. часто команды распределенные и у каждого тестировщика может быть свое видение насчет написания тестовой документации, ее детализации и т.д.
Не совсем с Вами согласен по поводу «правил и регламентов».
Безусловно, у каждого тестировщика свое видение насчет документации, подходов тестирования и т.д.
Можно жить и работать вовсе без правил и регламентов.
Важно чтобы QA инженеры понимали друг друга и у них была она цель.
Более того, чтоб разработчики понимали, что конкретно тестируют и как.
Безусловно, у каждого тестировщика свое видение насчет документации, подходов тестирования и т.д.
Можно жить и работать вовсе без правил и регламентов.
Важно чтобы QA инженеры понимали друг друга и у них была она цель.
Более того, чтоб разработчики понимали, что конкретно тестируют и как.
«Постарайтесь записывать интересные кейсы в вики» — тоже регламент, просто совсем не строгий.
Не обязательно иметь их в каком-то официально записанном виде — главное чтобы все участвующие в процессе были в курсе.
А семинары, лекции и прочие беседы позволят даже устные договорённости доносить до всех заинтересованных :)
Не обязательно иметь их в каком-то официально записанном виде — главное чтобы все участвующие в процессе были в курсе.
А семинары, лекции и прочие беседы позволят даже устные договорённости доносить до всех заинтересованных :)
Жить без правил и регламентов можно, согласен, но для этого нужно поддерживать достаточно сильную сплоченность команды или хотя бы иметь возможность собрать всю команду из разработчиков и тестировщиков в одной комнате/опенспейсе. В таком случае возможность налаживания понимания между тестировщиками команды и тем более разработчиками реальна. В распределенных командах наладить такую структуру не так просто т.к. даже не всегда бывает возможность нормально общаться с командой (не учитывая багтрекеры и тасктрекеры).
Если говоря кратко — при наличии живого общения можно обходиться минимумом правил, но все же базовые правила нужны. При отсутствии возможности подобного «живого» общения приходится вводить большее количество правил и регламентов для поддержания четкой инфраструктуры в части рабочих процессов, например в части написания и вида тест-кейсов.
Если говоря кратко — при наличии живого общения можно обходиться минимумом правил, но все же базовые правила нужны. При отсутствии возможности подобного «живого» общения приходится вводить большее количество правил и регламентов для поддержания четкой инфраструктуры в части рабочих процессов, например в части написания и вида тест-кейсов.
>Урок: гораздо лучше, когда с автотестами работают все представители QA-отдела. Пусть не все из них будут в состоянии написать тест с нуля, но сделать так, чтобы каждый инженер мог оценить состояние тестов в данный момент, понять причину их провалов, поправить простенькую ошибку или покрыть тестом новый несложный кейс, стоит.
Если ребята не смогут написать тест с нуля, как же они смогут покрыть тестом какой-то кейз? :)
Если ребята не смогут написать тест с нуля, как же они смогут покрыть тестом какой-то кейз? :)
Пример: мы для наших тестов пишем библиотеку, построенную вокруг слегка изменённого принципа PageObject — поэтому если в новой задачке появляется какой-то простой функционал на уже существующей странице (или на похожей странице), то инженеру достаточно написать новый метод в тесте этой страницы вида (это не наш код, это пример)
Научить ребят базовому синтаксису PHP и поиску существующих методов — не такая сложная задача.
Понятно что в этом случае новые кнопки, новые странички иболее сложная логика могут стать для инженера сложностью — но тут либо они могут уже сами начинать совершенствоваться, либо (если сроки поджимают, например) отдать написание этого теста более опытным специалистам.
$this->openFunnyPage();
FunnyPage::pressButtonWithWord("Ура!");
FunnyPage::clickOptionInCloud(2);
FunnyPage::checkUserIsHappy()
Научить ребят базовому синтаксису PHP и поиску существующих методов — не такая сложная задача.
Понятно что в этом случае новые кнопки, новые странички иболее сложная логика могут стать для инженера сложностью — но тут либо они могут уже сами начинать совершенствоваться, либо (если сроки поджимают, например) отдать написание этого теста более опытным специалистам.
Я понял, спасибо. Изначально я решил, что раз говорилось о высоком покрытии изначально, то ребятам из ручного тестировния приходится писать тесты именно на новый функционал, чего без знания языка программирования и основ selenium сделать довольно сложно. Но Вы, видимо, говорите о написании сценариев, составленных из возможностей уже существующей библиотеки. Значит либо это тест на пробел в покрытии старого функционала (например упущенного бага), либо BDD. Верно?
Чаще всего — да. Но помимо этого нередко бывают новые фичи, которые можно покрыть используя исключительно имеющиеся методы в API — у нас достаточно типизированная вёрстка (хоть и не всегда, конечно), чтоб можно было использовать общие методы вида «Нажать закрывающую кнопку в облаке» или «Нажать кнопку 'Продолжить' в диалоге». Часто этого бывает достаточно :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Учимся на ошибках в организации контроля качества