2. Зачем для бухучета вид задач выполняемых сотрудником. Я понимаю нежелание оплачивать задачу вида "пил пиво", но дальше то оплата идет за работу в целом же? Поднимал я сервер или читал доки - все равно зп будет одна. Еще деление по проектам понимаю - разные бюджеты. 

"в целом" наверное только в самом простом варианте в самой простой фирме

 

 

Еще деление по проектам понимаю - разные бюджеты. 

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

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

 

 

Повторюсь. Списывается время на проект. Против этого я ничего не имею. Но не стоит в рамках каждого проекта расписывать типы выполняемых задач. 

возьмем к примеру тайм-трекинг в Джире+Темпо: есть проекты, в проектах есть тикеты, на тикетах аккаунты

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

для тестера либо разраба (или любого другого сотрудника) все просто и прозрачно: взял с доски тикет в работу, после ввел время на этот тикет (ну или тракер конвертировал) - вот и делов то

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

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

 

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

1) В таймшитах вранье. Это очень хороший вариант.

2) В таймшитах правда. Вот это полная задница для фирмы.

 

И есть промежуточные варианты. Там есть вранье и задница.

"правда" или "враньё" зависит от точки зрения

например день тестировщика:

1 час с утра поднимал сервер

2 часа тестировал фикс старого бага, который зарепортил клиент

2 часа не было тикетов и читал доки по следующему проекту

1 час на обеде пил пиво и играл в настольный футбол с коллегами

1 час тестировал тикет по новому функционалу

1 час читал книжку по джаваскрипту

это всё вводится в таймшит как:

5 часов по тикету багфикса

3 часа по тикету про новый функционал

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

P.S.

а выдачу премий вообще надо запретить, а выдавать всем 13ю зарплату, либо зп повысить всем

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

 

 

Дурдом, тчк. 

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

а дурдом это когда "просто все работают" и заполняют сразу по 40 часов

 

 

Spock, поправь, ты же про аутсорс говоришь?) Они же по артефактам работают - производственные и непроизводственные, плюс SLA. 

не аутсорс. компания западная, не знаю как считают это в странах Восточной Европы
 

http://finvopros.com...8212_OPEX_CAPEX

капитальные и операционные расходы

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

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

 

 

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

ну а так почему заходим на третий круг? потому что даже в такой ситуации непонятно куда надо заводить простои типа "пил пиво и играл в приставку", и ведь это аукнется если кто-то реально начнёт "честно" вводить своё время. Для понимания загрузки нужно как-то анализировать например эджайл доски

 

 

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

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

 

 

Вот у нас в одном проекте таймшиты использовались для рассчета с заказчиком. Только в них нет тикетов, в них есть типы работ. и мы тупо раз в неделю вписываем 38 часов в "sprint work" и 2 часа в "Spikes, POCs". те самые capitals и expenses. То есть, если я играл в плойку в офисе потому что тикетов не подвезли - это 8 часов, а если болел или в отпуске был, то это 0.

это хорошо что у Вас так стабильно было "38+2", поэтому могли так вводить. но во многих случая реально нет такого стабильного отношения, и в одно время работа идёт 80% на поддержку, а в другое 80% на разработку, плюс разные проекты иногда накладываются, поэтому получается ещё веселее типа "60+30+10" или "40+20+30+10"

 

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

А в каком месте в таймшитах "все-таки правда" я категорически не понимаю.

 

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

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

вот это "пиво" и этот "сервер упал" и "читал доки по следующему проекту" и "копался в джире" - не вводятся нормально в таймшиты, приводят только к нервным стрессам и срывам, и недополучению заслуженной премии

бывают менеджеры которые пытаются заниматься микро-менеджментом времени сотрудника через таймшиты - но ни один из них не сможет внятно объяснить сотруднику как вот это всё в какие тикеты поместить

 

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

Фишка в том, что измерять таймшитами надо не сотрудника, а процессы. Тогда и решения автоматически будут приниматься и применятся не к сотрудникам, а к процессам. Тогда и  сотрудники в таймшитах врать не будут.

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

в рабочем дне 8 часов, но эффективных часов там 6 - так как 2 уходят на организацию работы, собрания, переговоры, документацию и просто всё подряд

поэтому и нереально ввести 6 эффективных часов в 8 часов рабочего времени

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

