@qa_ru

Страница 700 из 1080
Pavel
29.09.2017
12:04:50
> Кто формирует критерии качества продукта, следит за соответствием релизов оным и прочее? Кто пишет E2E тесты на выпускаемый функционал? Разрабы и девопсы могут вполне этим заниматься, в тесном сотрудничестве с product owner

roma
29.09.2017
12:05:20
Критерии качества определяет заказчик, разработчик самостоятельно пишет юнит тесты по tdd, пишет интеграционные тесты и e2e. Всё сам делает. Но это работает только когда разработчик очень опытный и заказчик даёт исчерпывающие требования, критерии качетсва, приёмки. А разработчик плюс ко всему следит за логами

Google
Artem
29.09.2017
12:05:59
проблема в том ребятки, что вы отталкиваетесь от своего опыта работы и у каждого там свои приколы были и разные люди работали

roma
29.09.2017
12:06:01
Artem
29.09.2017
12:06:07
поэтому ваш спор заведомо бессмыслен

Artem
29.09.2017
12:06:44
можете заканчивать =)

roma
29.09.2017
12:06:48
поэтому я там выше в 14:56 написал как приходится работать)

расходимся)

Pavel
29.09.2017
12:09:48
девопс это про процесс, а не про выделенную роль
Есть должности devops engineer, или по нашему девопсы, которые все время и занимаются подстройкой инфраструктуры, ревьюингом багов и т.д. Все деления на разрабов/qa/админов/девапсов плюс-минус условны, каждый человек может включать в себя несколько ролей. Иногда можно обойтись без всех.

У нас кстати qa открестились от написания e2e тестов, мы это делаем силами dev команды.

Pavel
29.09.2017
12:11:33
Ну там надо язык программирования знать, во фреймворке разбираться - тяжело.

Dmitry
29.09.2017
12:13:12
Расскажи потом об опыте внедрения парного тестирования.

Google
Dmitry
29.09.2017
12:14:06
После внедрения

Какой Профит итд

Shoo
29.09.2017
12:16:14
Критерии качества определяет заказчик, разработчик самостоятельно пишет юнит тесты по tdd, пишет интеграционные тесты и e2e. Всё сам делает. Но это работает только когда разработчик очень опытный и заказчик даёт исчерпывающие требования, критерии качетсва, приёмки. А разработчик плюс ко всему следит за логами
Если вы читали хотя бы одну книжку по XP, то знаете, что вся эта заварушка началась с осознания того, что заказчик никогда не дает исчерпывающие, полные и корректные критерии качества и приемки. Он (заказчик этот) в большинстве случаев даже функциональные требования формализовать не в состоянии, что уж там говорить о технических.

Ну, и со всем остальным так же. Разработчик может писать e2e тесты. Только вот в TDD и XP это не укладывается. Разработчик может формировать критерии качества, ставить метрики и отвечать за их выполнение. Только в перечисленные практики это тоже не укладывается. И тестить руками разработчик тоже может, но проблема та же. Так мы и приходим к тому, что ваше волшебное заклинание "TDD, XP и парное программирование" нифига не решает задач QA, т.е. не работает. Нужно ещё массу всего поверх накрутить и выстроить, и может быть оно заработает.

Но тут есть проблема: много ли есть на рынке разработчиков, способных параллельно и качественно выполнять функции аналитика, qa и разработчика (а лучше фуллстэка с опытом девопс, ага)? Нет, таких ребят довольно мало. Плюс к этому они, обычно, довольно хорошо устроены в плане работы и стоят как этот самый аналитик, тестировщик и разработчик вместе взятые.

Egor
29.09.2017
12:22:54
Парное тестирование - это когда один тыкает мышкой в экран, второй записывает его действие ввиде сценариев/ЧЛ. Так ведь?

Pavel
29.09.2017
12:23:25
А трипл тестирование бывает?

Egor
29.09.2017
12:23:53
Бывает, в баре

Dieva
29.09.2017
12:24:00
А трипл тестирование бывает?
трип тестирование бывает

Pavel
29.09.2017
12:24:02
?

Egor
29.09.2017
12:24:29
чтозабред....
прошу пояснить

в последний раз этот термин "парное тестирование" видел именно в сказанном мной контексте. Вот и хочу уточнить, на сколько этот термин мутировал с тех времен

Egor
29.09.2017
12:26:07
Этот подход использовался, когда в наличие есть руки, но нет времени и нужно писать отчет о том что было протестировано\

ОДин тестирует, второй готовит по ходу отчет

