Кто на тестатрон в Питере в 9 октября идёт?

/me

Сколько там вход стоит?

Бесплатно, но там через регистрацию и некий алгоритм отбора людей

Как завуалировано постель обозначили..

И кто 8 в Москве?) с удовольствием узнал бы заранее что да как

привет. Знакомое имя, на ПМе учился?) На сайте у них сказано так - приходишь, разбиваетесь по командам, соревнуетесь тестируя два приложения с перерывом на обед. В конце небольшой разговор с командой организаторов (не лекция, просто диалог) и раздача призов

Кто на тестатрон в Питере в 9 октября идёт?

Расскажите потом, как прошло. И как отбирали людей для участия)

https://media.giphy.com/media/l0HlMEaEqFC4eLXtC/giphy.gif

А вот в моей компании DevOps к отделу тестирования как отец родной - он бывший глава отдела нагрузочного тестирования. И недавно сманился на работу в Черногорию. До си пор всем отделом сидим завидуем.

Меня прям ломает каждый раз, когда вы людей называете Девопсами =)

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

Ну все уже смирились с "тестерами"

С девопсами будет такая же история

К вопросу о девопсах, может быть будет кому-то интересно - небольшой обзор докладов на предстоящей конференции "Linux Piter #2", где будет, в частности, и про девопс: https://habrahabr.ru/company/emc/blog/311614/

а что делать, если в девопс-процессе работает 5 человек? 2 кодера + 1 аналитик + 2 админа? кто из них девопс? )))

никто)

потому что девопс - это не человек

ессесно

и его нельзя захайрить )))

это как говорят "эджайл-команда" или "скрам-команда" - хочется взать и ууууууу

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

#whois Каланов Денис / Руководитель портала IT-Events.com / Санкт-Петербург Освещаем разные событие в IT-сфере, знаю обо всех (или почти обо всех) событиях IT-сферы Рунета. Не помню как я узнал о группе )

разработчик- это любой человек, учавствующий в разработке

т.е. он же будет решать вопросы автоматизации процессов, а именно CI, CD будет на нем, та же infastructure as code тоже

developer

но программист может писать тесты, что может делает его тестировщиком, а может и нет

такая формулировка устроит?

нет, я девелопер, моя позиция qa manager, если кто скажет, что я не девелопер, тому задевелоплю вынос мозга

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

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

да лааадно, кому должен?

потому что в большей степени компетенции программиста не хватит, чтоб гарантировать тестовое покрытие 100%

потому что в большей степени компетенции программиста не хватит, чтоб гарантировать тестовое покрытие 100%

даже компетенции боженьки не хватит )))

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

все зависит от бюджета приложения и компании

ну наааасть, ну что за замшелые мифы из 90-х?

никто ничего никому не должен

привет всем

будек кастомер платить - все будут сидеть и писать. не будет - не будут писать

простая политика :)

Ром, ну давай, разубеди меня =) Я проводила эксперимент, когда разработчик (крутой разработчик) сам проектировал свои тесты. НО он все-равно упускал крайние случаи, потому что как показывает практика, мало кто из разрабов просто даже взял и читал книгу Шаблоны X-Unit.

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

просто когда я писала код, незаметно для себя стала пропускать многое, что находила как тестеровщик :)))

есть такие тестеры, их ещё называют QA - они умеют техники тест-дизайна применять при проектировании ТМ =))

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

я тестирую 12+ лет, я знаю всё про тестирование msi пакетов всё вот что можно знать на уровне клиентских пакетов - я такую упоротую багу пропустил, что уже вторую неделю смешно

прям вот в лоб провтыкал

Коля Алименков с крутым докладом на эту тему выступил на QAFest =)

У всех свои недостатки Ром, ты не печалься

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

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

И вообще мы разговаривали про DevOps) смотри, что я хочу собственно сказать. Исключительно на примере тех проектов, в которых я работала. Как правило роль devops-инженера берет в скрам-команде на себя разработчик. Потому что тому же самому QA или аналитику, может не хватит компетенции, чтоб автоматизировать все процессы деплоя. Но вот QA, который руками может тестить и автоматизировать свои же тесты - вполне себе. А аналитик - вместо того чтоб писать документацию в стол, может работать в паре с разработчиком и QA и документацию готовить сразу в формате Specification of Example, тем самым автоматизируется и процесс написания документации

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

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

А никто про test coverege =100% и не говорил. Во-первых это слишком относительно, а во-вторых это не выгодно для Бизнеса. И вот тут роль QA и заключается в том, чтоб выработать подход подсчета минимального необходимого покрытия. К примеру у меня на проекте, мы рассчитываем согласно методологии RUP (упрощенная версия) Рисуется граф требований и на каждую ветку требований не менее двух сценариев ( 1 положительный, 1 отрицательный) Это минимум)

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

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

хочешь поговорить об этом?

неа

вот и правильно ?

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

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

это вопрос скилла - не хочет никто и не учит )))

Кто такая Анастасия? Она столько умных девопсовых терминов знает, я в шоке.

Работает в Альфа лаборатории, лид команды автоматизации

По крайней мере ФБ так сказал

А ну тогда все ясно

Кто нибудь сталкивался когда работал с гос.заказчиками с такими понятиям как ПМИ ПМУ итд?

ну не обязательно работать с госзаказчиками...

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

И впечатления были не из приятных

