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

[Denadan]

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

я те больше скажу - нет никакой евы, это происки зог

[Korvin]

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

Ок, ок дорогая, я тебе верю. В ЦЦП отдел QA процветает, багхантеры тут ни при чем, и это сугубо фейл процветающего отдела QA. Видишь, доверие - основа человеческих взаимоотношений.

[strannik_au]

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

 

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

 

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

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

это чушь полная. во первых в современном мире никто по 5 лет не разрабатывает проекты так как то что было специфицировано 5 лет назад никому уже не нужно.

 

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

 

т.е вместо того чтоб сделать приложения за 2.5 года, ты его делаешь 5 лет

 

представь себе если б каждое обновление в еве делали 5 лет. думаешь много людей бы в нее играли?

 

по поводу риск based ты походу вообще не вкуриваешь что такое риск бейсд тестирование.

для справки  - это когда определяют какой функционал затронут изменениями и тестируют только его.

[SteamWork]

это чушь полная. во первых в современном мире никто по 5 лет не разрабатывает проекты так как то что было специфицировано 5 лет назад никому уже не нужно.

 

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

 

т.е вместо того чтоб сделать приложения за 2.5 года, ты его делаешь 5 лет

 

представь себе если б каждое обновление в еве делали 5 лет. думаешь много людей бы в нее играли?

 

по поводу риск based ты походу вообще не вкуриваешь что такое риск бейсд тестирование.

для справки  - это когда определяют какой функционал затронут изменениями и тестируют только его.

 

 

Предлагаю закончить дисскус т.к. уже офф-топ, но напоследок выскажусь.

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

 

1. Разрабатывать проект 5 лет и выпустить проект на 5й год разные вещи. Было множество релизов как минорных так и мажорных версий в течении этих 5 лет.

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

 

Поясню ситуацию, ты разрабатываешь проект (допустим еву) уже 3 года. Функционала туча, каждый следующий патч норовит сломать старый функционал, ты принимаешь решение покрыть все регресс тестами. Выделяешь человека, он 10 месяцев пишет автотесты для того функционала что был разработан за 3 года, и оставшиеся 2 месяца покрывает тестами то, что было разработана за предыдущие 10 месяцев. После этого на этапе 4х годичной разработки есть первые автотест который полностью покрывает систему. К 5году разработки(на этом этапе я застал проект) автотесты отрабатывали больше суток.

[Asterologist]

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

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

 

Построй мне логическую цепочку между случаем в ССР, где только их код и случаем взаимодействия продукта и апгрейда операционки? А так, согласен - явный и очевидный дефект. 

 

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

Приведу простой пример. Решили мы обновить IBM WAS на проде др 8.5.6 , 8.0.
Спросили разработчиков, повлияет ли разница в версионности на работоспособность приложения.
Неделю отдел аналитики лопатил это - нет говорят, компоненты которые отличаются в новой версии не затрагивают приложение.
Результат - не работают некоторые модули приложения, потому что у нас порядка 200 разных приложений, на разных платформах, которые так или иначе связаны между собой. И новая версия незначительно повлияло на интеграцию одного приложения, изменив немного логику, при этом само приложение работало как и должно. Но из-за другой логике попало под раздачу 3ье и т.д.
И это в одном из крупнейших банков нашей страны, оборот которого на порядок выше, чем у ССР.

Ты думаешь уволили кого-то? Нет. Потому что брать новых аналитиков, которые в системе будут разбираться пару месяцев? Или новых QA? Которые по "новичковости" пропустят ещё больше багов?
А ты продолжал жить в своём наивном мире.

 

 

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

Плюсики-то твинами не забывай ставить.

[strannik_au]

Предлагаю закончить дисскус т.к. уже офф-топ, но напоследок выскажусь.

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

 

1. Разрабатывать проект 5 лет и выпустить проект на 5й год разные вещи. Было множество релизов как минорных так и мажорных версий в течении этих 5 лет.

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

 

Поясню ситуацию, ты разрабатываешь проект (допустим еву) уже 3 года. Функционала туча, каждый следующий патч норовит сломать старый функционал, ты принимаешь решение покрыть все регресс тестами. Выделяешь человека, он 10 месяцев пишет автотесты для того функционала что был разработан за 3 года, и оставшиеся 2 месяца покрывает тестами то, что было разработана за предыдущие 10 месяцев. После этого на этапе 4х годичной разработки есть первые автотест который полностью покрывает систему. К 5году разработки(на этом этапе я застал проект) автотесты отрабатывали больше суток.

разрабатывать проект 5 лет и сделать проект за год а потом заниматься его развитием это немного разные вещи.

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

[Ale_xXx]

Да, была такая фигня, открутили всё в системе обратно, таймер уязвимости закончился и сразу же начался снова, вот как-то так) Еще был баг с т2 энтозисом, когда после повторной активации, если из системы не выходил, не приходит сообщение об атаке защищающейся стороне

а мы подумали что это наши окно уязвимости перенесли ))

[Torius Enaka]

а мы подумали что это наши окно уязвимости перенесли ))

при переносе окна неуязвимости оно обновляется только через двое суток

[Asterologist]

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

У нас не более 20%.

[strannik_au]

ну так это зависит от того в каком обьеме автоматизировать

[Tatovkin]