Статья более похожа на описание ощущений автора, чем реальных + и - скрама. Чтобы не было стресса и было время передохнУть, нужно адекватно оценивать трудозатраты. Аспекты/роли предопределены - так это огромный плюс, каждый знает, что ему делать и что от него требуется. Если кто-то не доволен процессами, то можно их обсудить на ретроспективе.
Автор забыл, что а) для формирования требований есть бизнес аналитики (иные специалисты) + маркетологи, которые и обсуждают с заказчиками/продакт оунерами, что можно, что не можно, что нужно, что не нужно. Люди, которые не имеют соответствующих знаний и опыта (в данном случае команда, разрабатывающая продукт), не могут сами решать, как делать, какие требования там должны быть - как предлагает автор сей статьи. Если что-то сделать технически не возможно или можно сделать лучше/проще, то это все обсуждается на пленнингах/рифайнментах - то бишь, команда в некоторой степени может "управлять содержанием"; б) продакт оунер это не мальчик на побегушках, ему не нужно каждый раз бегать к своему руководству, чтобы одобрить те или иные требования.
Дейв Андерсон живёт где-то в параллельной вселенной. В компаниях обычно есть performance review работника, а есть ещё бюджет, есть ещё запрос на добавление новых специалистов, а это бюджетные траты - хоть из кожи вылезь, если карты не сходятся, то никто повышение в должности давать не будет
Эээ, поиск багов это одна из целей тестирования. Если по факту приложение/сайт работает не как написано в требованиях, то это в основном квалифицируется как баг. Баги бывают и в требованиях. Помимо этого баги ещё нужно искать вне требований, так сказать.
Что сказочник, то верно. Софтскиллы кандидата определяются на hr и техническом собеседованиях, ответственный от команды за проведение интервью уже на техническом совбесе может определить, сработаются ли люди или нет.
Разработка начинается с планирования, а тестируют для начала тестировщики. А Смута вышла сделанная левой ногой, потому что команда делала все на отвали, деньги получили и успокоились.
Неприкрытая реклама гетматч и компании, с волшебным получением оффера а-ля "сразу оторвали с руками и ногами", при чем у кандидата постоянно случались форс-мажоры, но у компании был вагон времени, чтобы постоянно переносить этапы собесов.
Только в реальной жизни требования являются важной составляющей практически любого проекта, особенно больших и в критически важных сферах, потому как наличие требований позволяет как минимум устранить разночтение
У ASTQB экзамен можно сделать либо онлайн, либо в их центре, если данный провайдер есть в стране. Регистрироваться на экзамен и выбирать дату лучше тогда, когда будешь подготовлен, а не заранее. 2 месяца очень субъективно, все зависит от уже имеющихся знаний и опыта. На Ютьюбе можно найти видео ментора, который разбирает теорию и практику по силлабусу, просто ввести в поиск название экзамена на фаундейшн и скорее всего первым и будет его сборник видео. Подготовка на фаундейшн вообще не сложная.
"Медианная зарплата – это показатель, который делит все заработные платы на две равные части: половина работников получают больше медианы, а вторая часть – меньше этого значения." (с)
Unit-тесты позволяют выявлять баги кода на ранних этапах + проверка, что код соответствует стандартам, на следующих уровнях будет бОльшая уверенность в коде + экономия времени + легче найти неочевидные баги, unit-тесты нужны, на следующих уровнях будут проводиться иные типы тестирования, которые будут отлавливать иной пласт багов
Работодателям делать нечего, кроме как по соцсетям и блогам бегать, ага. Хорошо составленное резюме, пет-проект, сертификаты (от узнаваемых компаний), сеть из коллег - вот это все увеличивает шанс.
Чтобы знать, как работает система и каковы ее особенности, нужно иметь доступ к коду, чего тестировщики зачастую не имеют. Более того, сами разработчики не всегда могут быстро определить причину проблемы. "Уделяет большую часть своего внимания второстепенным вещам" - эм, что? Тестировщики руководствуются приоритетами.
Статья более похожа на описание ощущений автора, чем реальных + и - скрама. Чтобы не было стресса и было время передохнУть, нужно адекватно оценивать трудозатраты. Аспекты/роли предопределены - так это огромный плюс, каждый знает, что ему делать и что от него требуется. Если кто-то не доволен процессами, то можно их обсудить на ретроспективе.
Хорошая попытка, ChatGPT, но нет, все равно приходится искать другие варианты при решении иногда даже элементарных задач.
Нельзя поломать то, что уже поламано☝️
Автор забыл, что а) для формирования требований есть бизнес аналитики (иные специалисты) + маркетологи, которые и обсуждают с заказчиками/продакт оунерами, что можно, что не можно, что нужно, что не нужно. Люди, которые не имеют соответствующих знаний и опыта (в данном случае команда, разрабатывающая продукт), не могут сами решать, как делать, какие требования там должны быть - как предлагает автор сей статьи. Если что-то сделать технически не возможно или можно сделать лучше/проще, то это все обсуждается на пленнингах/рифайнментах - то бишь, команда в некоторой степени может "управлять содержанием"; б) продакт оунер это не мальчик на побегушках, ему не нужно каждый раз бегать к своему руководству, чтобы одобрить те или иные требования.
"доверие к тестам в команде" - тут нужно доверие к коду в команде
Не выдуманные истории, о которых не можно молчать... Ничего не знает, но все умеет
"уменьшилось количество проблем, связанных с редактированием того или иного теста или шага в нем" - тесты начали сами себя исправлять? Понятно.
Дейв Андерсон живёт где-то в параллельной вселенной. В компаниях обычно есть performance review работника, а есть ещё бюджет, есть ещё запрос на добавление новых специалистов, а это бюджетные траты - хоть из кожи вылезь, если карты не сходятся, то никто повышение в должности давать не будет
Эээ, поиск багов это одна из целей тестирования. Если по факту приложение/сайт работает не как написано в требованиях, то это в основном квалифицируется как баг. Баги бывают и в требованиях. Помимо этого баги ещё нужно искать вне требований, так сказать.
Что сказочник, то верно. Софтскиллы кандидата определяются на hr и техническом собеседованиях, ответственный от команды за проведение интервью уже на техническом совбесе может определить, сработаются ли люди или нет.
Разработка начинается с планирования, а тестируют для начала тестировщики. А Смута вышла сделанная левой ногой, потому что команда делала все на отвали, деньги получили и успокоились.
Неприкрытая реклама гетматч и компании, с волшебным получением оффера а-ля "сразу оторвали с руками и ногами", при чем у кандидата постоянно случались форс-мажоры, но у компании был вагон времени, чтобы постоянно переносить этапы собесов.
Только в реальной жизни требования являются важной составляющей практически любого проекта, особенно больших и в критически важных сферах, потому как наличие требований позволяет как минимум устранить разночтение
У ASTQB экзамен можно сделать либо онлайн, либо в их центре, если данный провайдер есть в стране. Регистрироваться на экзамен и выбирать дату лучше тогда, когда будешь подготовлен, а не заранее. 2 месяца очень субъективно, все зависит от уже имеющихся знаний и опыта. На Ютьюбе можно найти видео ментора, который разбирает теорию и практику по силлабусу, просто ввести в поиск название экзамена на фаундейшн и скорее всего первым и будет его сборник видео. Подготовка на фаундейшн вообще не сложная.
"Медианная зарплата – это показатель, который делит все заработные платы на две равные части: половина работников получают больше медианы, а вторая часть – меньше этого значения." (с)
Эм, название статьи не соответствует контенту. А защитить прод от багов полностью нельзя, исчерпывающее тестирование невозможно.
Unit-тесты позволяют выявлять баги кода на ранних этапах + проверка, что код соответствует стандартам, на следующих уровнях будет бОльшая уверенность в коде + экономия времени + легче найти неочевидные баги, unit-тесты нужны, на следующих уровнях будут проводиться иные типы тестирования, которые будут отлавливать иной пласт багов
Работодателям делать нечего, кроме как по соцсетям и блогам бегать, ага. Хорошо составленное резюме, пет-проект, сертификаты (от узнаваемых компаний), сеть из коллег - вот это все увеличивает шанс.
Чтобы знать, как работает система и каковы ее особенности, нужно иметь доступ к коду, чего тестировщики зачастую не имеют. Более того, сами разработчики не всегда могут быстро определить причину проблемы. "Уделяет большую часть своего внимания второстепенным вещам" - эм, что? Тестировщики руководствуются приоритетами.
Для этого тесты регулярно пересматривают, потому что могут измениться даже требования с течением времени