ИМХО не стоит разделять тестировщиков и QA-инженеров. Как и не стоит разделять кодеров, программистов, архитекторов. ИМХО в ревльном мире все едино. Software developer — он же кодер, он же девелопер, он же программист — как ни назови, профессия не поменяется. Другое дело, что есть джуниор, миддл, сеньер — в зависимости от кол-ва опыта — от этого зависит, будет ли Вася проявлять инициативу и лезть в архитектуру или нет. Вася джуниор не полезет, Вася сеньер — вполне.
То же самое с QA. Это все одна и та же профессия: QA-инженер. Он же тестер, он же тестировщик или еще как ни назови, суть не поменяется. Это люди, которые ответственны за качество ПО. Джуниоры будут сидеть тыкать на кнопки, сеньеры автоматизировать. Разница практически всегда только в опыте людей
Можно вопрос, регрессионное тестирование вы тоже делаете вручную?
Конечно же нет! Я именно о том и пишу, что автоматизация регрессии как раз-таки и позволяет QA-инжинерам заниматься другими полезными вещами, которые, по моему мнению (не убедили вы меня), никак не автоматизируешь.
Про проверку консистентности UI, это нельзя оставлять на потом. Не думайте о том, автоматизировать это или тестировать руками. Думайте о том, чтобы при разработке UI, ваш дизайнер/UX-специалист находился рядом с разработчиками и работал с ними бок о бок.
Ну я же привел консистентность UI как пример. И я еще не видел проектов, где не было таких косяков. Еще есть куча моментов, которые автоматическими тестами не покроешь. Что будет если в форме добавления пользователя клацнуть два раза на кнопке сабмита? Не добавятся ли случайно два пользователя? А что если… и т.д.
По последнему вопросу, да, я очень хочу, чтобы тестирование было полностью автоматизировано. QA-инженеры отчасти и занимаются тем, что автоматизируют end-to-end сценарии, подключая слой UI, каких-то внешних компонентов и прочее.
Я хочу сказать, что функциональные тесты (их же я называю регрессионными, или end-to-end) — это лишь часть экспертизы QA-инжинеров, которая, несомненно, должна быть автоматизирована. Но вы меня пока что не убедили, что это единственное, зачем нужны QA.
Ну что же вы передергиваете? Я говорю про то что кроме регрессии есть для QA много ручных задач, вы мне про QA, который вообще об автоматизации не думает.
Расскажите, как можно автоматизировать проверку согласованности и логичности UI?
И, если честно, не совсем понимаю вашу позицию. Вы настаиваете на том, чтобы вообще всю работу QA автоматизировать? Чем они тогда должны заниматься?
По поводу UX — мне пока что не доводилось видеть проекты, в которых еще до девелопмента уже готов идеальный интерфейс, который потом не нужно исправлять. QA это такой человек — он фактически первым видит приложение в сборе с другого ракурса нежели девелопер. Банально: забыли добавить сортировку в drop-down пользователей. На деве их 3, в мокапах просто показан select и все. QA это увидит у заведет баг. UX-специалист с BA могут либо не подумать об этом, либо подумать что это очевидно и не стоит описывать в спеке. Девелопер может тоже об этом забыть. Или еще пример посложнее. Тот же drop-down, но у нас на проде 10к пользователей и выводить их в одном селекте обычном без автокоплита самоубийство. Бывают накладки и девелопер этого даже не увидит, потому что на его машине 10 пользователей. А увидит клиент и подумает, что на него работают какие-то неквалифицированные челы, раз такой вопиющий косяк пропустили. ИМХО это работа QA — не допускать таких косяков. И опять же — ручная.
Так о чем и речь, что полностью от ручного тестирования не уйдешь и все-равно остаются какие-то вещи, которые QA должен делать руками. Может быть не перед каждым деплоем, но-таки должен.
Никто ж не спорит против автотестов, они нужны — без них все время QA будет уходить на тупую проверку регрессии, а с ними QA сможет заняться более полезной и интересной работой. Важной, но ручной
Воу-воу-воу-воу-воу! Подождите. Вот у нас есть полный пак автоматических функциональных тестов. Если мы совсем молодцы, то у нас есть полный пак и юниттестов. И они все выполняются на каждый коммит и в конце загорается зеленая или красная лампочка. Зеленая лампочка при этом будет свидетельствовать только об одном: продукт выполняет именно то с фукнциональной точки зрения, что от него требуется. Т.е. пользователь сможет залогиниться, пользователь сможет купить что-то и т.д. Но ведь QA — это не просто тестирование функциональных требований! Иначе бы QA-инжинеры бы вообще не нужны были. А где тестирование удобства пользования? А где тестирование производительности? А где тестирование безопасности? А где тестирование того, что все интерфейсы в системе согласованы и похожи (например, форма редактирования пользователя имеет горизонтальный layout, а форма редактирования заказа — вертикальный.
Вот в чем фишка — мы как-бы можем деплоить по зеленой лампочке, но нужно понимать, что еще предстоит очень много работы QA для того, чтобы выявить все вот эти места, где кнопки по 2-3 пикселя различают и пр. Или, например, что будет, если в форму логина засабмитить пароль длиной 2 мб — вы же не будете писать для этого автотест.
Речь не идет о том, чтобы деплоить руками по SSH. Разве что в самых простых системах это бывает возможно. Речь о том, чтобы поставить какой-то функционал, который при этом не покрыт тестами. При этом, конечно же, поставить его через стандартные кнопки build -> deploy to production (у каждого по-своему, но суть та же).
Если грубо посчитать, то на тесты у нас уходит примерно ~ +50% времени к фиче. И это при том, что сами сценарии в стиле новомодного BDD пишут для нас QA еще до начала работы над функционалом. Так вот, очень часто бывает, что какой-то функционал нужно поставить в этот релиз позарез. Ну вот нужно бизнесу и все. Ты же не скажешь — не, ребята, нам нужно написать тесты, поэтому все будет только через неделю. Вот и получается, что поставляется через 3 дня функционал без тестов (проверенный вручную), а потом через еще несколько дней приезжают тесты к нему.
Неправда. Плохие тесты будут тянуть вас в пучину красных билдов, километровых фикстур и правки 60% тестов при изменении класса кнопки сабмита. А потом вся команда включая топ-менеджемент будет говорить, что тесты не нужны и даже вредны.
проектах к кучей легаси-кода
Бывают юниттесты, покрытие которыми легаси-кода равноценно самоубийству. Но покрытие юниттестами готового кода вообще сомнительное занятие. А бывают функциональные, или как еще их называют приемочные, или BDD, или specification by example — каждый называет на свой лад, придумывают все новые и новые модные названия — но суть не меняется. Так вот в них разницы уже между легаси-кодом и супер-пупер-навороченным ООП чудом техники, построенным по принципам SOLID практически нету. Так вот именно эти вот приемочные тесты и должны быть показателем того, что продукт готов к деплою.
Очень часто эти типы тестов путают и называют их просто — тесты. А потом пишут на PHPUnit/JUnit/NUnit (нужное подчеркнуть) юниттесты на класс UserPasswordValidator рядом с тестами RegistrationPage.
А расскажите подробнее, почему больше не доверяете? Я тоже всегда делаю fetch, а потом смотрю что дальше, но теперь хотел делать всегда git pull --rebase вместо ручного git fetch && git merge/rebase
Я бы не стал так категорично заявлять. Как стандартный workflow, push -f, конечно, сложно принять. Но как инструмент для применения иногда — почему бы и нет. Раз уж у нас есть такой крутой git pull --rebase
Конечно же, я имел ввиду git fetch && git rebase — опечатался там.
Нет никаких солюшенов и сводов правил, есть вы и git, некий набор инструментов в рамках гита и ваше умение ими пользоваться.
Кажется, до меня дошла ваша мысль ). Если есть понимание инструментов и умение ими пользоваться плюс база различных паттернов их использования, то для каждого проекта каждый сам сможем решить для себя, какие техники и когда применять.
+1, про race-condition я даже и не подумал, когда писал коммент! А ведь действительно, причем там не секунды синхронизации, далеко не секунды. Нужно обязательно перед каждым push --force делать тот же pull --rebase. Если забыл и затер изменения коллеги — будет много недовольных в лучшем случае. Т.е. добавляется еще одно административное ограничение кроме как запускать git pull --rebase — запускать его пере push, причем прямо перед самым им, чтобы минимизировать между ними время и, соответственно, вероятность race condition
Это не очевидно, но git pull --rebase делает не просто git pull && git rebase. Как вы процитировали доки выше, он смотрит, не ребейзился ли апстрим, и если ребейзился, то он ребейзит только те изменения что добавили мы. Это вообще говоря, похоже не хак и корректно работает только в некоторых конкретных случаях: когда у нас есть один главный бранч и фичебранчи. Действительно тогда фичебранчи можно без проблем ребейзить, если все делают git pull --rebase при работе. Как только система становится сложнее (например, добавляется фичебранч, основанный на другом фичебранче, как тут), git pull --rebase уже не будет корректно работать (как, собственно, вы и написали в конце статьи). Подозреваю, что все станет еще хуже, как только у вас появятся релиз-бранчи, staging, хотфиксы в master. Если только не взять за правило ничего кроме фичебранчей не ребейзить.
Конечно, линейная история гита при использовании долгоживущих фичебранчей это круто. И я ни в коем случае не агитирую против такого подхода, потому что хистори гита это часть исходников и как и все другие исходники она должна быть чистой и понятной. (Я против фичебранчей в целом, но это не относится к теме этой статьи.) Но цена за такую линейную историю — грязные хаки в виде git pull --rebase, которые будут работать только в конкретных случаях. Т.е. как только у нас в репозитории произойдет что-то нестандартное, наш стандартный хак не сработает. Это должно быть как-то административно поставлено, что все используют только git pull --rebase, что тоже не очень хорошо, ИМХО.
Повторюсь, я не против такого подхода, если необходимость использования долгоиграющих (например, отдельно тестируемых) фичебранчей не ставится под сомнение, но нужно понимать границы применения, и цену такого подхода.
ИМХО какой-то детский сад развели в комментариях. Уже лет N все передовые фреймворки кладут в DOCUMENT_ROOT веб-сервера только лишь index.php и статику. Остальное — от лукавого. Вы можете сколько угодно проверять доступы, писать .htaccess, проверять пути. Но достаточно хоть где-то немного ошибиться системному администратору — и все пропало: habrahabr.ru/post/112237/
Раньше, когда на мобильниках были кнопки, я выключал будильник на лежащем на уровне кровати телефоне не глядя на него — одной рукой. Теперь, в эпоху тачскринов у меня уже нету фидбека — попасть по слайдеру/кнопке выключения, не видя экрана, очень сложно. Приходится брать телефон в одну руку и отключать его второй рукой. Жутко бесит! Понимаю, что проблема решается установкой нестандартного будильника (типа приостанавливающегося при тыке куда угодно) и пр, но интерфейс, распознающий жесты тоже был бы кстати тут
Не принимайте близко к сердцу, но… У вас совершенно неадекватные представления о сложности морфологии русского языка… То, что вы делаете сейчас абсолютно так же, но насколько это возможно лучше делает PHPMorphy. Насколько я знаю, у него тоже много правил окончаний + списки исключений. Поверьте, сделать существенно лучше чем у них морфологию не получится. Это мы говорим про чистую морфологию — узнать часть речи и форму по одному слову.
Далее: «Косил косой косой косой», тут уже функцией с правилами на PHP не обойдешься. Тут, как правильно вы заметили, нужно строить деревья синтаксического разбора, выбирать более подходящие из них, на основании этого уточнять морфологические приметы слов, потом выбирать то дерево, которое нам больше нравится и т.д. Работы много. Очень много. Посмотрите на aot.ru — ребята этим занимаются на C++ в свободное время: кода много, словарей много, правил много — а результат не то чтобы сильно крутой был. Ну т.е. простые предложения оно распознает, а вот со сложными начинаются проблемы.
Повторюсь еще раз: у вас абсолютно неадекватное представление о сложности подобных библиотек и завышенные представления о своих возможностях. Не принимайте близко к сердцу. Покрутите PHPMorphy, если вам его возможностей будет мало — идите на aot.ru, покрутите их либы. Более крутого из опенсорсного, насколько я знаю (уже несколько лет не интересовался этой темой) вы не найдете. И конечно же не напишете, если только у вас нету штата лингвистов, программистов и денег им на хлеб с маслом на несколько лет.
То же самое с QA. Это все одна и та же профессия: QA-инженер. Он же тестер, он же тестировщик или еще как ни назови, суть не поменяется. Это люди, которые ответственны за качество ПО. Джуниоры будут сидеть тыкать на кнопки, сеньеры автоматизировать. Разница практически всегда только в опыте людей
Конечно же нет! Я именно о том и пишу, что автоматизация регрессии как раз-таки и позволяет QA-инжинерам заниматься другими полезными вещами, которые, по моему мнению (не убедили вы меня), никак не автоматизируешь.
Ну я же привел консистентность UI как пример. И я еще не видел проектов, где не было таких косяков. Еще есть куча моментов, которые автоматическими тестами не покроешь. Что будет если в форме добавления пользователя клацнуть два раза на кнопке сабмита? Не добавятся ли случайно два пользователя? А что если… и т.д.
Я хочу сказать, что функциональные тесты (их же я называю регрессионными, или end-to-end) — это лишь часть экспертизы QA-инжинеров, которая, несомненно, должна быть автоматизирована. Но вы меня пока что не убедили, что это единственное, зачем нужны QA.
Расскажите, как можно автоматизировать проверку согласованности и логичности UI?
И, если честно, не совсем понимаю вашу позицию. Вы настаиваете на том, чтобы вообще всю работу QA автоматизировать? Чем они тогда должны заниматься?
Никто ж не спорит против автотестов, они нужны — без них все время QA будет уходить на тупую проверку регрессии, а с ними QA сможет заняться более полезной и интересной работой. Важной, но ручной
Вот в чем фишка — мы как-бы можем деплоить по зеленой лампочке, но нужно понимать, что еще предстоит очень много работы QA для того, чтобы выявить все вот эти места, где кнопки по 2-3 пикселя различают и пр. Или, например, что будет, если в форму логина засабмитить пароль длиной 2 мб — вы же не будете писать для этого автотест.
Если грубо посчитать, то на тесты у нас уходит примерно ~ +50% времени к фиче. И это при том, что сами сценарии в стиле новомодного BDD пишут для нас QA еще до начала работы над функционалом. Так вот, очень часто бывает, что какой-то функционал нужно поставить в этот релиз позарез. Ну вот нужно бизнесу и все. Ты же не скажешь — не, ребята, нам нужно написать тесты, поэтому все будет только через неделю. Вот и получается, что поставляется через 3 дня функционал без тестов (проверенный вручную), а потом через еще несколько дней приезжают тесты к нему.
Неправда. Плохие тесты будут тянуть вас в пучину красных билдов, километровых фикстур и правки 60% тестов при изменении класса кнопки сабмита. А потом вся команда включая топ-менеджемент будет говорить, что тесты не нужны и даже вредны.
Бывают юниттесты, покрытие которыми легаси-кода равноценно самоубийству. Но покрытие юниттестами готового кода вообще сомнительное занятие. А бывают функциональные, или как еще их называют приемочные, или BDD, или specification by example — каждый называет на свой лад, придумывают все новые и новые модные названия — но суть не меняется. Так вот в них разницы уже между легаси-кодом и супер-пупер-навороченным ООП чудом техники, построенным по принципам SOLID практически нету. Так вот именно эти вот приемочные тесты и должны быть показателем того, что продукт готов к деплою.
Очень часто эти типы тестов путают и называют их просто — тесты. А потом пишут на PHPUnit/JUnit/NUnit (нужное подчеркнуть) юниттесты на класс UserPasswordValidator рядом с тестами RegistrationPage.
Кажется, до меня дошла ваша мысль ). Если есть понимание инструментов и умение ими пользоваться плюс база различных паттернов их использования, то для каждого проекта каждый сам сможем решить для себя, какие техники и когда применять.
Конечно, линейная история гита при использовании долгоживущих фичебранчей это круто. И я ни в коем случае не агитирую против такого подхода, потому что хистори гита это часть исходников и как и все другие исходники она должна быть чистой и понятной. (Я против фичебранчей в целом, но это не относится к теме этой статьи.) Но цена за такую линейную историю — грязные хаки в виде git pull --rebase, которые будут работать только в конкретных случаях. Т.е. как только у нас в репозитории произойдет что-то нестандартное, наш стандартный хак не сработает. Это должно быть как-то административно поставлено, что все используют только git pull --rebase, что тоже не очень хорошо, ИМХО.
Повторюсь, я не против такого подхода, если необходимость использования долгоиграющих (например, отдельно тестируемых) фичебранчей не ставится под сомнение, но нужно понимать границы применения, и цену такого подхода.
Далее: «Косил косой косой косой», тут уже функцией с правилами на PHP не обойдешься. Тут, как правильно вы заметили, нужно строить деревья синтаксического разбора, выбирать более подходящие из них, на основании этого уточнять морфологические приметы слов, потом выбирать то дерево, которое нам больше нравится и т.д. Работы много. Очень много. Посмотрите на aot.ru — ребята этим занимаются на C++ в свободное время: кода много, словарей много, правил много — а результат не то чтобы сильно крутой был. Ну т.е. простые предложения оно распознает, а вот со сложными начинаются проблемы.
Повторюсь еще раз: у вас абсолютно неадекватное представление о сложности подобных библиотек и завышенные представления о своих возможностях. Не принимайте близко к сердцу. Покрутите PHPMorphy, если вам его возможностей будет мало — идите на aot.ru, покрутите их либы. Более крутого из опенсорсного, насколько я знаю (уже несколько лет не интересовался этой темой) вы не найдете. И конечно же не напишете, если только у вас нету штата лингвистов, программистов и денег им на хлеб с маслом на несколько лет.