Мало того, что это банальный обзор на игру, больше уместный для игрового журнала, нежели для Хабра, так в нём ещё и нет ничего нового, ведь игра вышла ещё в прошлом году (скоро будет позапрошлый) и сам обзор не блещет оригинальностью и просто повторяет основные тезисы из других таких же обзоров.
Не понятно, почему всё расписано для Windows. Если это тестирование веб-сервисов, то логично было бы сразу описывать настройку ci/cd для какого-нибудь тестового стенда на linux. Собственно основная мысль - запустить коллекции постмана в ньюмане и отправить результаты в testIt. Это буквально пару команд. И видимо это костыль, призванный как-то автоматизировать ручную работу тестировщиков. Самому приходилось делать что-то похожее на Groovy. В итоге всё же усложнение бизнес-процесса привело к идее, что написать нормальные автотесты проще, чем поддерживать такие вот костыли в ci/cd.
Вроде бы встречал такую инструкцию много раз в сети. Как насчёт того, чтобы настроить не только отправку, но и приём писем для автоматической обработки в приложении? Это более редкий случай, но зато хоть что-то новое было бы.
Я так понимаю, цель исследования - доказать каким-то образом, что выборы неверно посчитали. Результат исследования - явка вполне правдоподобна. К чему тогда заключительный абзац? Или думаете, что специально мало людей выделили на организацию? Тогда можно было пойти дальше и сравнить с предыдущими годами. Больше явка или меньше? Можно ли было предугадать резкий рост количества избирателей?
Любопытный текст. Даж не подозревал о существовании QA Architect. Их и обычных мало, а тут прям QA. Я бы конечно несколько иначе структурировано статью. Я всегда считал, что если вы у потолка, то очевидно вы уже Automation QA. Собственно все последующие пункты предполагают умение писать код. Сомневаюсь, что кто-то из Manual QA сразу пойдёт в архитекторы, минуя стадию написания автотестов. Ну и естественно, как бывший свитчер, не могу не указать, что иногда, если ты понимаешь, что дальше расти уже некуда, то стоит попробовать шагнуть в сторону разработки или аналитики (не только с упором на QA), смотря куда больше тянет.
Базовые Unit-тесты неплохо описаны, но эту тему конечно надо развивать. Хотелось бы увидеть статьи про интеграционные и e2e-тесты, различные фреймворки и т.д..
Ну это очень просто, прям очевидно. Это даже до простого уровня не дотягивает. Лучше б написал статью "Как я вошёл в IT после курсов, не зная элементарных вещей".
Если вы, как и я раньше, наивно полагаете, что потенциальные рекрутеры хотя бы откроют ваш гитхаб, то глубоко ошибаетесь. Подавляющему большинству из них на это плевать. Если и делать README, то не для работодателя (ему нужен коммерческий опыт) и не для пользователя (ему хорошо бы интерактивное обучение в самом приложении и интуитивно-понятный интерфейс), а для отработки навыков (тогда описание нужно делать для себя, чтоб потом быстро найти и вспомнить) или для решения прикладной задачи, которая может пригодится другим разработчикам (тогда хорошо бы писать нормальный читаемый код и добавлять примеры использования). В любом случае, оформление из статьи не может служить хорошим примером.
Если бы вторая причина была надуманной, то давно бы написали множество привычных офисных программ для непродвинутого пользователя. А пока что даже офисные пакеты часто некорректно сохраняют и открывают файлы в форматах MS Office. Что уж говорить о более сложных продуктах.
Мало того, что это банальный обзор на игру, больше уместный для игрового журнала, нежели для Хабра, так в нём ещё и нет ничего нового, ведь игра вышла ещё в прошлом году (скоро будет позапрошлый) и сам обзор не блещет оригинальностью и просто повторяет основные тезисы из других таких же обзоров.
И на основе какой выборки эта статистика?
Не понятно, почему всё расписано для Windows. Если это тестирование веб-сервисов, то логично было бы сразу описывать настройку ci/cd для какого-нибудь тестового стенда на linux. Собственно основная мысль - запустить коллекции постмана в ньюмане и отправить результаты в testIt. Это буквально пару команд. И видимо это костыль, призванный как-то автоматизировать ручную работу тестировщиков. Самому приходилось делать что-то похожее на Groovy. В итоге всё же усложнение бизнес-процесса привело к идее, что написать нормальные автотесты проще, чем поддерживать такие вот костыли в ci/cd.
Вроде бы встречал такую инструкцию много раз в сети. Как насчёт того, чтобы настроить не только отправку, но и приём писем для автоматической обработки в приложении? Это более редкий случай, но зато хоть что-то новое было бы.
Новость конечно хорошая. Радостно, что на русском языке. На каких площадках будет продаваться игра в России? Не будет ли игра эксклюзивом для VKPlay?
Очень интересно и познавательно. Но сам так я делать конечно не буду. IDEA наше всё.
Я так понимаю, цель исследования - доказать каким-то образом, что выборы неверно посчитали. Результат исследования - явка вполне правдоподобна. К чему тогда заключительный абзац? Или думаете, что специально мало людей выделили на организацию? Тогда можно было пойти дальше и сравнить с предыдущими годами. Больше явка или меньше? Можно ли было предугадать резкий рост количества избирателей?
Полезно. Нашёл свою ошибку, спасибо за статью.
Любопытный текст. Даж не подозревал о существовании QA Architect. Их и обычных мало, а тут прям QA. Я бы конечно несколько иначе структурировано статью. Я всегда считал, что если вы у потолка, то очевидно вы уже Automation QA. Собственно все последующие пункты предполагают умение писать код. Сомневаюсь, что кто-то из Manual QA сразу пойдёт в архитекторы, минуя стадию написания автотестов. Ну и естественно, как бывший свитчер, не могу не указать, что иногда, если ты понимаешь, что дальше расти уже некуда, то стоит попробовать шагнуть в сторону разработки или аналитики (не только с упором на QA), смотря куда больше тянет.
Базовые Unit-тесты неплохо описаны, но эту тему конечно надо развивать. Хотелось бы увидеть статьи про интеграционные и e2e-тесты, различные фреймворки и т.д..
Тема интересная. Сам с Камундой не работал, но было бы интересно почитать ещё статьи на эту тему.
Ну это очень просто, прям очевидно. Это даже до простого уровня не дотягивает. Лучше б написал статью "Как я вошёл в IT после курсов, не зная элементарных вещей".
Вижу статью в поддержку строгой типизации - ставлю плюс.
Если вы, как и я раньше, наивно полагаете, что потенциальные рекрутеры хотя бы откроют ваш гитхаб, то глубоко ошибаетесь. Подавляющему большинству из них на это плевать. Если и делать README, то не для работодателя (ему нужен коммерческий опыт) и не для пользователя (ему хорошо бы интерактивное обучение в самом приложении и интуитивно-понятный интерфейс), а для отработки навыков (тогда описание нужно делать для себя, чтоб потом быстро найти и вспомнить) или для решения прикладной задачи, которая может пригодится другим разработчикам (тогда хорошо бы писать нормальный читаемый код и добавлять примеры использования). В любом случае, оформление из статьи не может служить хорошим примером.