А в чем проблема разместить центры на той же Аляске, где в зимнее время можно вообще отказаться от охлаждения водой, используя воздушныерадиаторы-теплообменики из меди или алюминия или других теплопроводящих материалов в местах с постоянными ветрами? Когда на радиатор дует ветер 30-40 м/с температурой -40 и ниже то охладить сервера с gpt можно с запасом и без всякой воды. :)
Задача тестера - выявить дефект и описать его в соответвующем Jira-item или иной системе управления проектами. Также сообщить о найденном как разработчику, так и Product Owner. Именно последний решает нужно ли передвинуть дефект в To Do или пропустить, согласовав это с клиентом, но добавив отдельный дефект для исправления найденного в следующем спринте о чём он сообщает в том же Jira item в ответ на комментарий тестера.
По своему хотению тестер не может блокировать дефект, у него него нет на это полномочий, а конфликты интересов должен решать Product Owner и Scrum master, а не разработчик и тестер напрямую между собой. Если у вас происходит последнее, то похоже что процесс поставлен неправильно.
Что касается TDD, так вроде речь там идёт не о unit, а о qa тестах как мануальных, так и автоматических, которые пишутся заранее параллельно с кодом девелопера. В результате, когда код написан, он немедленно проверяется уже готовыми тестами, что наоборот экономит время разработки.
А смысл в подобной подмене? Вот если бы можно было создать правило, которое автоматически проверяет статус соответвующего дефекта в Jira, а еще лучше статус соответвующего pull request, а именно, чтобы он стал Merged и только тогда запустить тест, чтобы получить реальную картину после того как изменения вчекинены в Github
А если ещё короче, то это область ответственности Product Owner и Scram Master. Они должны оценить все риски вплоть до того, чтобы обговорить их с клиентом: возможен ли выпуск релиза с этой проблемой и устранение её в следующем либо вообще отложить обновление до следующего релиза, в котором будет фикс. С программистом на эту тему можно поговорить лишь для того, чтобы обозначить проблему и ввести в курс дела, например показать как она воспроизводится
Задача же тестера, как было сказано выше, написать письмо с подробным описанием проблемы и каковы могут быть проблемы у клиента, добавить дефект с более лаконичным описанием, приаттачив это письмо и пометить дефект как Severity = High. Хотя и это будет лишним - даже приоритет дефекту будет назначать Product Owner.
А в чем проблема разместить центры на той же Аляске, где в зимнее время можно вообще отказаться от охлаждения водой, используя воздушныерадиаторы-теплообменики из меди или алюминия или других теплопроводящих материалов в местах с постоянными ветрами? Когда на радиатор дует ветер 30-40 м/с температурой -40 и ниже то охладить сервера с gpt можно с запасом и без всякой воды. :)
Задача тестера - выявить дефект и описать его в соответвующем Jira-item или иной системе управления проектами. Также сообщить о найденном как разработчику, так и Product Owner. Именно последний решает нужно ли передвинуть дефект в To Do или пропустить, согласовав это с клиентом, но добавив отдельный дефект для исправления найденного в следующем спринте о чём он сообщает в том же Jira item в ответ на комментарий тестера.
По своему хотению тестер не может блокировать дефект, у него него нет на это полномочий, а конфликты интересов должен решать Product Owner и Scrum master, а не разработчик и тестер напрямую между собой. Если у вас происходит последнее, то похоже что процесс поставлен неправильно.
Что касается TDD, так вроде речь там идёт не о unit, а о qa тестах как мануальных, так и автоматических, которые пишутся заранее параллельно с кодом девелопера. В результате, когда код написан, он немедленно проверяется уже готовыми тестами, что наоборот экономит время разработки.
На самом деле, можно за цену в пределах 8000-10000 р купить нормальный Jump Starter в помощь аккумулятору и не парится насчёт шансов завестись. :)
А смысл в подобной подмене? Вот если бы можно было создать правило, которое автоматически проверяет статус соответвующего дефекта в Jira, а еще лучше статус соответвующего pull request, а именно, чтобы он стал Merged и только тогда запустить тест, чтобы получить реальную картину после того как изменения вчекинены в Github
А если ещё короче, то это область ответственности Product Owner и Scram Master. Они должны оценить все риски вплоть до того, чтобы обговорить их с клиентом: возможен ли выпуск релиза с этой проблемой и устранение её в следующем либо вообще отложить обновление до следующего релиза, в котором будет фикс. С программистом на эту тему можно поговорить лишь для того, чтобы обозначить проблему и ввести в курс дела, например показать как она воспроизводится
Задача же тестера, как было сказано выше, написать письмо с подробным описанием проблемы и каковы могут быть проблемы у клиента, добавить дефект с более лаконичным описанием, приаттачив это письмо и пометить дефект как Severity = High. Хотя и это будет лишним - даже приоритет дефекту будет назначать Product Owner.