90 ответов в теме

[Orange Ray]

Но если все так, то это на мой взгляд явный косяк кого то из ССР, или нет?

Это в любом случае их косяк.

[FerrusManus]

Это в любом случае их косяк.

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

Ну прям ЯВНЫЙ и ОЧЕВИДНЫЙ дефект. В первую очередь тестируют такое
Вот почему тест на тесте всегда менее репрезентативный нежели на проде. Выборка ситуаций больше.

Сообщение отредактировал FerrusManus: 16 July 2015 - 17:50

[Orange Ray]

Вполне себе очевидный. Одна из тех вещей которые впервую очередь проверяются.

[FerrusManus]

Вполне себе очевидный. Одна из тех вещей которые впервую очередь проверяются.

Сарказм не в тему.

[makstomaks]

Ну прям ЯВНЫЙ и ОЧЕВИДНЫЙ дефект. В первую очередь тестируют такое 

 

а что еще можно там тестировать?

кстати кирилица не в тему опрделенно.

[FerrusManus]

а что еще можно там тестировать?
кстати кирилица не в тему опрделенно.

Действительно. Больше нечего. Ведь связь названия станция с сбросом таймера прям в глаза бросается.

[Orange Ray]

Один модуль передает в другой название станции которую теперь можно захватывать. Название в кириллице, модуль№2 переворачивает стол и уходит вешаться на сервере.

[CCP Leeloo]

Проблема с обработкой юникода в названиях действительно пристуствует иногда, но не в данном случае, и к тому же, она не привела бы к данному сбою, так как скрипт подбирает ID сооружения из базы, а не его название\описание\и т.п.

[FerrusManus]

Один модуль передает в другой название станции которую теперь можно захватывать. Название в кириллице, модуль№2 переворачивает стол и уходит вешаться на сервере.

Да, это тебе понятно, после поста Вердна (думаю ССР тоже сразу сообразили, как появился фидбек с транка).
Вот только когда тестировали, кириллических названий не было. И я не вижу причин, почему мог возникнуть вопрос: "а что если" - ведь работает с английскими, почему не может работать и с другими?

Функционал тестили - он работает.
Влияние языка совсем не тривиально и выявить его без соответствующей статистики сложно.

Проблема с обработкой юникода в названиях действительно пристуствует иногда, но не в данном случае, и к тому же, она не привела бы к данному сбою, так как скрипт подбирает ID сооружения из базы, а не его название\описание\и т.п.

Хм. Меняет ситуацию
Раз уж расщедрились на инфу, можно хоть в общих чертах описать "почему"?

[Obsik]

Вполне себе очевидный. Одна из тех вещей которые впервую очередь проверяются.

Сразу видно высококвалифицированного специалиста как в тестировании, так и в разработке.

Почему люди, которые ничего в этом не понимают, пишут какую-то ересь?

[Illiet]

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

Ну прям ЯВНЫЙ и ОЧЕВИДНЫЙ дефект. В первую очередь тестируют такое
Вот почему тест на тесте всегда менее репрезентативный нежели на проде. Выборка ситуаций больше.

Вообще то проблема кодировок довольно стандартная, особенно с кириллицей.

[FerrusManus]

Вообще то проблема кодировок довольно стандартная, особенно с кириллицей.

Ты все ещё не понял.
Но да ладно. Проблема не в этом, как выяснилось.

[Korvin]

В фантазии Корвина возможно всё 

Есть гипотеза, что я сплю, а вы мне снитесь.

 

Тем не менее, факап на лицо. (это не пожелание, а констатация факта.) 

 

Безусловно, в ЦЦП есть (был) отдел QA. В него в незапамятном 2010 брали всех кто мимо проходил. Вот только, часть народу оттуда давно ушла на другие должности, часть вообще из ЦЦП. Новых людей туда уже давно не искали. Подозреваю, что с тех пор, как я последний раз был в ЦЦП этот отдел сильно похудел.

[strannik_au]

