PO
Или погрузить свою доску и отвезти в помойку? А зачем 4 штуки если одну можно повесить?
Это для SAFe:)
Size: a a a
2019 December 17
VL
Вот откуда эта мода на матерчатые перегородки? У нас всю мебель на них меняют. Разве они не собирают пыль? (
стеклянные же, нет?
US
стеклянные же, нет?
Нет, нет. Матерчатые. И в Икее сейчас полно такой мебели
2019 December 18
US
В Финляндии такая же мода. Перегородки матерчатые.
VL
хз. у нас дерево и стекло. может просто бц класса А, остальные так не парятся
EM
Тележка с досками не выходит у меня из головы... Что с ней делать? Подарить продакт оунеру и сказать "теперь хватит места для бэклога" ?
Хороший подарок на Новый год)
侯
非小号Mytoken推特脸书增关注，菠菜棋牌推广霸屏强推APP内置广告，微信电报增粉私聊、推广，交易所上币投票，交易所平台账号代实名，如有需要请联系:➡️ @yx00001
T
Я сегодня на PBR одной из эрий периодически считал сколько разработчиков в телефонах сидело. Записывал молча максимум на флипчарте. Если появлялось больше - перечеркивал старую цифру и писал бОльшую. На четвертой цифре меня спросили что я делаю. Рассказал. Эффект потрясающий!
Попробую
VR
Ну как. Протестированно должно быть то - что не должно меняться.
Начать с того что дольше всего / сложнее всего протестировать руками. (Ну как вы в скраме пытаетесь доставить наибольший value заказчику в самом начале, так и тут попытаться доставить самый больший value для тестировщиков.)
У нас тесты делятся на 4 типа: юнит тесты, интеграционные тесты (написанные программистами), автотесты бекенда с помощью postman'a, полные автотесты с помощью selenium'a
Начать с того что дольше всего / сложнее всего протестировать руками. (Ну как вы в скраме пытаетесь доставить наибольший value заказчику в самом начале, так и тут попытаться доставить самый больший value для тестировщиков.)
У нас тесты делятся на 4 типа: юнит тесты, интеграционные тесты (написанные программистами), автотесты бекенда с помощью postman'a, полные автотесты с помощью selenium'a
Почему протестировано должно быть то, что не должно меняться?
YS
Почему протестировано должно быть то, что не должно меняться?
Я прочитал как то, что раньше сделано и автотестировать чтобы проверять не сломали ли при разработке нового)
VR
Всем привет!
Подскажите, по одному заурядному вопросу :) кто автоматизировал тестирование?
С чего начать? В какую сторону смотреть?
Хотим у себя в двух командах внедрить автотесты. Пока на этапе исследования, что к чему, кто делал в компании, и за пределами, и вообще с чего начинать.
Подскажите, по одному заурядному вопросу :) кто автоматизировал тестирование?
С чего начать? В какую сторону смотреть?
Хотим у себя в двух командах внедрить автотесты. Пока на этапе исследования, что к чему, кто делал в компании, и за пределами, и вообще с чего начинать.
Я бы рекомендовал начать с юнит тестов.
Быстро придете к проблеме, что что-то покрыть тестами просто, а что-то сложно. Упрётесь в понятие тестируемости. От этого понятия идите в SRP и DI.
Затем можете прийти к вопросу - а сколько надо тестов? Насколько глубоко копать с вариациями тестов? Тут можете попробовать найти связь с бизнес-требованиями. Делать только те тесты, которые соответствуют требованиям. Понятно, что на уровне отдельных классов эту связь найти может быть непросто, но размышления на этот счет, в любом случае, помогут сделать тесты более сфокусированные на том, что нужно бизнесу и клиентам, а не на фантазиях разработчика. Держите QA в фокусе - они хотят написать как можно больше тестов на любой пшик. А, между прочим, тесты это код, который надо поддерживать. Ищите баланс между количеством тестов и количеством багов.
При размышлении на тему связи тестов и требований может возникнуть желание сначала писать тесты, ведь требования уже есть, значит и какие тесты надо писать должно быть понятно до начала разработки.
Быстро придете к проблеме, что что-то покрыть тестами просто, а что-то сложно. Упрётесь в понятие тестируемости. От этого понятия идите в SRP и DI.
Затем можете прийти к вопросу - а сколько надо тестов? Насколько глубоко копать с вариациями тестов? Тут можете попробовать найти связь с бизнес-требованиями. Делать только те тесты, которые соответствуют требованиям. Понятно, что на уровне отдельных классов эту связь найти может быть непросто, но размышления на этот счет, в любом случае, помогут сделать тесты более сфокусированные на том, что нужно бизнесу и клиентам, а не на фантазиях разработчика. Держите QA в фокусе - они хотят написать как можно больше тестов на любой пшик. А, между прочим, тесты это код, который надо поддерживать. Ищите баланс между количеством тестов и количеством багов.
При размышлении на тему связи тестов и требований может возникнуть желание сначала писать тесты, ведь требования уже есть, значит и какие тесты надо писать должно быть понятно до начала разработки.
VR
Потом предложил бы почитать BDD in action и specification by example.
Часто достаточно всего двух типов тестов - юнит и функциональных.
Часто достаточно всего двух типов тестов - юнит и функциональных.
VR
Причем, в specification by example рекомендуют не делать тесты на UI, либо делать их отдельно от проверки функций.
Потому что тесты UI - долгие и изменчивые. Их сложно поддерживать и лень прогонять.
Потому что тесты UI - долгие и изменчивые. Их сложно поддерживать и лень прогонять.
NK
Я бы рекомендовал начать с юнит тестов.
Быстро придете к проблеме, что что-то покрыть тестами просто, а что-то сложно. Упрётесь в понятие тестируемости. От этого понятия идите в SRP и DI.
Затем можете прийти к вопросу - а сколько надо тестов? Насколько глубоко копать с вариациями тестов? Тут можете попробовать найти связь с бизнес-требованиями. Делать только те тесты, которые соответствуют требованиям. Понятно, что на уровне отдельных классов эту связь найти может быть непросто, но размышления на этот счет, в любом случае, помогут сделать тесты более сфокусированные на том, что нужно бизнесу и клиентам, а не на фантазиях разработчика. Держите QA в фокусе - они хотят написать как можно больше тестов на любой пшик. А, между прочим, тесты это код, который надо поддерживать. Ищите баланс между количеством тестов и количеством багов.
При размышлении на тему связи тестов и требований может возникнуть желание сначала писать тесты, ведь требования уже есть, значит и какие тесты надо писать должно быть понятно до начала разработки.
Быстро придете к проблеме, что что-то покрыть тестами просто, а что-то сложно. Упрётесь в понятие тестируемости. От этого понятия идите в SRP и DI.
Затем можете прийти к вопросу - а сколько надо тестов? Насколько глубоко копать с вариациями тестов? Тут можете попробовать найти связь с бизнес-требованиями. Делать только те тесты, которые соответствуют требованиям. Понятно, что на уровне отдельных классов эту связь найти может быть непросто, но размышления на этот счет, в любом случае, помогут сделать тесты более сфокусированные на том, что нужно бизнесу и клиентам, а не на фантазиях разработчика. Держите QA в фокусе - они хотят написать как можно больше тестов на любой пшик. А, между прочим, тесты это код, который надо поддерживать. Ищите баланс между количеством тестов и количеством багов.
При размышлении на тему связи тестов и требований может возникнуть желание сначала писать тесты, ведь требования уже есть, значит и какие тесты надо писать должно быть понятно до начала разработки.
Спасибо огромное!
Мы как раз начали с юнит тестов, и часть вопросов уже поднялась.
Сейчас команду усиливаем компетенциями тестирования (раньше это было выделенное подразделение) и в команде поднялся вопрос о том как его автоматизировать, что делать и с чего начинать.
Раз они готовы сами пилотировать эту историю, то нужно им помочь.
Ещё раз спасибо за ответ, я бы даже сказала - чек лист!
Мы как раз начали с юнит тестов, и часть вопросов уже поднялась.
Сейчас команду усиливаем компетенциями тестирования (раньше это было выделенное подразделение) и в команде поднялся вопрос о том как его автоматизировать, что делать и с чего начинать.
Раз они готовы сами пилотировать эту историю, то нужно им помочь.
Ещё раз спасибо за ответ, я бы даже сказала - чек лист!
IS
Почему протестировано должно быть то, что не должно меняться?
Ну как, у вас есть два основных кейса. Вы сделали функционал, и он важный, и ваши пользователи будут недовольны если он сломается. Поломка, это соответственно изменение. Значит, что бы пользователи были довольны, перед выпуском релиза такой функционал надо протестировать.
При этом, можно предстаить себе ситуацию, что вы не меняли конкретно этот функционал, но из за того что поменяли какой-то соседний функционал, обновлили библиотеки, поменяли инфраструктуру, etc, этот функционал все равно может сломаться. (То есть мысль в том, что сломаться может вообще любой функционал).
Второй вариант: вам не важно сломается ли функционал или нет. Например при разработке прототипа. Ок, тогда можно и не тестировать.
При этом, можно предстаить себе ситуацию, что вы не меняли конкретно этот функционал, но из за того что поменяли какой-то соседний функционал, обновлили библиотеки, поменяли инфраструктуру, etc, этот функционал все равно может сломаться. (То есть мысль в том, что сломаться может вообще любой функционал).
Второй вариант: вам не важно сломается ли функционал или нет. Например при разработке прототипа. Ок, тогда можно и не тестировать.
IS
По поводу того, что сломаться может все что угодно:
VR
Ну как, у вас есть два основных кейса. Вы сделали функционал, и он важный, и ваши пользователи будут недовольны если он сломается. Поломка, это соответственно изменение. Значит, что бы пользователи были довольны, перед выпуском релиза такой функционал надо протестировать.
При этом, можно предстаить себе ситуацию, что вы не меняли конкретно этот функционал, но из за того что поменяли какой-то соседний функционал, обновлили библиотеки, поменяли инфраструктуру, etc, этот функционал все равно может сломаться. (То есть мысль в том, что сломаться может вообще любой функционал).
Второй вариант: вам не важно сломается ли функционал или нет. Например при разработке прототипа. Ок, тогда можно и не тестировать.
При этом, можно предстаить себе ситуацию, что вы не меняли конкретно этот функционал, но из за того что поменяли какой-то соседний функционал, обновлили библиотеки, поменяли инфраструктуру, etc, этот функционал все равно может сломаться. (То есть мысль в том, что сломаться может вообще любой функционал).
Второй вариант: вам не важно сломается ли функционал или нет. Например при разработке прототипа. Ок, тогда можно и не тестировать.
Да, понятно.
Просто тесты часто воспринимаются как способ сделать изменения проще. Есть тесты - не боишься менять. Если речь только о поломках, то да. Если речь именно про зафиксированную функциональность, то скорее нет.
Просто тесты часто воспринимаются как способ сделать изменения проще. Есть тесты - не боишься менять. Если речь только о поломках, то да. Если речь именно про зафиксированную функциональность, то скорее нет.