навыки навыками, но ведь главное это какой именно вклад Вы сможете сделать на данной вакансии

Матрица? все части

вот что бывает когда в гите и пайплайнах абсолютно не хочется разбираться, а вот зарплата на позицию очень нравится

 

 

И потеряете хорошего начинающего кандидата только из-за того, что он не знает терминов?)

это просто для оценки кандидата, чтобы определить "начинающий" он или "продолжающий"

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

да и тут не в терминах же смысл, а в понимании пайплайна

а вообще это хорошая идея кандидатов отсеивать

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

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

и смотришь как тот выкрутится :)

 

 

Тестируйте сайт той организации, куда хотите на стажировку.

маленькая подсказка: только не говорите им потом про найденные баги

 

 

"Сначала возьмите, а потом скажу?"  

и тогда молчать тоже

пока не поймёте что это не нужно и не важно

я вот этот проходил, но их много, и на русском есть

https://docs.docker.com/get-started/

 

 

Можете потестировать прямо тот сайт, на котором сейчас находитесь — software-testing.ru

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

вообще внешние сайты это неподконтрольное ПО, на таком и тестировать никогда не научишься

 

 

личные кабинеты

не интернет банков, не государственных контор :)

 

 

Если я правильно понял, то вы предлогаете скачать готовый веб-проект и чтобы я установил его у себя на ПК?

вообще наверное предлагаю пройти туториал по докеру, это займёт 4 часа

получите кучу нужных знаний

 

 

Почему?

ну научишься кликать на кнопочки и проверять ошибки в текстах и находить какие-то невыровненные элементы, и что?

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

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

 

человек хочет на стажировку. Хочет найти сайты для тестинга.

А умение "кликать по кнопкам" лучше, чем ничего

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

 

 

Спасибо большое, я вас услышал. Теперь осталось у кого-то админку выцепить :D

можно разложить веб-аппликацию у себя на машине например, ну или лучше в AWS облаке, и тестировать ее

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

ищите веб-аппликации которые сразу упакованы в докер

почитал их сайты и разобрался что к чему:

https://www.rstqb.or...tification.html

вот он, путь сертификации: 

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

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

все остальные курсы основаны опять же на водопадной модели, как и первый сертификат

вот и проблема: 

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

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

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

Этот сертификат "Тестирование в гибких методологиях" по факту должен быть объединён с "Сертифицированный тестировщик" и быть одним входным сертификатом

 

Ок, предположим, что мы идём к чувакам из ISTQB, кладём их всех на пол и начинаем их судить:

 

— Вы утверждаете, что начинать тестирование надо начинать именно с написания тест-плана и тест-кейсов, а потом конечно, гоу-гоу на выполнение этих тест-кейсов.

 

— Ну, здравый смысл же… Сперва вымой руки, затем садись за стол…

 

— Но ведь всё поменялось! Теперь ведь:

(1) вместо тест-планов есть спринт-рефайнмент,

(2) вместо тест-кейсов — чек-листы и исследовательское тестирование,

(3) вместо ручной регрессии — автоматизированные тесты.

(4) Тест-менеджеров и тех практически не осталось! Пора уже принять современные реалии.

 

И вот здесь я не согласен. Ничего не поменялось. Спринт-рефайнмент что, отменяет тестирование? Исследовательское тестирование что, отрицает тест-кейсы? Автоматизация что, решает проблему регресса? Автоматизация, кстати, чего именно?  Функциональных тестов? Юнит тестов? Аджайл что, отменяет/заменяет установки "традиционной модели" (она же "водопадная", она же Соня Канцельбоген, воровка на доверии и особа, приближённая к императору)?

 

И если ответы будут «Да!», то мне сейчас, глядя на лежащих на полу чуваков из ISTQB, придётся признать, что мой собрат не понимает того, чем он занимается, и несёт в эфир белиберду белиберденьскую, бо его, походу, укусил какой-то дурак с неправильным аджайлом. Придётся извиняться перед этими чуваками.

 

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

 

Понятно ли я говорю?

очевидно что пост номер 7 вверху так и не прочитали:

https://software-tes...khomu/?p=174614

эджайл от водопада между прочим сильно отличается. По водопаду мы получаем софт на тестирование, составляем тест-план и начинаем писать тест-кейсы, тестируем только после того как написали кейсы. Всё в порядке водопада

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