chmod-нуть бы его еще, скриптик-то..

Прочитал, но так ничего и не понял. 

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

Тестировать игры != играть в них за деньги :)

 

 

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

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

 

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

Василий, ханть, человек с головой и за дело болеет :) Это уже половина успеха.

О, люди снова обозвали бардак аджайлом? :)

 

Виноват аналитик, к тестировщику вопросы минимальны.

Ну дык это.. смотрите консоль. Почему валятся-то?

Дамы и господа, в продолжении текущей темы, прошу подсказать с какого языка программирования можно начать, чтобы голова сразу не пухла и адекватно от одного к другому? Заранее спасибо )

Python

Добрый День!
Цель такая: проверка регистрации( заполнение  поля уникальным email)
Сейчас сделал  автоматическую генерацию почту  по дате + времени - это работает
Вопрос в том как перехватывать код из письма отправленный на эту почту? такое вообще возможно?

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

1. Вы просите поставить заглушку вместо отправки почты, и ловите код в каком-то файле или другом интерфейсе на вашем сервере

2. Гуглопочта имеет встроенную "фичу" - все ящики вида yourmail+sometext@gmail.com являются вашим ящиком yourmail@gmail.com. Т.е. вы можете регать почту в вашей системе вида yourmail+timestamp@gmail.com, затем логиниться на yourmail@gmail.com и смотреть, что туда пришло.

Получение кода должно выглядеть как-то так:

String code = RestAssured.
when().get("url").
then().statusCode(200).
extract().path("code");

 

Jenkins, TeamCity и прочее

 

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

А какое отличие у них? С чего проще было бы начать - Jenkins или TeamCity?

 

Попробуйте с jenkins, по нему хотя б ответов на stackoverflow побольше :)

Jenkins, TeamCity и прочее

При всем уважении - API-тесты описаны тут принципиально неверно. Это Integration, который вообще не факт что про API.

В современных системах шо API, шо GUI - как правило, системное тестирование приложения/сервиса через определенный интерфейс.

 

А так, судя по статье - проверил джун ячейку отчета, строку отчета, весь отчет - и у него Пирамида!

Это все хорошо, но..

Потом оказывается, что у пользователя логин на компе ジョン, и ваше приложение валится при запуске.

 

Начни с Java

Начни? А потом что, еще штук пять выучить? Ну и вроде как java умирает вроде. Да, много чего в "enterprise" все еще на ней завязано. Но такое чувство что это останавливающийся поезд. В среде windows майкрософт ее вытолкнула своим C#. На мобилках тоже, на андроид гугл продвигает вместо явы kotlin, а на ios - swift. В вебе тоже, typescript, новомобный pyton и тд

 

Java уже лет 20 "умирает". 

Python примерно такой же "новомодный".

И они вдвоем занимают процентов 80 всей автоматизации. Поэтому для начала надо выбирать один из этих языков. Затем учить второй.

Потом JS/TS.

Потом все остальное. 

Начни с Java

окей.. какую площадку не жалко? :)

Можно найти абсолютные XPath-ы для обоих элементов и потом их сравнивать.

Стандартной функции нет, stackoverflow предложил что-то подобное https://stackoverflo...element-in-java

Говорят, что есть https://octoperf.com...ter-assertions/

Бэкенд будет написан на C#. Но вообще из всех языков программирования мне больше нравится Java. Насколько я понимаю, это универсальный язык для автотестов. Спрошу у руководства, какой язык будет использован для API. Если что - подтяну C#. 
 
Выходит, если внедряется автоматизация на микросервисах, то сначала API через Postman, а потом уже UI через Selenium?

Значит, у вас .NET, и автоматизировать вы с большой долей вероятности будете на C# или еще чем-то, что компилируется в .NET
Если java-компонентов нет в вашей системе, то никто не будет поддерживать JDK, закупать IDE и прочее только ради ваших автотестов.

Скорее всего, вам эффективнее будет тестировать микросервисы через API, а все остальное в виде UI - просто руками.

 

Не трогайте десктоп, это вообще отдельный мир автоматизации.

 

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

 

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

Смотря на чем написан бэкенд и какую инфраструктуру вам могут дать под автотесты.

 

Изучать язык программирования однозначно нужно. Какой именно - см. выше. "Единственно верного" ответа здесь нет.

Не трогайте десктоп, это вообще отдельный мир автоматизации.

 

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

День Добрый, подскажите пожалуйста где создавать резюме для Junior QA тестировщик , я так понимаю в ворде но сохранять в pdf формате?

Здравствуйте, Станислав!

Место, где все создают резюме - hh.ru

 

Но если у вас есть такие вопросы (и так сформулированные), то, полагаю, вам не помешало бы пройти еще какие-то общетехнические курсы.

Привет.

В этой статье "Тестируй не числом, а умением" рассказано, что уменьшить количество тестов можно, применив Попарное тестировние и Тестирование сочетаниями по N.
Для Попарного тестриования можно воспользоваться алгоритмом PICT. Попарное тестрование - это N=2.
А какой алгоритм составит сочетания по N=3?

Рекомендую ACTS https://csrc.nist.go...ng-for-software

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

<шутка>

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

</шутка>

 

А если серьезно - то это не вид тестирования. Это, в общем-то обычный результат тестирования: найденная проблема. А то, что в документации не было - ну так документация не может покрыть вообще всё, плюс к тому есть и неявные требования.

Отправляете запрос, получаете токен, токен передаете в api. Все, что можно тут сказать - надо читать документацию к конкретной системе