?

У нас вон play station стоит в офисе. Если люди за ним отсиживают овертайм - считать за переработку?)

Зависит от того, как работодатель считает рабочее время.

(а по законодательству он обязан это делать, если что)

Если тупо по нахождению в офисе - то да, это овертайм. :)

А у кого как трекается?

Скуд обычно

Или по звонку как в ссср

У нас есть чеклист для суппорта и ко-ко-ко, которые работать не хотят. Господам разработчикам просто по дефолту ставится 8 часов, сколько бы они не работали.

А так, у всех по разному. Кто-то время в джире трекает, например. :D

Скуд обычно

У нас скуд для контроля нахождения в офисе. Далее есть таймшитики и траты времени в джире.

Работаешь дома или у заказчика - отмечаешь это.

У нас сейчас стартап и на честном слове + под контролем Тим лидов.

У нас сейчас стартап и на честном слове + под контролем Тим лидов.

Это работает не только в стартапах, а в любой адекватной команде, на самом деле.

Обычно сидят дольше положенных 8 часов, ибо условия создали в офисе располагающие

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

Это работает не только в стартапах, а в любой адекватной команде, на самом деле.

+

Есть спринты и релизы. Там видно какая команда не тянет )

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

Поддерживаю. Ну и эстимейты, траты должны быть адекватными.

Ну, это подразумевается под "всех всё устраивает".

Ага

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

Имхо для QA переработки не свойственны так, как для девелоперов

Имхо для QA переработки не свойственны так, как для девелоперов

Ахахаха

Но, вообще, да. Больше восьми часов работать глупо.

Имхо для QA переработки не свойственны так, как для девелоперов

На их переработки, сдвиги/съезды сроков QA также подвязаны. Если общее дело делают и болеют за результат )

Опять же компания и её отношение к сотрудникам ежели располагает к подобной самоотдаче

Главное чтобы это с завидным постоянством не повторялось.

Иначе надо менеджмент и estimate менять)

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

Серьезно... У нас если хочешь - хоть ночуй :) Хочешь - оставайся в офисе, можешь читать статьи, пробовать что-то новое применить и т.д. Можно просто лекции/доклады на ютубе/вимео посмотреть... И т.д.

Серьезно... У нас если хочешь - хоть ночуй :) Хочешь - оставайся в офисе, можешь читать статьи, пробовать что-то новое применить и т.д. Можно просто лекции/доклады на ютубе/вимео посмотреть... И т.д.

У меня в предыдущем стартапе такое было, некоторые индивидуумы по ночам работали из офиса

Кроме того, рабочий день начинается 8-30/9-00/10-00/11-00

У меня в предыдущем стартапе такое было, некоторые индивидуумы по ночам работали из офиса

Если прет - надо делать. Но чувство меры надо знать...

У меня вообще нет четкого времени прихода, даже плавающего, когда приду, тогда приду

У меня вообще нет четкого времени прихода, даже плавающего, когда приду, тогда приду

И как?

Отлично

Для меня это идеально

Отлично

А как общение с командой, митинги?

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

Митингов у меня нет, если что я к нужному человеку подхожу и выясняю что мне надо

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

Ааа. А у меня так не получается... :)

Причём на предыдущем месте работы у меня также получалось)))

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

приветы пипл!) Что по вашему мнению должно входить в тестирование перед выкатом нового чего то? Если учесть что выкаты каждый день. Да да...вот такой мифический ни к чему не привязанный вопрос. без конкретики. Мне кажется что не нужно включать в тестирвоание перед выкатом проверку каждой функциональности и особенности. даже если считтаь что она важна для сайта. имхо нужно посмотреть что падало после выкатки за последние два года и только то что падало ранее(переставало работать) нужно проверять. как уязвимые места а фичи которые исправно работали и работают... и тупо не ломаются и претензий к ним никогда не было. даже если это важная функциональность не тестить. как вам такое?..)

возможно.

Проставить приоритеты и estimate.

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

Критичную функциональность надо проверять всегда, а остальное - на усмотрение владельца продукта

приветы пипл!) Что по вашему мнению должно входить в тестирование перед выкатом нового чего то? Если учесть что выкаты каждый день. Да да...вот такой мифический ни к чему не привязанный вопрос. без конкретики. Мне кажется что не нужно включать в тестирвоание перед выкатом проверку каждой функциональности и особенности. даже если считтаь что она важна для сайта. имхо нужно посмотреть что падало после выкатки за последние два года и только то что падало ранее(переставало работать) нужно проверять. как уязвимые места а фичи которые исправно работали и работают... и тупо не ломаются и претензий к ним никогда не было. даже если это важная функциональность не тестить. как вам такое?..)

IMHO надо тестить то, что затрагивает выкатываемый функционал

В идеальном мире я бы сказал что это возможно. В реалиях того с чем приходится работать - мне вопрос кажется толстым вбросом. :)

Смысл тестить регистрацию если поменяли ссылку на api чата тех поддержки

