(настройка бэкапов и тест на восстановимость оных) с mssql так не выйдет, да и способов отстрелить себе что-то с ним гораздо больше
Зря вы так, MS SQL Server совсем не плох. Тем более, если приложение разрабатывается только на платформе Windows.
Что касается Firebird, то, наверное, хотелось услышать от разработчиков аргументы в его пользу, например почему Firebird а не Postgree?
Теперь я узнал о Firebird полезную для себя информацию — на этой СУБД делают успешные системы и при проектировании его можно рассматривать как приемлимую альтернативу (многоплатформенность, свободная лицензия, опыт применения).
Но мы уже раньше встречались с Иннокентием и знаем, что в прошлые месяцы он покупал преимущественно мелкую бытовую технику и одежду в России со средним чеком 7 000 рублей. Только сегодня утром он пополнял проездной в Москве, поэтому принципиальных изменений в его поведении быть не должно.
Правильно ли я понял, что если я ищу работу, разослал резюме, а потом зашёл в интерне-поиск и набрал «омез», то кадровые агентства уже знают, что у меня проблемы с желудком?
в бейсболе все подсчитано — хиты, раны, пойманные мячи
В разработке ПО есть такая проблема (испытал на своём скине):
— дешёвый проект, но работы реально много — а там горбатятся 2,5 человека. Иногда (от недостатка опыта) они считают себя даже героями, а всем (и руководству и ПМ) по-настоящему наплевать.
— дорогой проект, но реальной работы дай Бог на троих — а там несколько десятков разрабов и все «загружены» на 120%.
Объективных критериев оценки и мотивации в облати ИТ (очень часто/совсем) нет — об этом статья.
Качественное тестирование может обеспечить только внешняя, неаффелированная команда (это из области психологии — почему так, учёные пока объяснить не могут).
Тестировать надо (в солидных компаниях, которые привыкли заботиться о своей репутации) не только собственные разработки, но и любые ПО-продукты, которые там внедряют.
Мне всегда казалось, что тестирование отдельно от разработки не продать.
Отлично продаётся. Главные потребители — банки и корпорации. У них сейчас сенокосная пора на мобильную разработку. А свой штат тестировщиков держать на окладе — зачем? Тестировщики востребованы только по мере появления нового ПО (и собственной и сторонней разработки).
А вот как можно нагрузку условного Фейсбука протестировать руками – я даже и не знаю.
Если вы имеете в виду — смоделировать нагрузочный тест как примитивную DDOS-атаку, то да — это будет делать скрипт.
Прям сижу и вижу, как десятки тестировщиков руками синхронно проводят сложные прикладные поведенческие тесты, (которые, к слову, будут абсолютно нерепрезентативны для других порядков чисел).
Поведенческие тесты нужны тогда, когда надо выявить, например, скрытую/плавающую ошибку. Разработать, провести такой тест и получить положительный результат (выявить причину проблемы) — большая работа. В каждом конкретном случае такие тесты уникальны.
Кстати, сейчас востребованы услуги по тестированию ПО, которые предоставляются по схеме аутсоурсинга. Мне известна одна такая фирма. В штате у неё несколько десятков тестировщиков (с разными проф. навыками). У неё всегда есть заказы, а услуги далеко не всем по-карману.
Для выявления некоторых (самых неприятных) багов, иногда бывает нужно смоделировать не просто нагрузку, а сложный прикладной поведенческий тест. Для этого приходится вникать и в прикладную область и разрабатывать мудрёные алгоритмы.
PS А вы всерьёз думали, что эти несчастные долбят как мартышки по клавишам?
Мне известны примеры, когда в тестировании участвуют десятки тестировщиков. Сейчас эта тема вполне актуальна, когда речь идёт о важной системе в солидной компании.
А как быть в случае, если баг проявляется в процессе взаимодействия пользователя с формой.
Например — пользователь с таким именем уже зарегистрирован в системе.
Или — пароль не прошёл валидацию на сложность.
Или просто произошла ошибка при сохранении данных.
Сможет ли автоматический тест решать такие задачи?
Дело не во мне. В статье затронута действительно актуальная тема, с которой, в той или иной степени, сталкиваются все компании-разработчики ПО. Я стараюсь задавать «уточняющие» и «наводящие» вопросы, которые позволят лучше раскрыть тему. Судя по статье — у вас есть успешный опыт атоматического тестирования.
Например, в компании, где я работаю, схема примерно такая: после этапа первичной разработки (разработка обычно ведётся на основании требований) составляется ПМИ, которое передаётся тестировщикам (их несколько человек и у них нет навыков разработки, но им приходится иметь дело с прикладной областью). Тестировщики пишут баг-репорты, которые исправляются. И так до устранения всех проблем. В общем-то ничего нового.
Обеспечивая качественное покрытие кода приложения тестами мы одновременно замедляем разработку как таковую. И замедляем не на 10%, а вдвое, втрое или даже больше.
Переход на автоматическое тестирование у нас тормознул, в том числе, и по этой причине.
И дело не только во времени. Нужны ещё дополнительные ресурсы (разработчики со спец. навыками) для разработки тестов. Но тесты покрывают далеко не все задачи тестирования. В итоге, стоимость и сроки разработки растут, а без ручного тестирования всё-равно не обойтись.
Нагрузку проверяет нагрузочное тестирование, оно ни к авто, ни к ручному особого отношения не имеет.
Вы меня заинтриговали (извините за сарказм), как же оно выполняется (или кем)? В вашем контексте «нагрузочное тестирование» это субъект, программа, технология или что?
у каждого важного элемента должен быть уникальный, не меняющийся id
О каком «важном элементе» идёт речь в данном контексте, кто и на каком этапе задаёт id, как гарантируется уникальность?
При таком раскладе можно написать один раз пачку тестов на селениуме
Тесты на селениуме? Очень интересно. А конкретный пример теста можно? Что-нибудь простое, например типа регистрации нового пользователя.
Зря вы так, MS SQL Server совсем не плох. Тем более, если приложение разрабатывается только на платформе Windows.
Что касается Firebird, то, наверное, хотелось услышать от разработчиков аргументы в его пользу, например почему Firebird а не Postgree?
Теперь я узнал о Firebird полезную для себя информацию — на этой СУБД делают успешные системы и при проектировании его можно рассматривать как приемлимую альтернативу (многоплатформенность, свободная лицензия, опыт применения).
Правильно ли я понял, что если я ищу работу, разослал резюме, а потом зашёл в интерне-поиск и набрал «омез», то кадровые агентства уже знают, что у меня проблемы с желудком?
Что я сделал не так?
В разработке ПО есть такая проблема (испытал на своём скине):
— дешёвый проект, но работы реально много — а там горбатятся 2,5 человека. Иногда (от недостатка опыта) они считают себя даже героями, а всем (и руководству и ПМ) по-настоящему наплевать.
— дорогой проект, но реальной работы дай Бог на троих — а там несколько десятков разрабов и все «загружены» на 120%.
Объективных критериев оценки и мотивации в облати ИТ (очень часто/совсем) нет — об этом статья.
Некоторые места задели за живое, например:
выходит это распространённое явление, а то я думал только в тех местах, где мне довелось поработать.
Тестировщики, о которых вы говорите — входят в обязательный штат современной компании-разработчика ПО.
Внешнее тестировщики нужны, когда компания не хочет, чтобы её 100500 клиентов выступили в качестве тестировщиков.
Для внешнего тестирования отлично подходит аутсоурсинговая компания.
Качественное тестирование может обеспечить только внешняя, неаффелированная команда (это из области психологии — почему так, учёные пока объяснить не могут).
Тестировать надо (в солидных компаниях, которые привыкли заботиться о своей репутации) не только собственные разработки, но и любые ПО-продукты, которые там внедряют.
Сказал и сделал — вероятно это и есть самый главный скилл в любом деле. Спасибо, записал себе в ноут.
Уверен, у вас получится. По-крайней мере, стоит попробовать.
Статью с таким названием я бы хотел прочитать.
А как быть, если просто нужен «качественный автоматизатор» тестов — какие к нему должны быть требования по скилам?
Отлично продаётся. Главные потребители — банки и корпорации. У них сейчас сенокосная пора на мобильную разработку. А свой штат тестировщиков держать на окладе — зачем? Тестировщики востребованы только по мере появления нового ПО (и собственной и сторонней разработки).
Если вы имеете в виду — смоделировать нагрузочный тест как примитивную DDOS-атаку, то да — это будет делать скрипт.
Поведенческие тесты нужны тогда, когда надо выявить, например, скрытую/плавающую ошибку. Разработать, провести такой тест и получить положительный результат (выявить причину проблемы) — большая работа. В каждом конкретном случае такие тесты уникальны.
Кстати, сейчас востребованы услуги по тестированию ПО, которые предоставляются по схеме аутсоурсинга. Мне известна одна такая фирма. В штате у неё несколько десятков тестировщиков (с разными проф. навыками). У неё всегда есть заказы, а услуги далеко не всем по-карману.
PS А вы всерьёз думали, что эти несчастные долбят как мартышки по клавишам?
А как быть в случае, если баг проявляется в процессе взаимодействия пользователя с формой.
Например — пользователь с таким именем уже зарегистрирован в системе.
Или — пароль не прошёл валидацию на сложность.
Или просто произошла ошибка при сохранении данных.
Сможет ли автоматический тест решать такие задачи?
Дело не во мне. В статье затронута действительно актуальная тема, с которой, в той или иной степени, сталкиваются все компании-разработчики ПО. Я стараюсь задавать «уточняющие» и «наводящие» вопросы, которые позволят лучше раскрыть тему. Судя по статье — у вас есть успешный опыт атоматического тестирования.
Например, в компании, где я работаю, схема примерно такая: после этапа первичной разработки (разработка обычно ведётся на основании требований) составляется ПМИ, которое передаётся тестировщикам (их несколько человек и у них нет навыков разработки, но им приходится иметь дело с прикладной областью). Тестировщики пишут баг-репорты, которые исправляются. И так до устранения всех проблем. В общем-то ничего нового.
Переход на автоматическое тестирование у нас тормознул, в том числе, и по этой причине.
И дело не только во времени. Нужны ещё дополнительные ресурсы (разработчики со спец. навыками) для разработки тестов. Но тесты покрывают далеко не все задачи тестирования. В итоге, стоимость и сроки разработки растут, а без ручного тестирования всё-равно не обойтись.
Вы меня заинтриговали (извините за сарказм), как же оно выполняется (или кем)? В вашем контексте «нагрузочное тестирование» это субъект, программа, технология или что?
О каком «важном элементе» идёт речь в данном контексте, кто и на каком этапе задаёт id, как гарантируется уникальность?
Тесты на селениуме? Очень интересно. А конкретный пример теста можно? Что-нибудь простое, например типа регистрации нового пользователя.