Если работало на тесте тут 2 варианта, либо проверили не все/не должным образом, либо ресуры были выделенные некорректно - не заполненная бд, мало времени, информации, слабое приближение к продакшену - то вопрос к тем кто организует ресурсы для тестирования.

 

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

этот баг мог появится после того как тестировали ту функциональность.

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

 

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

 

и собственно виноваты тут не QA или разрабы, а програм менеджеры которые выбрали такой способ разработки приложения.

 

ну и конечно и девелоперы с тестерами в том что не определили зависимости и не включили перетестирование второй части в план.

[Akako]

Надеюсь ССП уволит весь пиар отдел, всяких бесполезных переводчиков и дополнит отдел Тестирования.

[SteamWork]

этот баг мог появится после того как тестировали ту функциональность.

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

 

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

 

и собственно виноваты тут не QA или разрабы, а програм менеджеры которые выбрали такой способ разработки приложения.

 

ну и конечно и девелоперы с тестерами в том что не определили зависимости и не включили перетестирование второй части в план.

"этот баг мог появится после того как тестировали ту функциональность." - т.е. по твоей логике как получается, протестировали, накатали еще кусок функционала и не стали его тестировать и в нем как раз баг был?

 

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

Есть общепринятая практика называется "регрессионное тестирование", если сказать проще - проверка старого рабочего функционала после подготовки релиза(до его выпуска в прод). Необходимость проведения такого тестирования - уже другой вопрос(я его провожу постоянно перед каждым релизом каждого из проектов).

Сообщение отредактировал SteamWork: 17 July 2015 - 9:46

[strannik_au]

"этот баг мог появится после того как тестировали ту функциональность." - т.е. по твоей логике как получается, протестировали, накатали еще кусок функционала и не стали его тестировать и в нем как раз баг был?

неправильно. протестировали, накатали кусок функционала, протестировали его, а в другом куске функционала появился баг.

 

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

[SteamWork]

неправильно. протестировали, накатали кусок функционала, протестировали его, а в другом куске функционала появился баг.

 

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

 

Несколько месяцев - это бред полный и такое возможно если отдать огромный проект одному человеку который в тестировании первый день. Самое что большое я видел - это 25 часовой регрессионный автотест, на системе которую разрабатывали годами(более 5 лет активной разработки в группе) и она очень огромна. Трудоемкость разработки такого теста составляла 1 человеко год. Да затраты с первого взгляда кажутся большими, но результаты - всегда стабильные сборки, как бы часто их не делали и какой бы кусок системы не правили.

 

Регресс тесты для больших проектов в 99% случаев автоматизированны. Для небольших блоков системы РТ можно проводить руками, но это уже не верно, т.к. человеческий фактор=пропуск бага и риски повышаются очень сильно.

 

"наличие багов уже зависит от того насколько правильно оценили риски." - вот эта фраза. Оценка рисков и наличие\отсутствие багов никак не связанно между собой. Если речь шла о допуске найденного бага в релиз по risk based когда нет времени закрыть все найденные баги, то да тут можно согласиться с этой фразой. Даже при RB подходе, априори считается что в системе есть баги, и RB подход оценивает только возможность "пропуска" такого бага при тестировании и на его основе выдвигаются сроки и ресурсы на тестирование (либо вообще отмена тестирования функционала).

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

[CCP Leeloo]

Есть гипотеза, что я сплю, а вы мне снитесь.

 

Тем не менее, факап на лицо. (это не пожелание, а констатация факта.) 

 

Безусловно, в ЦЦП есть (был) отдел QA. В него в незапамятном 2010 брали всех кто мимо проходил. Вот только, часть народу оттуда давно ушла на другие должности, часть вообще из ЦЦП. Новых людей туда уже давно не искали. Подозреваю, что с тех пор, как я последний раз был в ЦЦП этот отдел сильно похудел.

Этот тот момент, Корвин, когда твоя гипотезная аналитика не срабатывает. Информация о QA есть в вкладке About, как я уже выше говорила. Вон лучше иди набрасывай в теме про онлайн, там тебе может и поверит кто