Vlad
29.09.2017
12:27:57
в последний раз этот термин "парное тестирование" видел именно в сказанном мной контексте. Вот и хочу уточнить, на сколько этот термин мутировал с тех времен
я могу сидеть тестить с разрабом вобнимку. и он будет фиксить на лету баги. мне не понравился контекст "тыкает-записывает"

Egor
29.09.2017
12:28:29
Эм. ТО есть парное тестирование - это один тестирует, второй сразу правит?

Pavel
29.09.2017
12:29:16
Блин неужели это так важно?

Egor
29.09.2017
12:29:26
термин не покрывает суть происходящего совершенно. Второй же не тестирует, что бы это называлось парным тестированием

Google
Vlad
29.09.2017
12:29:26
как угодно. как и с парной разработкой просто два чела за одним компом, остальное имхо это религиозные деноминации

Pavel
29.09.2017
12:29:42
Просто сидите вдвоем за экраном и делайте все что приводит к уменьшению энтропии в багтрекере.

Vlad
29.09.2017
12:29:49
почему не тестирует?

если человека зовут разраб, это не значит, что он не должен тестировать.

Egor
29.09.2017
12:30:43
В общем, не буду развивать полемику/демагогию/флуд (нужное подчеркнуть), спасибо за прояснение термина

Vlad
29.09.2017
12:31:04
Вам спасибо, что подняли интересный вопрос.

Danil
29.09.2017
12:36:17
Какими инструментами пользуетесь для кроссбраузерного регрессионного тестирования?

Zuboff
29.09.2017
12:40:58
Как по мне в вопросе содержится ответ

Vladimir
29.09.2017
12:45:00
Браузерами, наверное (:

Danil
29.09.2017
13:00:32
Браузерами. Или в чате не поняли вопрос.
Конкретно скриншот тестирование. Пример: https://github.com/gemini-testing/gemini

Dieva
29.09.2017
13:00:47
я думаю что именно это имелось ввиду

Shoo
29.09.2017
13:05:34
Так вам скриншотное тестирование, или кроссбраузерное? :)

Alekons
29.09.2017
13:25:27
Вопрос: Developer Senior должен покрывать свой код unit тестами? (по крайней мере он себя так называет Senior =) )

Richard
29.09.2017
13:27:22
Конечно должен.

Aleksandr
29.09.2017
13:30:23
Нет, не должен.
А кто должен? :)

Google
Shoo
29.09.2017
13:31:15
А кто должен? :)
Если в команде принята практика писать тесты на свой код, то любой разработчик в команде, независимо от степени сеньорности, должен это делать. Если такой практики в команде нет - то никто не должен. Логично же.

Shoo
29.09.2017
13:32:39
Нет, не сомнительная.

Aleksandr
29.09.2017
13:33:21
Ты сегодня немногословен. Выбивать пояснения надо. :)

Shoo
29.09.2017
13:33:32
Все сильно зависит от ситуации и потребностей бизнеса. Все эти ваши "бест практисес" сильно ситуативны и не стоит их применять просто что б применять.

Filipp
29.09.2017
13:34:50
В таком случае хотелось бы услышать примеры, когда нет разработки на пожаре, продукт не очень маленький, и не очень большой legacy. Т.е., условно, в нормальных условиях, и чтобы юнит-тесты были не нужны.

Shoo
29.09.2017
13:34:59
Ты сегодня немногословен. Выбивать пояснения надо. :)
Ну, допустим. У вас есть задача: быстро запрототипировать сервис, проверить теорию и или удалить репозиторий, или развивать уже в качестве полноценного продукта. Вот на этапе создания условного MVP, когда нужно "быстро и дешево" - тесты это очевидный оверхед и нахрен не нужны.

В таком случае хотелось бы услышать примеры, когда нет разработки на пожаре, продукт не очень маленький, и не очень большой legacy. Т.е., условно, в нормальных условиях, и чтобы юнит-тесты были не нужны.
Сильно динамичная кодовая база, хорошая степень вовлеченности разработчиков в бизнес и функциональную логику + наличие покрытия более высокоуровневыми тестами.

Это в качестве примера.

Друзья, обязательное написание юнитов - это довольно большие косты. Для всех практик есть соотношение стоимости их применения и выхлопа от оных. Если у вас есть на продукте высокий регрешшен рейт, например - юниты могут помочь решить эту проблему. Это, правда, выльется в сильное замедление (и увеличение стоимости, как следствие) разработки, но тут надо смотреть на это самое соотношение costs vs values.

Shoo
29.09.2017
13:38:38
Слепое утверждение "юнит тесты должны обязательно писаться всегда" - попытка изобрести silver bullet там, где их нет в принципе.

Vladimir
29.09.2017
13:39:17
Costs vs values всегда важны ))

