и так из версии в версию

nope

качество зависит от всех звеньев цепи разработки

а еще разрабы иногда свое решение тестируют: один получше смотрит, повнимательнее: а другой даже не запускает

вот в данном случае это говорит о том что один разраблучше другого?

а как ты узнаешь, кто из них лучше проверяет свой код?

вот в данном случае это говорит о том что один разраблучше другого?

ну этот разраб в итоге потратил в 2 больше времени на реализацию задачи

или даже не лучше а ответственнее

а первый не потратил: но это время потратили тестировщик и тот же разработчик фикся баги

бросай ты это дело

оно до добра не доведет

та я так не делаю) просот с этми столкнуля стало интересно мнение)

Вообще лучше всем работать хорошо, а не выяснять кто виноват))

Извините)) Ваш Кэп))

но вдеь не бывает так что ни кто не виноват?

почему нельзя разделять ответсвенность?

качество зависит от всех звеньев цепи разработки

?

ПМ виноват обычно)))

либо все, либо ни кто

ПМ виноват обычно)))

плюсую )

поддерживаю

почему нельзя разделять ответсвенность?

ответственность разная, а команда одна и продукт один

ы. А у нас никто никогда не виноват)

а кто решает что релиз делать нельзя

в хорошем смысле)

например пм говорит всеравно выкатываем а тетсировщики такие анм стыдно за такой продукт

а кто решает что релиз делать нельзя

Так от проекта/компании зависит

слушаем ПМа

например пм говорит всеравно выкатываем а тетсировщики такие анм стыдно за такой продукт

ну значит ПМ решает :)

ну понятно что все у всез по разному но собирая все разное можно анйти хорошие и плохие практики

или пытаемся переубедить

принимает решение менеджмент

и еще вопрос а многие тут пользуются теми продуктами что разрабатывают?

ну понятно что все у всез по разному но собирая все разное можно анйти хорошие и плохие практики

ну тады знакомся с моделями разработки и смотри как ведуться процессы

а там уже исходя из них и решай, кто решает, когда решает и почему

модели разработки в книжках одни а в жизни другие(

Даже аксептанс критерии можно опустить по решению менеджмента

принимает решение менеджмент

опять плюсую Ответственность в итоге на менеджменте и они с Продукт-овнером общаются :)

модели разработки в книжках одни а в жизни другие(

ну дык)

модели разработки в книжках одни а в жизни другие(

"как положили говняшку, так и воняет"

если люди будут пользоваться продуктом который они делают не только на работе но и в жизни это увеличит качество?

ога, а еще ненависть и боль

интересно, а инженеры Гугла гуглят ?

ахахаха

нет, юзают msn

что б их не палили

вот вот)

torch юзают

рамблер

если люди будут пользоваться продуктом который они делают не только на работе но и в жизни это увеличит качество?

Мне кажется это не взаимосвязано никак: конечно если речь не о внутренних инструментах. Тут все по другому

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

хорошо а тут люди предпочитают свой продукт или другие аналоги?

ы. Я физически немогу использовать свои продукты)))

ну а елси бы могли?

Ну вообще хорошо бы да, использовать стараться. Другой вопрос, если ты вообще не целевая аудитория продукта своего.

И так бывает.

я к тому что разве осведомленность в продукте не помогает делать его лучше?

ну тоесть ПМ должен ведь знать хорошо про продукт как он может что либо предлагать дельного елси сам не пользуется?

или тестировщик что либо смотрит и говорит вот такое решение неудобное и елси пользуется продуктом может аргументировать

если человек не пользуется например мобильным банком как он придумает какой функционал там более енмобходим какой должен быть максимально и легко доступным

или это совсем не обязательно?

если хорошо развита связь с комьюнити проекта, то можно и на этом выжить

ну тоесть ПМ должен ведь знать хорошо про продукт как он может что либо предлагать дельного елси сам не пользуется?

ну ПМ, на мой взгляд, должен знать Как продукт и Почему работает; и понимать Цели бизнесса. Но все таки по итогу, комерческий продукт: за него платит Продукт овнер и соответственно понимание За счет чего этот продукт принесет деньги - это то же знает продукт овнер. Ну и по такой схеме: инициативы должны от продукт овнера исходить. Какие-то незначительные улучшения могут исходить из команды, но это скорее Апдейты и Фиксы чем Фичи

