Там в описании процедуры апдейта БД еще есть "WARNING: if you are using a table prefix replace prefix with your prefix"

Хорошее начальное обучение - это
https://online-learn...science?delta=0
говорят есть на русском

 

Что смешно — у опытных тестировщиков те же проблемы, слишком опытный стоит слишком много, слишком умничает, не хочет нам тут всё аффтаматизираватЪ, возражает, спрашивает, какие-то тест-кейсы пишет… А вот джун, который был до тебя, делал всё быстро и вопросов не задавал, и баги находил… А ты вот нет…

Люто плюсую, мое самое больное место. Доказать что я стою в полтора-два раза больше чем тот кто фигачит тесты вдвое быстрее меня. а потом еще и смочь нанести пользы на означенную сумму.
Сколько автотестов вы написали на этом проекте? - Три сценария. за 2 недели. И эти тесты находили баг примерно раз в 2 недели. на протяжении полугода.
А у вас 2000? половина из которых регрессионные на найденные вручную дефекты, которые не принесут пользы никогда.  да они еще и мерцают и требуют постоянной поддержки. А покрытие какое? не строк, требований, примерно 70? Ах не знаете как посчитать требования и их у вас вообще нет как единого артефакта. А нанимаете зачем? чтобы больше тестов писать? морщусь потому, что вы мне только что сказали что у вас стратегии тестирования нет. Нет "быстрее, выше, сильнее" - это не стратегия.

С одной стороны это вроде бы звучит как справедливое требование - ведт  тестировщик на тои тестировщик, чтобы находить несоответствия

 

несоответствия чего с чем?
Если ожидаемый результат тестировщик должен доставать из заказчика - значит аналитик филонил.

 

 

 

Самое тупое что может быть - свалить все на тестировщика.

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

 

А вы не пробовали сменить работодателя?)

 

да вот уже подумываю))) хотела получить луч надежды, что таки есть места, где работа налажена)))

 

В вашем случае не с процессами проблема, а с мудаками. Процессами это не лечится.

 

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

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

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

Всегда легко уйти)

 

Но хочется попробовать сделать что-то. Работа в плохом проекте тоже опыт и тоже работа)

 

Может вы посоветуете какие-нибудь активности? Чем еще можно заниматься кроме тест сценариев и самих тестов?

Спасибо за совет!

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

изучайте технологии с которыми работаете и ищите потихоньку другой проект.

интересно, как скоро мы дойдем до машинного анализа цифрового следа и выявления "зачисток" :)
У меня оооооочень развесистая цифровая история. И я не очень помню чтобы мне за какие-то мои интересы было стыдно.

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

так там один ожидаемый результат: "Сохранение отменено"(Диалоговое окно закрылось, Файл не изменился, кнопка сейв активна).

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

Ну и раз уж платеж совершен, то приходит не подтверждение заказа, а подтверждение покупки.

 Ага, без контекста это помидор в форме апельсина

1) Чтоб понять что такое эффект пестицида надо в него пару раз влететь и разобраться как именно баг проскочил мимо тестов. В любом случае, это всегда продолб или отсутствие аналитики.

2) Опыт. Хорошая документация. Грамотный анализ документации. покрытие требований тестами. Мы никак не можем сказать что мы рассмотрели все ситуации, можно только перечислить что мы провеили.

3) находят ли дефекты пользователи?

https://octoperf.com...ter-assertions/

Доброго времени!

 

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

 

Прошу знатоков этого вопроса ответить на правильность моих суждений в части реализации (TestNG) и применимости.

 

Реализация -> все тестовые классы наследуются от БазовогоКласса, в котором было:

 

protected static final AppManager app = new AppManager(System.getProperty("browser",BrowserType.FIREFOX));

@BeforeClass(alwaysRun = true)
public void setUp(ITestContext context) throws Exception {
app.init();
context.setAttribute("app",app());
}

@AfterClass(alwaysRun = true)
public void tearDown() throws Exception {
app.stop();
}

 

ниже, мои переделки для многопоточного запуска:

 

private static ThreadLocal<AppManager> thread = new ThreadLocal<AppManager>();

public static AppManager app() {
   return thread.get();
}

@BeforeClass(alwaysRun = true)
public void setUp(ITestContext context) throws Exception {
   //System.out.println(Thread.currentThread().getName());
   thread.set(new AppManager(System.getProperty("browser",BrowserType.FIREFOX)));
   app().init();
   context.setAttribute("app",app());
}

@AfterClass(alwaysRun = true)
public void tearDown() throws Exception {
   app().stop();
}

 

Плюс я настроил запуск нескольких потоков через xml

 

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd" >

<suite name="Suite1" verbose="1" parallel="classes" thread-count="3">
       <test name="Contacts">
           <classes>
                 <class name="il.javatesting.addressbook.tests.ContactCreation" />
                 <class name="il.javatesting.addressbook.tests.ContactDelete" />
                <class name="il.javatesting.addressbook.tests.ContactModification" />
           </classes>
       </test>
</suite>

 

Проблемы с которыми я столкнулся: есть множество тестов, которые на выходе делают сверку состояния всей базы до ТЕСТА с состоянием  после ТЕСТА с учетом изменений(поменяли имя, значит проверяем имена всех пользователей до этого изменения с учетом того, что этот пользователь уже с другим именем). !!! НО, если все течет в многопоточности, то за время ТЕСТА могут пробежаться другие тесты и , конечно , такая проверка не пройдет.

 

