Видимо о том и вопрос какой гит сервер выбрать

Предложу посмотреть в сторону gogs. Можно сразу докер выкачать и запустить

Всем привет. Такой вопрос: при статусе 200 и "From memory cache" запрос на сервер даже не отправляется, верно? А при статусе 304 запрос отправляется на сервер и ответом присылается только header, так? Как браузер различает, когда брать из кэша, а когда посылать запрос?

Всем привет. Такой вопрос: при статусе 200 и "From memory cache" запрос на сервер даже не отправляется, верно? А при статусе 304 запрос отправляется на сервер и ответом присылается только header, так? Как браузер различает, когда брать из кэша, а когда посылать запрос?

По заголовку cache control

то есть если в запросе в хедере есть cache control, то при каждой загрузке будет проверяться, не изменился ли файл? А если cache control нет, то ВСЕГДА из кэша браться будет?

то есть если в запросе в хедере есть cache control, то при каждой загрузке будет проверяться, не изменился ли файл? А если cache control нет, то ВСЕГДА из кэша браться будет?

Я, похоже, не очень понимаю вопрос :( 200 (кэш) - это когда пришёл заголовок "возьми успешный ответ из кэша". 304 - это когда браузер спросил "is modified since?", а сервер ответил "нет, поэтому возьми из кэша". Насчёт всегда не знаю, у заголовка cache control тоже есть опция валидировать ._. Не знаю точно, как работает ._.

так все же в 200 тоже приходит заголовок? Мне вот почему-то казалось, что нет. Поискал ещё: cache control и expires ещё присутствует. То есть, при установленном expires запрос на сервер даже отправляться не будет. А если стоит cache control, то запрос пойдет. Если я правильно понял

В смысле один раз (первый) приходит заголовок. Если контент свежий (max-age и(ли) expire валидные), браузер запрос на сервер отправлять не будет, а ответ возьмёт из кеша. Это 200. Если надо на сервере проверить валидность данных, то это делается заголовками, и это 304.

Похоже, я совсем косноязычная ?

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

Так что посоветовать-то? Тестируйте лучше.

В плане оптимизации, стоит ли переходить на автоматизированное тестирование или

Лучше уже не куда хД

В плане ручного

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

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

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

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

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

В Гугле есть специфичные мобильные проверки, думаю стоит начать с них

This

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

В Гугле есть специфичные мобильные проверки, думаю стоит начать с них

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

В плане оптимизации, стоит ли переходить на автоматизированное тестирование или

Нет такого «перейти на автоматизированное тестирование». Вы им ручное не замените. Если у вас из-за человеческого фактора баги на прод попадают (например, прозевал тест-кейс и не выполнил его, а чекбокс проставил), то имеет смысл ввести тест-ревью и автотесты. Если у вас большая регрессия и вы не успеваете , то имеет смысл начинать автоматизировать ваши сьюты. При этом ручное тестирование у вас никуда не денется. Есть ли у вас документы , описывающие подходы к тестированию типовых задач / компонент? Как быстро новый человек в команде сможет подхватить задачу и начать эффективно тестировать у вас на проекте? Есть ли у вас люди, которых невозможно заменить? Заведены ли у вас метрики в таск трекерах, чтобы трекать плохой перформанс отдельных людей? Автоматизированы ли скрипты , идентично ли окружение тестовооо контура к другому тестовому контуру / прод серверу? Вопросов как тестировать надежнее можно задать много

Два чая этому господину!

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

если куча проектов и всё завязано на 1 человеке - то вот вам поле для улучшения

Как вариант на аутсорс отдать

нафига?

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

Напишите в личку, помогу чем смогу)

Два чая этому господину!

Поддерживаю!

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

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

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

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

А зачем?

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

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

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

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

Michael Bolton, Context-driven Testing, Agile Testing (разные источники)

Но в двух словах это всё не объяснить

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

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

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

Я ни в коем случае не хотел написать,что автор сообщения некомпетентен - ты меня неправильно понял. Речь о некомпетентном внедрении в целом, без привязки к проекту автора. Моя мысль - фраза является маячком. Но всегда бывают исключения. :)

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

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

Как "проводить регрессию"

А с "проведением регрессии" что не так?)

Грамотная автоматизация "проводится" сама собой - и сигнализирует о проколах в системах нотификации (мейлом например).

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

А с "проведением регрессии" что не так?)

если в тексте выше заменить "автотесты" на (ручную) "регрессию" - то всё норм. А с автотестами - не айс.

У нас вообще нет ручного тестирования. Релизы каждый день. Иногда дважды в день. На каждый МР в мастер прогоняются тесты специфичные для конкретного компонента(компонент достается из бранча). Далее мерж в мастер доступен только через единственную джобу в дженкинсе, доступ к которой у 2х человек. При запуске прогоняются вообще все тесты которые есть, и только в случае успеха производится мерж

Таким образом мы всегда знаем что в мастере код прошел ревью и оттестирован

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

Молодцы:)

Автоматизация похоже построена верно.

А что за продукт у вас? Интересно, как выживает без ручного.

Рекламный сервис

Точнее его самые кишочки, системное по которое непосредственно всю вакханалию со всего инета обрабатывает

То есть сплошной бэкенд и бэкендом погоняет?

У нас вообще нет ручного тестирования. Релизы каждый день. Иногда дважды в день. На каждый МР в мастер прогоняются тесты специфичные для конкретного компонента(компонент достается из бранча). Далее мерж в мастер доступен только через единственную джобу в дженкинсе, доступ к которой у 2х человек. При запуске прогоняются вообще все тесты которые есть, и только в случае успеха производится мерж

т.е. у вас по сути TDD?

Из описания нет никаких оснований считать, что это TDD

Такой ворк флоу может существовать и без red->green->refactor , а блокирующие релиз тесты вообще не показатель

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

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

То есть сплошной бэкенд и бэкендом погоняет?

Да. И во фронты я что то больше не хочу:)

т.е. у вас по сути TDD?

Именно

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

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

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

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

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

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

т.е. даже бэкапа нету? жесть :)

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

А компания чешская или с российскими корнями? Больно уж кейс знакомый

А компания чешская или с российскими корнями? Больно уж кейс знакомый

Полностью чешская фирма

т.е. даже бэкапа нету? жесть :)

Не хрена нету хД

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

Не хрена нету хД

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

Если все верно, я бы на вашем месте начал с разговоров про полномочия, "тру QA" и чем грозит загрузка одного специалиста всем-всем-всем.

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

В точку именно так !

Соболезную :)

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

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

Соболезную :)

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

Силы есть, но надо знать что и как делать , и чему стоит ещё научиться

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

Профессионально развиваться нужно, но и про soft skills забывать не стоит

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

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

Я вижу проблему в процессах внутри команд, которую почему-то сваливают на вас и тестирование здесь становится бутылочным горлом. Начните профилактические беседы о том, что на качество влияют все участники процесса :)

Я вижу проблему в процессах внутри команд, которую почему-то сваливают на вас и тестирование здесь становится бутылочным горлом. Начните профилактические беседы о том, что на качество влияют все участники процесса :)

Менеджер считает что он делает правильно а тестирование страдает ? и проводится только грубо говоря с одной стороны

Менеджер считает что он делает правильно а тестирование страдает ? и проводится только грубо говоря с одной стороны

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

Любая оптимизация начинается с указания бизнесу на проблемные места и именно фактами

В идеале конечным пересчетом времени в $