тогда странно)) там же и примеры в коде есть

О, так я вроде читал эту статью пару лет назад

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

Писать код я конечно буду как и раньше ;)

https://www.youtube.com/watch?v=PJjHfa5yxlU

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

?

я считаю, что вся эта терминология – буллшит бинго

стабы, моки – это все круто

запоминать разницу я конечно же не буду

Ну кстати яркий пример - это то что у Фаулера называется Spy - объект который в себе счетчики содержит. Можно 10 лет городить такие объекты со счетчиками и анализаторами, подсовывать их в тестах и прекрасно жить, и умереть даже не зная что это оказывается называется *Spy* ?

миллион плюсов :)

да, можно как в анекдоте на заводе изъясняться х..нами и п..нами. А что, всё равно ж все поймут

Поинт в том, что problem solving в рамках языков решается практиками. Практики находят жизнь в библиотеках, паттернах и прочих вещах.

Высокоуровневая теория - зачастую переопределяется в имплементациях каждого языка

каковы шансы что человек будет цитировать Фаулера чаще, чем библиотеку по этому линку? http://www.rubydoc.info/gems/rspec-mocks/frames малы. Потому что нужно быть down to earth.

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

примерно вот так

Ну если допустим расти в семье потомственных QA, то там может и трудно будет общаться без знания мока.

Паша, посмотри видео

Ок. Я смотрю postal сейчас ;)

там Сэнди годноту палит насчет того, что сейчас модно через DI тестировать

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

Ну, так я через DI и тестирую всю жизнь

А разве для ruby это актуально? Я слышал что там другой принцип подмены

код после рефакторинга, добавлен optional argument model, где передаем в него Sale. в кач-ве di можно передать и Totalizable item который будет возвращать нам что-то (якобы имитируя запрос в БД)

подскажите, пожалуйста, где можно блок-схемы удобно рисовать?

подскажите, пожалуйста, где можно блок-схемы удобно рисовать?

Draw.io

google draw.io

Всех приветствую! А вакансии здесь разрешено размещать?

Всех приветствую! А вакансии здесь разрешено размещать?

@qa_jobs - туда.

Благодарю

Всем привет! Посоветуйте​, пожалуйста, где почерпнуть практический опыт по тестированию клиент серверной архитектуры, инструменты может какие. Так как теоретические знания и понимание есть, а вот на практике кроме консоли ничего не знаю? Тапками прошу не кидаться. Всем спасибо заранее?

А вам прям архитектуру надо тестировать?

пойти на стажировку куда-нибудь.

А вам прям архитектуру надо тестировать?

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

Ну как минимум можно поюзать Fiddler

советую написать любой сайт , хоть на котором будет просто 1 фраза из базы

сразу поймёте как это работает

Ребзя, а посоветуйте плиз. Задание выбрать окружение для багтрекинга+тест кейсов+реквайрементов/юзер стори. Полностью покупать джиру нельзя, дорого.

TargetProccess.

Он прям отличненький.

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

мне редмайн нравится

TargetProccess.

Прям супер? Дороже чем жира говорят.

Мне таргет процесс понравился категорически.

Прям супер? Дороже чем жира говорят.

+

Это самый удобный из трекеров, с которыми я работал.

Это самый удобный из трекеров, с которыми я работал.

Слышал похвальбы, к сожаленю не пробовал. Там вроде уже есть функциональность TestRail'a Кейсы, Планы, это все

Слышал похвальбы, к сожаленю не пробовал. Там вроде уже есть функциональность TestRail'a Кейсы, Планы, это все

Да. Тесты, планы, раны, вот это все

Прям супер? Дороже чем жира говорят.

Тормозит и глючит как жира тоже.

Ну, я не ковырял их апи, поэтому не могу сказать на сколько они конкурент тестрейлу.

Но в целом выглядит приятно и кастомизируемо.

Плюс поддержка годная.

(не аффилирован с этими ребятами, за идею топлю)

Testrail, basecamp, redmine? Что скажете?посоветуйте, коллеги)

есть что нибудь годное типа зефира, но лучше/дешевле или бесплатное/функциональнее и не глючная, с jira кроме Testrail

ERROR: S client not available

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

Омг. Багзилла! Попробуй редмайн

Бейскемп - это ужасная вещь. Просто вычеркни её из лексикона.

а у нас все на gitlab + testrail по удобству и функционалу тоже хватает

а у нас все на gitlab + testrail по удобству и функционалу тоже хватает

спс

Бейскемп - это ужасная вещь. Просто вычеркни её из лексикона.

Просто ты не ПМ, не продакт

Просто ты не ПМ, не продакт

И? Тут просят для продакта что-то подыскать?

Ну для чего-то же человек описал в списке бейзкамп

К тестированию он имеет очень отдаленное отношение

Всем привет. Вопрос есть. Есть например критический дефект и несколько не критических. На момент исправления критического дефекта уже как раз исправили и не критические дефекты. Будете ли вы включать не критические дефекты при отправке критического дефекта в патче?

Лучше отдельно

Ведь не критические могут ещё 10 раз вернуться разработчику

И это может затянуться, а критический баг не может ждать

Так все уже пофиксили и лежит на полке

Всем привет. Вопрос есть. Есть например критический дефект и несколько не критических. На момент исправления критического дефекта уже как раз исправили и не критические дефекты. Будете ли вы включать не критические дефекты при отправке критического дефекта в патче?

Если все уже оттестировано и готово, в тч билд куда вмержены все эти правки, то почему нет? Немного странная постановка вопроса, если честно.

Если не проверено, это не значит что пофикшено

И даже если проверено , я бы катил бы отдельно

Ну вот я своему лиду тоже так говорю, что если все проверено почему не отправить

А если надо будет откатить, если надо будет ещё фикс , лучше потушить пожар, а только после этого катить что угодно

На что получаю ответ, что в патчи должны входить только критические дефекты

Я считаю лид прав

Ну еще от severity дефекта зависит, конечно.

лид прав, т.к. план релиза - это план релиза

Критические фиксы отдельно от просто задач

нет никакого поинта в том, чтобы мержить к критической правке другие фича-бранчи.

На что получаю ответ, что в патчи должны входить только критические дефекты

Я думаю, это ваши локальные методики. Сложно судить о сферическом коне в вакууме.

Я думаю, это ваши локальные методики. Сложно судить о сферическом коне в вакууме.

Да в любой методике не надо их смешивать

в случае с веб-приложением: если у вас деплой фич является пофичным, т.е. вы можете нажать одну кнопку - и одна фича-ветка улетит на бой, и избавит вас от бага - то вопрос отпадает сам собой - фикс бага будет поставляться независимо от других фич. если же у вас "собирается" раз в N время ветка-кандидат с кучей фич, то для критического бага подмерживать в ветку с багом якобы протестированные фичи - это такое себе.

в случае с веб-приложением: если у вас деплой фич является пофичным, т.е. вы можете нажать одну кнопку - и одна фича-ветка улетит на бой, и избавит вас от бага - то вопрос отпадает сам собой - фикс бага будет поставляться независимо от других фич. если же у вас "собирается" раз в N время ветка-кандидат с кучей фич, то для критического бага подмерживать в ветку с багом якобы протестированные фичи - это такое себе.

Всё правильно описал, поддерживаю