Comments 45
Сам перечитал сейчас… сумбурно немного вышло. надо как-то поаккуратнее мысли-то излагать
может однозначно сказать, хороший он или плохой. Зеленый — хороший, красный — плохой.
мне кажется так реагировать на билд не стоит. Менеджер должен быть уверен, что команда написала все тесты, что все они адекватные, т.е. тестируют именно то, что надо. Короче зеленый цвет не значит что с проектом все хорошо
Если зеленый цвет не значит, что с проектом все хорошо, то зачем применять Continuous Integration?.. Мне бы как раз очень хотелось обратного, чтобы зеленый билд означал работающее приложение. Часто этого сложно добиться, я понимаю, что все тесты не напишешь, да и от ручной проверки мы все равно не избавимся, хотя бы просто запустить приложение. Чем больше автоматизации, чем больше система проверит сама, тем выше шансы на то, что продукт в рабочем состоянии. Без панацеи, естественно.
Сори, ответил в основном потоке. Тут ответ
«Всё зелёное — значит всё работает» — это типичная ошибка новичка.
Если красное — это значит что не работает. Если зелёное — ничего не означает. Зелёное — это «qa не может дать гарантию, что билд плохой и не работает». Как-то так.
Если красное — это значит что не работает. Если зелёное — ничего не означает. Зелёное — это «qa не может дать гарантию, что билд плохой и не работает». Как-то так.
Так может тогда и не надо CI, если он врет, говоря, что с билдом все хорошо. Или мы не можем это сказать наверняка? Continuous Integration Шредингера прям.
Он может сказать, что всё плохо. Его «хорошо» означает «я не нашел плохого, но может плохо искал».
Как раз об этом я и поднимал тему — идет поиск своих объяснений, статусов а-ля «зеленый, но с оговорками»… и от этого-то и хочется двигаться к позиции «зеленый-хороший, красный-плохой».
Ошибка новичка, говорите… о нет, ни в коем разе. Из-за того, что мы сами опускаем руки при автоматизации, оставляя огромную кипу ручной работы, мы и приходим к тому, что зеленый — не значит, что все работает. И именно это придется изменить в мозгу, чтобы начать ставить CI на рельсы у себя на работе.
Ошибка новичка, говорите… о нет, ни в коем разе. Из-за того, что мы сами опускаем руки при автоматизации, оставляя огромную кипу ручной работы, мы и приходим к тому, что зеленый — не значит, что все работает. И именно это придется изменить в мозгу, чтобы начать ставить CI на рельсы у себя на работе.
Как по мне, то CI — это не серебряная пуля, которая решит все проблемы. Это инструмент, облегчающий работу прежде всего тестировщикам (даже если эта роль явно не выделена), но не заменяющая их. Зеленый означает — нет предусмотренных тестами проблем. Но это не означает, что можно не глядя выкатывать на продакшен. Только в крайнем случае (фикс критического бага, например) и это рисковое решение.
Я понимаю Ваше стремление и я сам хотел бы этого, но в реальной жизни это просто не реально. Тут проблема не в том, что CI не нужен и не в том, что команда херовая, просто часто бывает такое, что человек написал кусок кода, а тесты к нему — нет. И проблема не в том, что разработчик раздолбай и не в том, что тимлид виновен, просто проблему надо было решить прямо сейчас и выкатить ее на прод в течении 20 минут. Может это спицифика моей работы, но такое бывает и довольно часто и в данном случае я не могу пойти к клиенту и сказать, что блид зеленый — все ОК. И тут в любом случае будут ситуации типа:
В общем что я хочу сказать: CI не панацея и зеленый билд не значит что все идеально. Надо знать контекст последних изменений и исходя из этого говорить билд хороший или нет
«Ты последний билд не бери, в нем вот не работает это»
В общем что я хочу сказать: CI не панацея и зеленый билд не значит что все идеально. Надо знать контекст последних изменений и исходя из этого говорить билд хороший или нет
А вы думаете я все это не в реальной жизни применяю? в самой что ни на есть реальной. С одной командой получилось быстрее, с другой помедленнее идет, но идет.
А в ситуациях, когда надо выкатить в течение 20 минут фикс на продакшен, мне кажется, еще страшнее делать это, не написав тест.
А в ситуациях, когда надо выкатить в течение 20 минут фикс на продакшен, мне кажется, еще страшнее делать это, не написав тест.
Я понимаю что это все с реальной жизни и согласен, это страшно :) Но это иногда надо. Часто бывает такое, что надо сделать прям сейчас, а тесты — потом и хорошо когда изменения только в интерфейсе и тесты только для selenium.
Я думаю что у нас просто разная специфика работы. Мы делаем релизы 10 раз за день (Continuous Deployment, хорошо звучит, да? :) ) И здесь проблема в том, что часто бывает ситуация, когда за 20 минут до совещания/презентации инвесторам надо добавить страницу, поменять тексты, сделать так, что бы инвайты работали по другой схеме. И тут я могу сколько угодно рассказывать что это хреново, но это просто надо сделать и тесты никто писать не будет и билд будет зеленый.
Снова я все веду к тому, что зеленый билд != хороший код/билд. Надо знать контекст.
Я думаю что у нас просто разная специфика работы. Мы делаем релизы 10 раз за день (Continuous Deployment, хорошо звучит, да? :) ) И здесь проблема в том, что часто бывает ситуация, когда за 20 минут до совещания/презентации инвесторам надо добавить страницу, поменять тексты, сделать так, что бы инвайты работали по другой схеме. И тут я могу сколько угодно рассказывать что это хреново, но это просто надо сделать и тесты никто писать не будет и билд будет зеленый.
Снова я все веду к тому, что зеленый билд != хороший код/билд. Надо знать контекст.
Сколько времени занимает сборка приложения? Хорошо, если это просто веб-странички и изменение действительно только во фронт-энде. Но серверный код выкладывать вот так, без всякой проверки? Риск, конечно, благороден :) Перед встречей с инвестором сделать что-то, не проверив… нет, я тут лучше рисковать не буду, ибо обернуться это может неработающим приложением.
По поводу специфики, она вроде всегда и есть, а вроде и нет. Мы деплоили и полностью клиентские системы, и веб, и SaaS с несколькими тысячами серверов, и базы данных, и мобильные приложения. Разница в деталях, несомненно, но суть остается одной — собери приложение не сам, а доверь компьютерам
По поводу специфики, она вроде всегда и есть, а вроде и нет. Мы деплоили и полностью клиентские системы, и веб, и SaaS с несколькими тысячами серверов, и базы данных, и мобильные приложения. Разница в деталях, несомненно, но суть остается одной — собери приложение не сам, а доверь компьютерам
Речь не идет о том, чтобы деплоить руками по SSH. Разве что в самых простых системах это бывает возможно. Речь о том, чтобы поставить какой-то функционал, который при этом не покрыт тестами. При этом, конечно же, поставить его через стандартные кнопки build -> deploy to production (у каждого по-своему, но суть та же).
Если грубо посчитать, то на тесты у нас уходит примерно ~ +50% времени к фиче. И это при том, что сами сценарии в стиле новомодного BDD пишут для нас QA еще до начала работы над функционалом. Так вот, очень часто бывает, что какой-то функционал нужно поставить в этот релиз позарез. Ну вот нужно бизнесу и все. Ты же не скажешь — не, ребята, нам нужно написать тесты, поэтому все будет только через неделю. Вот и получается, что поставляется через 3 дня функционал без тестов (проверенный вручную), а потом через еще несколько дней приезжают тесты к нему.
Если грубо посчитать, то на тесты у нас уходит примерно ~ +50% времени к фиче. И это при том, что сами сценарии в стиле новомодного BDD пишут для нас QA еще до начала работы над функционалом. Так вот, очень часто бывает, что какой-то функционал нужно поставить в этот релиз позарез. Ну вот нужно бизнесу и все. Ты же не скажешь — не, ребята, нам нужно написать тесты, поэтому все будет только через неделю. Вот и получается, что поставляется через 3 дня функционал без тестов (проверенный вручную), а потом через еще несколько дней приезжают тесты к нему.
У вас проблема с тем, кто вам эти задания «сделать за 20 минут» выкатывает. Он не умеет планировать задачи и распределять на них ресурсы.
Плохие тесты лучше, чем никакие
Неправда. Плохие тесты будут тянуть вас в пучину красных билдов, километровых фикстур и правки 60% тестов при изменении класса кнопки сабмита. А потом вся команда включая топ-менеджемент будет говорить, что тесты не нужны и даже вредны.
проектах к кучей легаси-кода
Бывают юниттесты, покрытие которыми легаси-кода равноценно самоубийству. Но покрытие юниттестами готового кода вообще сомнительное занятие. А бывают функциональные, или как еще их называют приемочные, или BDD, или specification by example — каждый называет на свой лад, придумывают все новые и новые модные названия — но суть не меняется. Так вот в них разницы уже между легаси-кодом и супер-пупер-навороченным ООП чудом техники, построенным по принципам SOLID практически нету. Так вот именно эти вот приемочные тесты и должны быть показателем того, что продукт готов к деплою.
Очень часто эти типы тестов путают и называют их просто — тесты. А потом пишут на PHPUnit/JUnit/NUnit (нужное подчеркнуть) юниттесты на класс UserPasswordValidator рядом с тестами RegistrationPage.
Мне все же верится, что даже плохой тест повышает уверенность при разработке. Для команды, которая тестов вообще не писала и только начинает, это понять особенно важно, потому что первая причина, по которой они отказываются — как раз то, что вы назвали: большая стоимость поддержки, длинные, медленные и т.д… Чтобы начать, им придется писать плохие тесты по началу. Через это просто придется пройти
Плохой тест может обмануть и обманет в один момент. Единственный момент когда я лично принимаю плохие тесты — это для легаси кода и на момент миграции этого кода а новую систему. Я обоими руками за если разработчик сначала пишет тест на старый код для проверки работы новго кода. Но этот тест не должен попасть в svn/git/etc. Это личный тест разработчика.
Любой тест может обмануть. И хороший, и плохой. Написать хороший — искусство. Написать плохой — необходимость, чтобы научиться писать хорошие. Пусть он ассертит поведение, пусть он проходит, когда на компьютер не дышишь и не запускаешь посторонних программ, но он уже будет работать быстрее, чем проверить это руками
Вот тут наверное у нас и разница во взглядах. Я не думаю, что плохой тест, который работает только в идеальных условиях — это хорошо. Я не верю этому тесту и в любом случае потребую проверить его руками, поэтому я не вижу смысла в написании такого теста.
А для того что бы научиться писать хорошие тесты, конечно их надо писать, но я на 100% уверен, что в команде должен быть хотя бы 1 разработчик, который умеет писать тесты, иначе пройдет очень много времени прежде чем разрабы начнут писать реально хорошие тесты.
А для того что бы научиться писать хорошие тесты, конечно их надо писать, но я на 100% уверен, что в команде должен быть хотя бы 1 разработчик, который умеет писать тесты, иначе пройдет очень много времени прежде чем разрабы начнут писать реально хорошие тесты.
лучше тогда коучей нанять, чтобы научили
Коучи это 1-2 дня. Они просто не смогут научить. Я не верю, что за 1-2 дня можно научить разраба, даже толкового, хорошо писать тесты.
не-не. на 1-2 дня — это тренинг. А коучей профессиональных нанять, это людей, которые месяц (может больше) в проекте буду работать, садясь в пару
Ну это хороший вариант, только я такого не встречал. Вот правда, я не работал в команде где нанимали бы коучей на 1-2 месяца. Может мне не поевезло. Правда даже сейчас компания где я работаю просто не сможет позволить себе нанять коучей на 1-2 месяца и в такой ситуации приходится выкручиваться.
Я ведь не говорю что статья плохая. Она полезная, просто часто бывают такие ситуации когда нельзя четко сказать, что зеленый билд — хорошо, красный — плохо и это надо понимать и всегда думать головой.
Я ведь не говорю что статья плохая. Она полезная, просто часто бывают такие ситуации когда нельзя четко сказать, что зеленый билд — хорошо, красный — плохо и это надо понимать и всегда думать головой.
Смысл проверять одно и то же руками и автотестом? Никто не утверждает, что тесты панацея и гарантирует работу приложения. но если что-то можно проверит тестом, то зачем это проверять руками? Не говоря о том, что автотесты, особенно интегрированные с CI, уменьшают влияние человеческого фактора. Билд-система и тестовый фреймворк не понадеются на авось, не забудут сегодня опять проверить функциональность, которую тестировали вчера и вроде не изменяли, и т. п. Гарантий безошибочности они не дают, но дают гарантию, что однажды зафиксированное поведение незаметно не изменится.
«По ночам компьютеры собираются вместе и смеются над людьми, если те делают работу, которую могли бы делать компьютеры»
Забрал себе!
По поводу «зеленый билд — хорошо, красный — плохо» — не хватает уточнения: в рамках написанных тестов/в рамках поставленной задачи.
Вот пример специально из ручного тестирования, несколько преувеличенный, но, надеюсь, моя мысль будет понятна. Возьмем две проблемы в приложении, которые мы регрессим:
1. приложение падает при старте (скажем, на определенном железе/системе)
2. в одном из основных диалогов приложения расстояния между тремя основными кнопками визуально неодинаковые, разница — 2-3 пикселя
Теперь зададим вопросы по обеим проблемам: проблема серьезная? Отсутствие этой проблемы в билде сделает его «более зеленым»? Присутствие — сделает «более красным»?
Чаще ответ будет: №1 — серьезная, №2 — косметика, можно пропустить. Однако зависит от условий: может система/железо, на которых возникает проблема №1, вовсе не является target системой для приложения, значит эта проблема не должна влиять на принятие решения go/not go. А вторая проблема — иниджевая, заказчик, для которого пишем приложение, уже неоднократно тыкал нас носом в аналогичные проблемы в других местах приложения и использует как аргумент, что мы не в состоянии нормально работать. По-прежнему считаем, что с такой проблемой можно отдавать билд заказчику?
Вот пример специально из ручного тестирования, несколько преувеличенный, но, надеюсь, моя мысль будет понятна. Возьмем две проблемы в приложении, которые мы регрессим:
1. приложение падает при старте (скажем, на определенном железе/системе)
2. в одном из основных диалогов приложения расстояния между тремя основными кнопками визуально неодинаковые, разница — 2-3 пикселя
Теперь зададим вопросы по обеим проблемам: проблема серьезная? Отсутствие этой проблемы в билде сделает его «более зеленым»? Присутствие — сделает «более красным»?
Чаще ответ будет: №1 — серьезная, №2 — косметика, можно пропустить. Однако зависит от условий: может система/железо, на которых возникает проблема №1, вовсе не является target системой для приложения, значит эта проблема не должна влиять на принятие решения go/not go. А вторая проблема — иниджевая, заказчик, для которого пишем приложение, уже неоднократно тыкал нас носом в аналогичные проблемы в других местах приложения и использует как аргумент, что мы не в состоянии нормально работать. По-прежнему считаем, что с такой проблемой можно отдавать билд заказчику?
я не уверен, что правильно понял суть. Приемочное тестирование в любом случае осуществляет либо заказчик, либо его представитель в лице продукт-овнера, он же решает, какая из проблем наиболее критична. Речь же о том, чтобы команда была уверена в том, что она отдает и вместо того, чтобы придумывать новые статусы, вроде «более зеленым» или «более красным», идти к тому, чтобы иметь однозначный ответ — зеленый, отдаем, красный — нет.
Ok, не совсем точно выразился (по поводу «более...»). Я о том, что любые тесты выполняются согласно неким заданным критериям: что должно быть, чего быть не должно. Так вот эти критерии в разных проектах могут очень сильно отличаться. В одном проекте проблема №1 сразу сделает билд «красным» (тогда как проблема №2 вообще не будет протестирована), во втором проекте — с точностью до наоборот.
Описываемая область находится на границе знаний между разработчиками и тестировщиками. Если б было ясно сказано, что зеленая/красная лампочка — она только для разработчиков, тогда согласен, команда разработчиков уверена какой продукт отдает. Но поскольку тут упоминался еще и менеджер, который обычно гораздо менее технически подкован чем разработчики и тестировщики, но при этом гораздо лучше знает, чего от продукта ждет заказчик, зеленая/красная лампочка ориентированная и на него тоже, должна нести несколько другой смысл.
Описываемая область находится на границе знаний между разработчиками и тестировщиками. Если б было ясно сказано, что зеленая/красная лампочка — она только для разработчиков, тогда согласен, команда разработчиков уверена какой продукт отдает. Но поскольку тут упоминался еще и менеджер, который обычно гораздо менее технически подкован чем разработчики и тестировщики, но при этом гораздо лучше знает, чего от продукта ждет заказчик, зеленая/красная лампочка ориентированная и на него тоже, должна нести несколько другой смысл.
А последнее по списку, на что я обращал внимание — это как раз команда. Активная работа с продукт-овнером (или менеджером, если он представляет заказчика), как раз и будет приводить к той ситуации, что тесты будут именно те, что нужно, что продукт именно в таком виде заказчику и нужен.
Красная лампочка — она для всей команды, в которую входят и разработчики, и тестировщики, и менеджеры, и продукт-овнеры
Красная лампочка — она для всей команды, в которую входят и разработчики, и тестировщики, и менеджеры, и продукт-овнеры
Воу-воу-воу-воу-воу! Подождите. Вот у нас есть полный пак автоматических функциональных тестов. Если мы совсем молодцы, то у нас есть полный пак и юниттестов. И они все выполняются на каждый коммит и в конце загорается зеленая или красная лампочка. Зеленая лампочка при этом будет свидетельствовать только об одном: продукт выполняет именно то с фукнциональной точки зрения, что от него требуется. Т.е. пользователь сможет залогиниться, пользователь сможет купить что-то и т.д. Но ведь QA — это не просто тестирование функциональных требований! Иначе бы QA-инжинеры бы вообще не нужны были. А где тестирование удобства пользования? А где тестирование производительности? А где тестирование безопасности? А где тестирование того, что все интерфейсы в системе согласованы и похожи (например, форма редактирования пользователя имеет горизонтальный layout, а форма редактирования заказа — вертикальный.
Вот в чем фишка — мы как-бы можем деплоить по зеленой лампочке, но нужно понимать, что еще предстоит очень много работы QA для того, чтобы выявить все вот эти места, где кнопки по 2-3 пикселя различают и пр. Или, например, что будет, если в форму логина засабмитить пароль длиной 2 мб — вы же не будете писать для этого автотест.
Вот в чем фишка — мы как-бы можем деплоить по зеленой лампочке, но нужно понимать, что еще предстоит очень много работы QA для того, чтобы выявить все вот эти места, где кнопки по 2-3 пикселя различают и пр. Или, например, что будет, если в форму логина засабмитить пароль длиной 2 мб — вы же не будете писать для этого автотест.
Тестирование производительности автоматизируется, тестирование безопасности автоматизируется (сканеров сейчас валом), тестирование консистентности UI и тестирование удобства — эм, ребят, а вы это делаете после того, как фича уже готова? Может в процессе работы поговорить с UX-специалистом, а не отдавать QA лишь после нескольких дней разработки?
QA-инженеры нужны, поскольку полностью избавиться от ручного тестирования не удастся.Но их работу надо минимизировать и максимум уводить в автоматизацию. Время человеческое куда дороже времени машинного
QA-инженеры нужны, поскольку полностью избавиться от ручного тестирования не удастся.Но их работу надо минимизировать и максимум уводить в автоматизацию. Время человеческое куда дороже времени машинного
Так о чем и речь, что полностью от ручного тестирования не уйдешь и все-равно остаются какие-то вещи, которые QA должен делать руками. Может быть не перед каждым деплоем, но-таки должен.
Никто ж не спорит против автотестов, они нужны — без них все время QA будет уходить на тупую проверку регрессии, а с ними QA сможет заняться более полезной и интересной работой. Важной, но ручной
Никто ж не спорит против автотестов, они нужны — без них все время QA будет уходить на тупую проверку регрессии, а с ними QA сможет заняться более полезной и интересной работой. Важной, но ручной
По поводу UX — мне пока что не доводилось видеть проекты, в которых еще до девелопмента уже готов идеальный интерфейс, который потом не нужно исправлять. QA это такой человек — он фактически первым видит приложение в сборе с другого ракурса нежели девелопер. Банально: забыли добавить сортировку в drop-down пользователей. На деве их 3, в мокапах просто показан select и все. QA это увидит у заведет баг. UX-специалист с BA могут либо не подумать об этом, либо подумать что это очевидно и не стоит описывать в спеке. Девелопер может тоже об этом забыть. Или еще пример посложнее. Тот же drop-down, но у нас на проде 10к пользователей и выводить их в одном селекте обычном без автокоплита самоубийство. Бывают накладки и девелопер этого даже не увидит, потому что на его машине 10 пользователей. А увидит клиент и подумает, что на него работают какие-то неквалифицированные челы, раз такой вопиющий косяк пропустили. ИМХО это работа QA — не допускать таких косяков. И опять же — ручная.
ИМХО это работа QA — не допускать таких косяков. И опять же — ручная.
нет, QA и тут может автоматизировать. И здорово, если задумается об этом. Я знаю человека, который всю жизнь работает тестировщиком. Он даже не думает об автоматизации и даже перфоманс-тесты делает вручную. Естественно, на это уходит огромное количество времени и надежность таких проверок невелика.
По поводу примера с сортировкой, попробуйте парное программирование и парную работу Developer-QA. Пусть девелоперы увидят, как работают QA-инженеры, а QA посмотрит, как идет работа у девелоперов. Общение поможет им уйти от документации, мокапов и потери информации.
Ну что же вы передергиваете? Я говорю про то что кроме регрессии есть для QA много ручных задач, вы мне про QA, который вообще об автоматизации не думает.
Расскажите, как можно автоматизировать проверку согласованности и логичности UI?
И, если честно, не совсем понимаю вашу позицию. Вы настаиваете на том, чтобы вообще всю работу QA автоматизировать? Чем они тогда должны заниматься?
Расскажите, как можно автоматизировать проверку согласованности и логичности UI?
И, если честно, не совсем понимаю вашу позицию. Вы настаиваете на том, чтобы вообще всю работу QA автоматизировать? Чем они тогда должны заниматься?
Можно вопрос, регрессионное тестирование вы тоже делаете вручную?
Про проверку консистентности UI, это нельзя оставлять на потом. Не думайте о том, автоматизировать это или тестировать руками. Думайте о том, чтобы при разработке UI, ваш дизайнер/UX-специалист находился рядом с разработчиками и работал с ними бок о бок.
По последнему вопросу, да, я очень хочу, чтобы тестирование было полностью автоматизировано. QA-инженеры отчасти и занимаются тем, что автоматизируют end-to-end сценарии, подключая слой UI, каких-то внешних компонентов и прочее.
Про проверку консистентности UI, это нельзя оставлять на потом. Не думайте о том, автоматизировать это или тестировать руками. Думайте о том, чтобы при разработке UI, ваш дизайнер/UX-специалист находился рядом с разработчиками и работал с ними бок о бок.
По последнему вопросу, да, я очень хочу, чтобы тестирование было полностью автоматизировано. QA-инженеры отчасти и занимаются тем, что автоматизируют end-to-end сценарии, подключая слой UI, каких-то внешних компонентов и прочее.
Можно вопрос, регрессионное тестирование вы тоже делаете вручную?
Конечно же нет! Я именно о том и пишу, что автоматизация регрессии как раз-таки и позволяет QA-инжинерам заниматься другими полезными вещами, которые, по моему мнению (не убедили вы меня), никак не автоматизируешь.
Про проверку консистентности UI, это нельзя оставлять на потом. Не думайте о том, автоматизировать это или тестировать руками. Думайте о том, чтобы при разработке UI, ваш дизайнер/UX-специалист находился рядом с разработчиками и работал с ними бок о бок.
Ну я же привел консистентность UI как пример. И я еще не видел проектов, где не было таких косяков. Еще есть куча моментов, которые автоматическими тестами не покроешь. Что будет если в форме добавления пользователя клацнуть два раза на кнопке сабмита? Не добавятся ли случайно два пользователя? А что если… и т.д.
По последнему вопросу, да, я очень хочу, чтобы тестирование было полностью автоматизировано. QA-инженеры отчасти и занимаются тем, что автоматизируют end-to-end сценарии, подключая слой UI, каких-то внешних компонентов и прочее.
Я хочу сказать, что функциональные тесты (их же я называю регрессионными, или end-to-end) — это лишь часть экспертизы QA-инжинеров, которая, несомненно, должна быть автоматизирована. Но вы меня пока что не убедили, что это единственное, зачем нужны QA.
Я чуть-чуть побуду занудой и напомню, что решение о том, чтобы посадить в пару разработчика и тестировщика — это таки задача QA. И да, тестировщик и QA — это совсем не одно и то же. Если тестировщик всю жизнь занимается ручными тестами — прекрасно, это его работа, значит не нашлось никого, кто позаботился бы о QA в его проектах и не выделил области для автоматизации.
А вот от документации уходить никак нельзя, опять же, если есть QA. А если QA отсутствует, то разработчики с тестировщиками как-угодно могут договориться между собой, хоть левой ногой код писать и в телефонном режиме его «тестировать»…
А вот от документации уходить никак нельзя, опять же, если есть QA. А если QA отсутствует, то разработчики с тестировщиками как-угодно могут договориться между собой, хоть левой ногой код писать и в телефонном режиме его «тестировать»…
Пожалуй, немного больше объясню: разница между «тестировщиком» и «QA» примерно такая же, как между «кодером» и «архитектором». Вы же не станете жаловаться, что кодер Вася не проявляет инициативу и не лезет менять архитектуру приложения, напротив, скажете «слава богу, не нужно ему туда соваться». Вот так с тестировщиками, не их задача думать о качестве в проекте, их задача — только контролировать его (качество) используя заранее известные критерии.
ИМХО не стоит разделять тестировщиков и QA-инженеров. Как и не стоит разделять кодеров, программистов, архитекторов. ИМХО в ревльном мире все едино. Software developer — он же кодер, он же девелопер, он же программист — как ни назови, профессия не поменяется. Другое дело, что есть джуниор, миддл, сеньер — в зависимости от кол-ва опыта — от этого зависит, будет ли Вася проявлять инициативу и лезть в архитектуру или нет. Вася джуниор не полезет, Вася сеньер — вполне.
То же самое с QA. Это все одна и та же профессия: QA-инженер. Он же тестер, он же тестировщик или еще как ни назови, суть не поменяется. Это люди, которые ответственны за качество ПО. Джуниоры будут сидеть тыкать на кнопки, сеньеры автоматизировать. Разница практически всегда только в опыте людей
То же самое с QA. Это все одна и та же профессия: QA-инженер. Он же тестер, он же тестировщик или еще как ни назови, суть не поменяется. Это люди, которые ответственны за качество ПО. Джуниоры будут сидеть тыкать на кнопки, сеньеры автоматизировать. Разница практически всегда только в опыте людей
А можно еще шире взять: это все одна профессия — IT-шник. Просто кому-то что-то ближе, в чем-то больше опыта — тем и занимается.
Если серьезно, тестировщик, QA, кодер, архитектор, менеджер — это всего-лишь проектные роли. Другое дело, что не все взаимозаменяемые. Да, QA может работать какое-то время простым тестировщиком, но во-первых его ручная работа будет очень демотивировать, во-вторых, это просто неэффективное использование рессурса. Да и разница между тестировщиком и QA очень большая, QA — это не просто тестировщик с большим опытом, тут нужен опыт управления, опыт разработки.
Да, бывают случаи в реальном мире, когда просто делят на «software developer» и «специалист по качеству», но это чаще в мелких проектах на три калеки, там каждый на все руки мастер и уровень ответственности невысокий. Представьте проект, в котором постоянно присутствует несколько десятков разработчиков, и столько же тестировщиков. Если каждый разработчик (будучи даже сеньером, но выполняющий на проекте строго определенную роль кодера) полезет в архитектуру приложения — вся эта шобла (извините, команда), никогда никуда не приедет. С QA то же самое. Кстати, QA в данном случае будет скорее все равно один, причем не факт, что будет закреплен за этим проектом. И для эффективности его работы иерархия в компании будет выстроена таким образом, чтобы он был не в подчинении никого из команды, включая менеджера, QA — это трезвый взгляд со стороны, а не изнутри песочницы.
Если серьезно, тестировщик, QA, кодер, архитектор, менеджер — это всего-лишь проектные роли. Другое дело, что не все взаимозаменяемые. Да, QA может работать какое-то время простым тестировщиком, но во-первых его ручная работа будет очень демотивировать, во-вторых, это просто неэффективное использование рессурса. Да и разница между тестировщиком и QA очень большая, QA — это не просто тестировщик с большим опытом, тут нужен опыт управления, опыт разработки.
Да, бывают случаи в реальном мире, когда просто делят на «software developer» и «специалист по качеству», но это чаще в мелких проектах на три калеки, там каждый на все руки мастер и уровень ответственности невысокий. Представьте проект, в котором постоянно присутствует несколько десятков разработчиков, и столько же тестировщиков. Если каждый разработчик (будучи даже сеньером, но выполняющий на проекте строго определенную роль кодера) полезет в архитектуру приложения — вся эта шобла (извините, команда), никогда никуда не приедет. С QA то же самое. Кстати, QA в данном случае будет скорее все равно один, причем не факт, что будет закреплен за этим проектом. И для эффективности его работы иерархия в компании будет выстроена таким образом, чтобы он был не в подчинении никого из команды, включая менеджера, QA — это трезвый взгляд со стороны, а не изнутри песочницы.
Sign up to leave a comment.
Для начала внедрим Continuous Integration в мозг