Отсюда вопрос, для чего нужна многопоточность в тестах (только, чтобы узнать предельные нагрузки, хотя как это реализовать без облака?), или у меня неверный подход к многопоточности?

 

Заранее благодарен за ответ по части реализации и применимость многопоточного тестирования

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

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

Возможно HR захлебывается в потоке откиков, поэтому ставят предварительный фильтр.
В одной из компаний, в которых я работал, Был предварительный асессмент опросник по джаве, вопросов на 10. и тестовое на собесе. Так вот, тестовое выносили в предварительное при наборе джунов/стажеров ибо там без него конверсия у HR была меньше 0.01.

Когда работа ищет тебя, то тестовое не бывает до собеседования.

И начинайте ходить по всем собеседованиям, пока зовут (в 43 уже перестанут). Там поймете, что важно, а что нет.

Таки я с вами категорически не согласен! Не перестали.

Топикстартеру.
У вас есть опыт. проблема в том, что он:
1) специфичен.
2) не поименован терминами принятыми в обществе.

Соответственно:
глоссарий istqb и классификация по нему того, что вы делали.
собеседования и проработка непонятных вам требований.

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

Facepalm driven development?
У меня есть хороший образец Экселевской таблицы в фомате xls. Пишите в первый столбец критерии приемки а во втором отмечаете фэйл или пасс.
А потом еще можно следующую версию в третьем.
А потом добавить сверху строку и писать в нее версию которую проверяли.

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

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

А потом можно статистики собирать, но это уже адвансед.
 

Для осознания принципа работы с терминами и наступления просветления настоятельно рекомендуется к прочтению:
https://testitquickl...0/termimimitre/

используй Хуки.
https://www.baeldung...-cucumber-hooks

Есть контекст исполнения теста он может хранить переменные или объекты, реализация зависит от языка имплементации.

 

Есть контекст исполнения теста он может хранить переменные или объекты, реализация зависит от языка имплементации.

 

 

https://cucumber.io/...ep-definitions/

 

привет. спасибо.

как вы относитесь к такой штуке, как PicoContainer ?  (https://cucumber.io/...cucumber/state/)

Подходит? используйте.

тесткейсы решают разные задачи.

1) передачу знаний

2) единообразность/стабильность тестирования разных версий

3) включение в работу джуниоров/ клиентов/ прочих некомпетентных людей.

4) Составление отчета о тестировании

5) Оценка покрытия.

6) Трассировка дефектов на требования.

Хорошая школа https://www.m2p.education/ но это не про игры.
Больше чем с половиной команды я вместе работал и преподавал во внутренней школе  Grid Dynamics. И с выпускниками школы потом тоже работал.

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

я вижу:
окно,

элементы управления окном,
поле ввода
кнопку
текстовое поле

У каждого из этих элементов есть функциональность, то что она не описана не значит что ее нет. всегда есть пирамидка "Требования, класс систем, здравыйсмысл." Не описано в требованиях?, А как это сделано в подобных системах? подобные системы неизвестны? А для чего оно? что оно должно позволять? что не позволять? какие сценарии использования?

ЗЫЖ  "тестирование поля ввода" вполне себе гуглится.
ЗЗЫЖ в результатах поиска стоит особо выделять результаты на сайтах testitquickly.com blog.shumoos.com и habr.com. сайты всевозможных школ тестирования скорее содержат статьи для правильного индексирования сайта, нежели для объяснения людям концепций.

В/О тебуют гос и около структуры. Либо компании где цена ошибки - жизнь (авиа, авто, медицина).
Остальным пофиг, даже если в вакансии прописано.

Даже, если указывают высшее образование, то его никак не проверяют (про гос.компании не знаю). Зато знаю людей, которые покупали дипломы или просто врали в резюме, что имеют высшее образование и при примере на работу это не всплывало.

Это какие-то совсем шаражкины конторы. При нормальном оформлении на работу документ о образовании (диплом/аттестат) нужен обязательно.

Привет! Пишу автотести для API. Начала все это дело по старинке - новый проект, сама написала модели, ендпойнты, реквести, респонсы.. НО.. девелоперы сказали что это полнейшая ерунда, вручную писать все эти вещи плохо, выдали сгенерированный клиент и сказали пользоваться.

Клиент генерили через nswag, в проект добавила его как nuget package. 

В самом клиенте есть:

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

2) методы для работы с ендпойнтами. выглядит ужасно, некоторые методы принимают 10-20 входящих параметров, пользоваться крайне неудобно, как представлю что нужно передать (null, null, null, null .. и еще несколько раз null, "something") аж передергивает.

 

И собственно вопрос: это я отстала от жизни и нужно переучиваться или предложили штуку, бесполезную для написания автотестов, но класное решение в девелопменте? 

Скорее второе.
Для того чтобы не писать вызовы с кучей null нужно обернуть вызов методом принимающим список параметров в мапе и все недостающее заменяющий дефолтными значениями.
как подменять типы полей с ходу не скажу

Что-то я в Вашем комменте не вижу ответа на свой вопрос. 

 

Тесты в отдельном репозитории, пишу их независимо от девелоперов, ревью нет.

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

потому, что его там нет :)