Рефакторинг обычно исходит только от команды и на этом ломают по 100 копий с бизнесом

ERROR: S client not available

А еще часто бывает что бизнес дает какие-то неясные очень бизнес-требования из которых вся команда пытается родить спецификацию, пытая ПМа в процессе

команда с марса, бизнес с венеры

Но их тянет друг к другу...

Все верно, найти общий язык между разработкой и бизнесом очень непросто. И не всегда адекватно получается. И бизнес неадекватно оценивает трудозатраты и рынок, а команда - трудозатраты на разработку.

Но ведь синтетические результаты получаются. Разве нет? Операционная система отличается от Оси целевой аудитории. И ФФ не настолько популярный как хром. Хотя имеет смысл посмотреть в сторону api хрома, и с его помощью мерить. Эти плагины все умеют отслеживать тот самый момент, когда страница полностью отрисовалась?

Настя , в этой теме все результаты синтетические кроме статистики с продана, но там уже поздно :)

Почему поздно? Можно же в ближайшем релизе запилить улучшения и снова наблюдать статистику.

И сделать из юзеров бета тестеров за их же деньги Ага

Тестируем на проде

Привет! Вопрос такой: кто-нибудь пишет тесты на TypeScript? Какой unit-test фреймворк используете? Tsunit кажется сыроватым.

Привет! Вопрос такой: кто-нибудь пишет тесты на TypeScript? Какой unit-test фреймворк используете? Tsunit кажется сыроватым.

Привет. Писал не много. В основном jasmine or cucumber. В основном на последнем пилил. Но имхо завязывать с ним надо)

Привет. Писал не много. В основном jasmine or cucumber. В основном на последнем пилил. Но имхо завязывать с ним надо)

Спасибо, посмотрю в эту сторону!

приветствую, коллеги. а поведайте, должен ли тестировщик знать, как работают репозитории? как код взаимодействует с базой? и другие интимные подробности.

приветствую, коллеги. а поведайте, должен ли тестировщик знать, как работают репозитории? как код взаимодействует с базой? и другие интимные подробности.

должен

по хорошему да

поясните пожалуйста

как минимум чтоб понимать о чем речь идет)

не обязательно в подробностях

вот тут и вопрос, какая степень подробности? ну знаю что есть репозиторий который создаёт пользователя, мне надо код смотреть, как он его создаёт и всё такое?

репозиторий - это хранилище. он ничего не создает

приветствую, коллеги. а поведайте, должен ли тестировщик знать, как работают репозитории? как код взаимодействует с базой? и другие интимные подробности.

что значит должен или не должен? странная постановка вопроса. если он в проекте применяется и он с ним сталкивается, то должен понимать на уровне бранчей и пулов. Если нет, то в рамках общих процессов разработки.

Иногда полезно, при наличии времени заглядывать в тесты, которые разработчики пишут. Особенно, если планируешь сам потом автоматизировать. Делать так сказать неполноценный code review, беглый.

вот тут и вопрос, какая степень подробности? ну знаю что есть репозиторий который создаёт пользователя, мне надо код смотреть, как он его создаёт и всё такое?

я бы сказал, что нужно понимать что и где лежит в этом репозитории и как это достать

о кстати а вот про репозиторий раз говорим, у вас как пользуют его с gui или нет?

под репозиторием я имею ввиду патерн. а не репозитории гита

о кстати а вот про репозиторий раз говорим, у вас как пользуют его с gui или нет?

у нас с гуи

под репозиторием я имею ввиду патерн. а не репозитории гита

я после этого не понимаю о чем речь: Можно как то подробнее ? Паттерн чего ?

у нас с гуи

при этом на собеседовании спрашивали знаете команды для гита или нет?

я после этого не понимаю о чем речь: Можно как то подробнее ? Паттерн чего ?

https://msdn.microsoft.com/en-us/library/ff649690.aspx

я после этого не понимаю о чем речь: Можно как то подробнее ? Паттерн чего ?

http://design-pattern.ru/patterns/repository.html

при этом на собеседовании спрашивали знаете команды для гита или нет?

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