привет, вопрос конечно мифический и весьма странный. представим, ты тестируешь сайт. Разработчики вашего JS (реакта, ангуляра, эмбера и проч) сделали фикс в store веб-приложения: при написании блогпоста на странице написании блогпоста, возврат в общий фид всех блогпостов ранее последний написанный блогпост не появлялся. Сейчас он появляется, потому что ребята сделали notify (уведомили) диспетчер, который слушает такое событие. Вопрос: что тестировать в этом случае? Логин и регистрацию приложения тестировать не стоит, но любого рода "события" на похожих страницах проверить стоит, именно в рамках SPA-приложения. Едва ли такой фикс затронет количество максимальных слов в блог посте, или затронет то, что отвалится валидатор не позволяющий опубликовать пустой блогпост. Также маловерятно, что такой фикс вообще затронет бекенд и API - тестировать не нужно. Идеальный вариант - а) разработчики пишут в тикете, на что обратить внинмание. Я работал с командой, которая прекрасно знала опасные точки и писала о критических моментах, фактически это было половиной всего чеклиста к фиче. б) не верить этому и смотреть код коммита. Пытаться понять границы затронутого. Код в шаблоне .hbs едва ли сломает логику сайта, но отображение конкретной страницы может сломаться. Т.е. нужно представлять как в современных MVC MVP MVVM приложениях ресурс файл за что отвечает. в) Наличие автотестов на апи и фронтенд покрывающие регрессию, а также смоук-набор чтобы всегда проверять ключевую функциональность. тестировать все с нуля глупо - никто не даст вам времени каждый раз проводить регрессию. Возможно, регрессия тем сильнее на проекте необходима, чем больше связанности элементов в системе и одно ломает другое

Смысл тестить регистрацию если поменяли ссылку на api чата тех поддержки

А на деле ещё чёто ковыряли, но не в рамках задачи

И на проде чёто отъебнуло в итоге

Смысл тестить регистрацию если поменяли ссылку на api чата тех поддержки

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

А на деле ещё чёто ковыряли, но не в рамках задачи

вот поэтому нужен код-ревью разработчиков, делать другие рефакторинги в рамках фич-задач - это зло

А на деле ещё чёто ковыряли, но не в рамках задачи

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

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

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

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

Иногда критично так много, что если его тестить каждый день, то на тестирование фичи нет времени

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

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

за 3 года видел все бранчдиффы всегда :)

за 3 года видел все бранчдиффы всегда :)

Я ж не говорю, что такого нигде нет))))

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

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

мм....крч основные функциональности проверять всегда. Еще получить доступ к коду хорошо бы. ну в общем с чего началось к тому и пришли. революции не получилось(

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

Сила в неведении

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

Не все далеко умеют читать код, вот в чем проблема

ERROR: S client not available

Больше интересных багов найдёшь

?

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

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

А по коду разработчики и сами протестировать могли

Более того, должны были

я хз ребят где вы находите такие компании :)

Иногда критично так много, что если его тестить каждый день, то на тестирование фичи нет времени

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

мм....крч основные функциональности проверять всегда. Еще получить доступ к коду хорошо бы. ну в общем с чего началось к тому и пришли. революции не получилось(

А чего вы ждали? 1. проверять надо по приоритету от самого важного к самому ненужному. 2. обьём проверок ограничен вашими ресурсами Всё.

с руководством которое трекает ваше время на стуле, не дает смотреть в код

с руководством которое трекает ваше время на стуле, не дает смотреть в код

Я ж говорю чаще сами тестеры не умеют читать код, и это очень во многих компаниях

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

От некоторого кода могут и глаза выгореть.

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

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

Я ж говорю чаще сами тестеры не умеют читать код, и это очень во многих компаниях

Ну а как набить скил, если не дают практиковаться?

Ну а как набить скил, если не дают практиковаться?

Изучай программирование)))

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

не дают - бьют по рукам, когда ты сидишь дома и вместо дотки пытаешься открыть automated-testing.info

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

приветы пипл!) Что по вашему мнению должно входить в тестирование перед выкатом нового чего то? Если учесть что выкаты каждый день. Да да...вот такой мифический ни к чему не привязанный вопрос. без конкретики. Мне кажется что не нужно включать в тестирвоание перед выкатом проверку каждой функциональности и особенности. даже если считтаь что она важна для сайта. имхо нужно посмотреть что падало после выкатки за последние два года и только то что падало ранее(переставало работать) нужно проверять. как уязвимые места а фичи которые исправно работали и работают... и тупо не ломаются и претензий к ним никогда не было. даже если это важная функциональность не тестить. как вам такое?..)

Никто никому ничего не должно. Тестирование-это про добычу информации. Много протестировали - больше информации добыли, меньше - меньше добыли. Добыча тоже стоит денег, иногда больших. Всей информации никогда не добудешь.

открыл такой https://laracasts.com/series/learn-vue-2-step-by-step а тебе пм звонит и говорит "ты че сука, попутал?а ну включай Как я встретил вашу маму!"

Ну а как набить скил, если не дают практиковаться?

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

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

"Гарантировать хоть какое-то качество" - это охуенное выражение. Надо его в цитаты забрать.

не дают - бьют по рукам, когда ты сидишь дома и вместо дотки пытаешься открыть automated-testing.info

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

"Гарантировать хоть какое-то качество" - это охуенное выражение. Надо его в цитаты забрать.

Ахах) acceptance который чуть больше smoke) только высокоприоритетные проверки) без которых ни в коем случае нельзя)

Ребят, тут вообще мат не котируют.

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

А где ты работаешь?

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

Опыт чтения и написания кода это разные вещи

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

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

Опыт чтения и написания кода это разные вещи

Лол?

Опыт чтения и написания кода это разные вещи

Читать, но не писать - бесполезно, писать не читая - вредно.

Опыт чтения и написания кода это разные вещи

Спасибо, я знаю, я в универе 6 лет читал код, хотя должен был его писать

А где ты работаешь?

В 1 фирме