ERROR: S client not available

Всех этих формальностей и бумажек

мы работаем с крупными компаниями, в т.ч. частными. раньше заказчики хотели формальное ПМИ на "отвали".

но... знаете, мы их приучили. они сами заинтересовались в хорошем ПМИ.

а потом на наших проектах поменялся менеджер со стороны заказчика

и теперь у нас... бумага бумага бумага

заказчик сам щупает руками и понимает как с этим работать - мы меньше тратим времени на объяснения теперь :)

но... знаете, мы их приучили. они сами заинтересовались в хорошем ПМИ.

Ну аналогичная ситуация , но мне кажется есть более современные методы решения этого вопроса , например конференция , прямой контакт со специалистом который проходит ПИМ это затягивает процесс и дико неприятное и рутинное явление только ещё печатной машинки не хватает как в 90х

так всё равно же должны проходить различные ПСИ, ИФТ и пр., по заданным и согласованным программам/методикам

К примеру бывало вот как кидаешь пим заказчиков штук 8 из 8ми 4 ро как правило пришлют что то вроде "пункт 5.1" не смогли выполнить требуется пояснение и вооот это все затягивается на месяцы

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

Есть классные заказчики которые шарят в продуктах и ещё по мимо пми своих кейсов накидают не спорю

К примеру бывало вот как кидаешь пим заказчиков штук 8 из 8ми 4 ро как правило пришлют что то вроде "пункт 5.1" не смогли выполнить требуется пояснение и вооот это все затягивается на месяцы

странные у вас заказчики. а может у них политика партии такая. у нас они сами нацелены на ввод в эксплуатацию, но не просто так - чтоб еще и всё работало.

Есть классные заказчики которые шарят в продуктах и ещё по мимо пми своих кейсов накидают не спорю

вот у нас такие ;) они и на наших тестовых данных прогонят, и на реальных (на всякий случай - реальные данные с прома не всегда дают, либо зашумляют сильно)

странные у вас заказчики. а может у них политика партии такая. у нас они сами нацелены на ввод в эксплуатацию, но не просто так - чтоб еще и всё работало.

Ну это все в далеком прошлом и я глубоко надеюсь что это скоро исчерпает себя , т.к уже третий год работаю в норм конторах СОВРЕМЕННЫХ без всех этих бумажек и Слава Аллаху это блаженство

Клянусь ?

Ну это все в далеком прошлом и я глубоко надеюсь что это скоро исчерпает себя , т.к уже третий год работаю в норм конторах СОВРЕМЕННЫХ без всех этих бумажек и Слава Аллаху это блаженство

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

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

Не спорю для кого то норм стабильность и все такое

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

Мне кажется там и по сей день пишут Пимы и юзают QC который работает только в IE и ещё 10 лет будут использовать

Не спорю для кого то норм стабильность и все такое

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

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

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

Мне кажется там и по сей день пишут Пимы и юзают QC который работает только в IE и ещё 10 лет будут использовать

вот мы и юзаем qc, всё думаю сподвигнуть контору на переход чего-либо более адекватного и интегрированного в джиру.

вот мы и юзаем qc, всё думаю сподвигнуть контору на переход чего-либо более адекватного и интегрированного в джиру.

Красава стой на своём ?

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

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

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

+ какая контора не подскажете )? Ни СПб случайно )?

головная в Мск(поеду повторно знакомиться в декабре + знакомиться с заказчиками + встретиться с бывшими заказчиками — по личной инициативе, за свои бабки). центры разработки - в Спб, НН, Воронеже, Уфе, Перми, Екатеринбурге, Красноярске...

кстати, совет тем, кто работает в заказной разработке. по возможности - знакомьтесь с заказчиками. отношение к вам и компании меняется. плюс хорошие отношения на будущее - мир тесен ;)

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

Зачастую да этого не хватает , каких требований документации , но есть взвесить все плюсы и минусы это очень трудозатратный процесс , тем временем как заниматься писаниной , можно делать куча нового и интересного , я считаю что такой процесс как раз и настроен на специалистов , которые впринципе готовы сидеть и не рыпаться по 5-10 лет и это вполне удовлетворяет компании такого рода , с другой стороны никто не держит да , но в целом икспа качается больше в командах где подход немножко другой , ну это я на своём опыте говорю

Зачастую да этого не хватает , каких требований документации , но есть взвесить все плюсы и минусы это очень трудозатратный процесс , тем временем как заниматься писаниной , можно делать куча нового и интересного , я считаю что такой процесс как раз и настроен на специалистов , которые впринципе готовы сидеть и не рыпаться по 5-10 лет и это вполне удовлетворяет компании такого рода , с другой стороны никто не держит да , но в целом икспа качается больше в командах где подход немножко другой , ну это я на своём опыте говорю

не спорю, но у нас всё стандартизировано. более менее. а если нет - то стандартизируем. пишем сами регламенты, вносим изменения - чтобы действия у всех были одинаковы и (гребцы на галере) команда работала слаженно

не спорю, но у нас всё стандартизировано. более менее. а если нет - то стандартизируем. пишем сами регламенты, вносим изменения - чтобы действия у всех были одинаковы и (гребцы на галере) команда работала слаженно

Сколько человек в отделе ?

@chebotarevp я создатель этого чатика =) ну и плюс devops евангелист в Альфа Банке, внедряю с командой devops в Банке.