P.S.

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

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

 

 

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

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

 

 

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

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

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

 

 

Знаешь, что. Реши ка для начала задачу Голдратта: https://tocpeople.co...-stoga-sena-12/

таймшиты это не про планирование ведь, таймшиты это про учёт уже потраченного времени

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

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

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

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

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

У нас решали такую проблему просто. В спринте у каждого был таск Overhead, куда легально можно было списывать до часа в день. Если за день набегало больше часа времени на всякое "активность незапланированная в спринт" (от "комп тупил, админы смотрели" до "внезапно пришлось делать рисёч, который сложно привязать к продуктовой задаче"), то приходилось заводить отдельную таску и списывать туда. Но случалось редко, на коммоновые задачи часа в день хватало.

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

 

 

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

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

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

 

 

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

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

 

 

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

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

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

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

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

 

 

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

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

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

 

 

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

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

 

 

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

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

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

 

 

Почему?

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

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

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

 

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

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

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

 

 

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

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

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

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

 

 

ISTQB вообще не учит, с чего начинать тестирование.

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

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

 

Почитайте силлабусы для Advanced.

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

ну открыл например Адвансд Техникал Аналист, то же самое что и в фаундейшн:

пункт "1.5.2 Creation of Test Cases"

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

 

 

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

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

 

Мы прожили без тест кейсов и без планирования тестирования 6 месяцев в следствии реорганизации команды и компании в целом. В результате я месяц разгребаю, описываю и систематизирую новый функционал, перерабатывая в будни и по выходным периодически. И конца и края этому не видно. А всё потому что тест кейсы не делались на функционал который был не приоритетный, а потом он неожиданно стал приоритетный. И оказалось что там миллиард багов, а новые разработчики вообще не понимают, как что работает. Как по мне, да же если у нас аджайл, и что иногда нам нужно например:

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

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

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

3. Человеческий фактор никто не отменял. Я давеча проводя "исследовательское" тестирование, после двух недель переработок пропустил на прод абсолютно банальный баг с неправильным суммированием в столбце "итого". Просто не заметил/забыл посмотреть/хз что ещё..и всё. При тестировании расчетов верить нельзя да же самому себе. 

Да же если у вас лендинг с 5тью кнопками и чисто визуальным JSом, всё равно хотя бы единожды написать подробные тест кейсы надо, да же если на их поддержку потом забьют. 

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

 

 

"завтра выкатываем, забей на регресс"

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

 

 

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

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

 

 

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

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

 

 

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

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

 

 

3. Человеческий фактор никто не отменял. Я давеча проводя "исследовательское" тестирование, после двух недель переработок пропустил на прод абсолютно банальный баг с неправильным суммированием в столбце "итого". Просто не заметил/забыл посмотреть/хз что ещё..и всё. При тестировании расчетов верить нельзя да же самому себе. 

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

 

Да же если у вас лендинг с 5тью кнопками и чисто визуальным JSом, всё равно хотя бы единожды написать подробные тест кейсы надо, да же если на их поддержку потом забьют. 

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