Little_CJIOH

Вы предложили полный перебор.

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

Разумным компромиссом является допущение что дефект вызывается комбинацией 2-х параметров. Соответственно надо подобрать наборы так, чтобы каждое значение каждого параметра хотя-бы раз совпало с каждым значением любого другого параметра. техника называется pairwise обычно для генерации наборов тестов используются инструменты принимающие на вход описание параметров и выдающие список комбинаций. Мне доводилось использовать Pict

Некоторые инструменты позволяют описывать и исключать невозможные комбинации и комбинировать не по 2, а по 3 параметра

когда-то сталкивались с чем-то похожим

 

добавили флаг в конфиг по которому система определяет это дебажная сборка или продовая

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

 

наверное можно как-то лучше определять, без конфига

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

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

 

 

 

У нас решали такую проблему просто. В спринте у каждого был таск Overhead, куда легально можно было списывать до часа в день. Если за день набегало больше часа времени на всякое "активность незапланированная в спринт" (от "комп тупил, админы смотрели" до "внезапно пришлось делать рисёч, который сложно привязать к продуктовой задаче"), то приходилось заводить отдельную таску и списывать туда. Но случалось редко, на коммоновые задачи часа в день хватало.

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

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

Вот у нас в одном проекте таймшиты использовались для рассчета с заказчиком. Только в них нет тикетов, в них есть типы работ. и мы тупо раз в неделю вписываем 38 часов в "sprint work" и 2 часа в "Spikes, POCs". те самые capitals и expenses. То есть, если я играл в плойку в офисе потому что тикетов не подвезли - это 8 часов, а если болел или в отпуске был, то это 0.

Нужен DataManager который контролирует создание и модификацию тестовых данных. Соответственно если нужные данные уже есть, просто отдает их, если нет - создает.

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

 

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

 

Вы просто там никогда не работали....

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

 

2. UI тесты заменяются API- тестами, но не все, основные сценарии все равно надо проходить через UI

 

 На этот счет у меня есть идея. Приведу пример. Если я правильно вас понял, то например в моем web приложении, в UI есть кнопка, при нажатии на которую  дергается какая-то API ручка. Если я напишу тест на этот API я покрою проверку работы кнопки?  Ну и соответсвтенно если при нажатии на другую кнопку API ручка не дергается, то следовательно на эту кнопку нужно писать полноценный UI тест?

Если кнопка не дергает ни какой API то что она вообще делает?
По идее, граничные значения, простейшая бизнес-логика должны проверятся юнит-тестами. тесты API должны покрывать кейсы интеграционных тестов не залезая в ньюансы. UI тесты должны проверять верстку, логику имплиментированную на интерфейсе и проходимость основных пользовательских сценариев.

Это классическая "пирамида тестов"

 

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

Как мне кажется, это все равно не решит проблему. Нужно как-то менять саму архитектуру автотестов. А с этим как раз проблемы.

 

про архитектуру автотестов выше ссылка на очень хороший доклад. Сценарии по 30-50 шагов скорее всего можно разбить на состояния и переходы между ними.

1. не противоречит.

2. UI тесты заменяются API- тестами, но не все, основные сценарии все равно надо проходить через UI

Посмотрите:

https://sqadays.com/ru/talk/7636

Может добавится ответов.

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

Подготовкой тестовых данных должна заниматься отдельная подсистема. Тесты в своих проверках должны оперировать объектами выданными этой подсистемой.

google "jenkins maven"

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

На все ваше сообщение вам не ответит скорее всего никто. Вы откусили одновременно протокол HTTP и всю модель OSI. При одной мысли о разборе этих тем в рамках одного обсуждения на форуме делается дурно.

 

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

Отличный ответ развернутый (пост выше). Только я не могу понять

 

Пока перерыв, так как знаю, что не все дописала из smoke, чувствую еще есть тесты, но я их не замечаю.

В смоук тестировании будет только 2 теста в данном случае 1) форма открывается. 2) кнопка нажимается без падения системы.

 

т.е smoke тестироание для ДАННОЙ формы будет ТОЛЬКО нажатие на кнопку? - предположим...Нажали (дым из формы не пошел). Но что мы проверили этим нажатием, когда к примеру есть просто кнопка без логики никакой.

Smoke тест прошли - отдали тестировщикам, программисты перешли к другой задаче. тестировщик берет Критикал пас тест: вводит валидные данные в поля - нажимает кнопку - 0 реакции, прогоняет все тесты - все FAIL. Потрачего 3 часа времени в пустую, так как кнопка REGISTRATION не имела никакого события. Вопрос - что мы добились smoke тестом из вашей логики и на что мы потратили3  часа тестирования?

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

Что именно попадет в смок определяется эмпирически, фактически это один из критериев приемки сборки в тестирование. Обычно начинается с того, что сборка запускается, кто-то пробегается по вкладкам/формам (если они есть) опять-же, без проверки функциональности, просто смотрим что формы отрисовываются вроде как надо и ничего при этом не взрывается, иногда туда может добавится что-то, что отламывают через 2 сборки на третью.
Еще один способ формирования смок-тестов: "Вот вам сборка, ответьте через 5 минут берете ли вы ее в тестирование? и если нет, то почему".

 

 

 

"QA Lead" по логике отвечает за команду тестировщиков, а "QA Manager" за построение процесса тестирования (Хотя, повторюсь, границы весьма размыты от компании к компании)

наоборот, лид это типа старшего тестировщика, строит процессы и менторит

 

а менеджер управляет командой

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

 

Вы не с той стороны заходите.

Вам надо разбираться что делать, а вы пытаетесь понять чем делать, не зная что именно делать.

 так вродебы суть задачи ясна и понятна. Узнать сколько работает каждая из команд. Ребят не душите XD если не сложно подскажите каким софтом это делать , а я уж потрачу время на импрув

Дежурные телепаты как обычно в отпуске.
Задача стояла как протестировать производительность не веб приложения.
"Не веб приложение" - это такая неебическая никому не ведомая хрень, которая что угодно. Я думаю за изобретение инструмента тестирующего производительность "не веб приложения" можно получить нобелевку и возможно даже не одну.

поэтому давайте вернемся в нашим баранам:

1) что такое производительность нашего "не веб приложения"?

2) в чем она измеряется?

3) как она измеряется?

И вот тут уже круг чем бы нам ее померять будет достаточно узок.

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

Если это все еще не очевидно, деление на веб и не веб несколько ущербно. Это как бытовую технику делить на пылесосы и не пылесосы - годится только пока вы работаете исключительно с пылесосами.

Так что, для получения адекватного ответа надо сформулировать что за приложение и ответить на 3 вышеупомянутых вопроса (ответить - в смысле найти ответ)

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