Vladimir
29.09.2017
13:39:36
Идеалисты могут про них забыть)

Aleksandr
29.09.2017
13:40:47
Только написание юнитов может никак не сокращать скорость тестирования вообще.
Ну, я считаю, что юнит-тестирование - это в большей степени разработка, чем тестирование.

Aleksandr
29.09.2017
13:41:22
Лол
Обоснуй. :)

Shoo
29.09.2017
13:41:24
Ну, в итоге длительность разработки у вас увеличивается (порядочно так), длительность тестирования и планирования остается прежней. Вы начинаете быстрее выпускать фичи? (Спойлер: нет)

Google
Shoo
29.09.2017
13:42:42
Я на своей практике видел достаточно много случаев, когда дешевле, проще и правильнее было 3 раза написать хреново, показать feature ownerу, получить фидбэк и вылить, чем классно подумать, хорошо оттестировать, юнитов наворотить, а через N*3 это выкинуть к херам.

Aleksandr
29.09.2017
13:42:46
Меньше багов уходит на тестирование.

Shoo
29.09.2017
13:43:05
У нас увеличивается качество кода.
Оно может увеличиваться.

Юниты не гарантируют ни качество кода, ни уменьшение количества багов на этапе тестирования.

Artur
29.09.2017
13:43:29
Тестировщик как проверял 10 сценариев по фиче, так и будет проверять.

Filipp
29.09.2017
13:45:06
Слепое утверждение "юнит тесты должны обязательно писаться всегда" - попытка изобрести silver bullet там, где их нет в принципе.
Напоминание об отсутствии серебряных пуль - вещь, безусловно правильная. И анализировать соотношение выгоды/затрат тоже крайне желательно. Но все-таки у меня было ощущение, что за редким исключением юнит-тесты полезны. Это дополнительный барьер для багов, очень серьезная поддержка при рефакторинге и переезде на новые технологии. Жаль, личный опыт - не статистика, но вот как раз с "динамичной кодовой базой" и без тестов проект был болью - отвалиться могло что угодно и где угодно. А сейчас на проекте с юнит-тестами жизнь играет гораздо более позитивными красками

Хотя, конечно, это не статистика, и там много факторов было кроме юнит-тестов

Тестировщик как проверял 10 сценариев по фиче, так и будет проверять.
С юнит-тестами должно уменьшаться количество возвратов после проверки из-за багов

Shoo
29.09.2017
13:46:20
Юниты не гарантирую правильную работу фичи, в этом проблема.

Artur
29.09.2017
13:46:37
С юнит-тестами должно уменьшаться количество возвратов после проверки из-за багов
Ну я рассматривал время тестирования, т.е. столько, сколько тестировщик проверяет фичу.

Shoo
29.09.2017
13:46:46
Если 90% багов в проекте - что код ссылается на несуществующую переменную, или где-то там ассайнмент не происходит - юниты дают очень большой выхлоп.

Если большинство косяков в бизнес логике - юниты вам не дадут примерное ничего.

Filipp
29.09.2017
13:48:01
Ну я рассматривал время тестирования, т.е. столько, сколько тестировщик проверяет фичу.
дело же не только в проверке. Проверили - нашли баги - проверяем снова исправления - новый цикл

Flashcsgroup
29.09.2017
13:48:31
при создании мавенского с зависимостями log4j проекта в идее в папке ресурсы файл log4j.properties сам создается или откуда его брать со стандартными настройками?

Artur
29.09.2017
13:50:38
дело же не только в проверке. Проверили - нашли баги - проверяем снова исправления - новый цикл
в данном слуае реально уже зависит от того какого рода ошибки, далее как Shoo сказал, проблему кривого кода это решит, кривой логики вряд ли

Evgeniy
29.09.2017
13:51:17
Ну, я считаю, что юнит-тестирование - это в большей степени разработка, чем тестирование.
Процедурное программирование, database oriented разработка . Data driven тестирование - по сути юнит тестирование- если ЭТО не тестирование в таком проекте, тогда что?

Filipp
29.09.2017
13:53:14
в данном слуае реально уже зависит от того какого рода ошибки, далее как Shoo сказал, проблему кривого кода это решит, кривой логики вряд ли
У меня есть ощущение, что ошибки есть и те и те. Разные языки, конечно, могут влиять, но после юнит-тестов по крайней мере одного типа ошибок будет сильно меньше

Shoo
29.09.2017
13:53:47
У нас, например, довольно высокий кавередж на текущем проекте, но падения тестов преимущественно псевдослучайные. Багов от этого меньше не становится.

Страница 700 из 1080