А из чего именно вы делаете такие выводы (лень, нерасторопность, немотивированность)

Должен был сделать позавчера, а сделал только сегодня? Баги пишет непонятно? Баги пропускает? Тест-кейсы не покрывают функциональность? Энтузиазма не проявляет, глаза не горят? :)

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

а у xpath вот да, яркое преимущество, что можно искать внутри чего-то (".//div...") Если этого не надо, то css быстрее, вроде. Так считается )

Это надо как-то разработчиков фронта трестируемой системы заставить id элементам лепить, с которыми может взаимодействовать пользователь.

Просто если этих id нет, тогда и приходят на помощь xpath и css

Just for my education, а что, можно, к примеру, в данном форуме добавить заранее известные айдишники элементам, которые содержат ссылку на профиль комментатора в теме? (скажем, мой ник в этом сообщении)?

-- Не буду. Злой я сегодня ---

Прошу извинить за нескромный вопрос и отклонение от темы, а когда вы добрый?

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

Любопытно хоть один юзкейс с Канвой увидеть О_о

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

Почему вы так думаете?

По вопросу саморазвития, опять же, не бывает тестировщика крутого в вакууме. Вы хотите дорого стоить? Быть гуру на форуме? Учить других? Это все разные цели. Можно быть универсалом, можно узким спецом, тут что кому ближе (см. теорию о сканерах и дайверах). 

Вообще считается, что надо найти некую волшебную область, которая вам очень понравится или - того хуже - Ваше Предназначение, и все пойдет как по маслу, но на самом деле это миф, не более правдивый, чем о половинках мэ и жо. Книга Кэла Ньюпорта   "Хватит мечтать, займись делом!" отлично ставит мозги, правда насчет главы про девушку-тестировщика я бы сама ему сказала кой-чего :) но он не практикующий айтишник, а профессор математики, так что ему позволительно. 

 

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

 

Подскажите пожалуйста, где можно попрактиковаться по тестировании api?

https://jsonplacehol...icode.com/posts - бесплатный сервис, который можно использовать для тестовых запросов.

http://software-test...ls/2638-postman вот тут, например, объясняют, с чего начать, выучите по этой статье басик, а уж потом можно практиковаться в свободном полете. Или какой-нибудь онлайн курс пройти, хотя бы вот этот https://www.udemy.com/api-postman/ или еще что найдите (udemy просто платформа очень хитропопая).

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

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

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

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

Что за слово такое - колдунщик? Это на каком языке?

Тест-кейс №1. Появление колдунщика по запросу.

Шаги:

1. Открыть браузер.

2. В поисковой строке ввести "переводчик онлайн".

Результат: 

Отобразится колдунщик онлайн переводчика.

 

вы уверены, что это не тест поисковой системы ))

Спасибо всем за ответы.

1) это просто, можно удалить в своём 

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

 

1) Оказывается эта фишка в ФФ не работает, а я думала, все знают какой-то секрет. Пришлось в Хром переехать. Ну да ладно. Спасибо большое.

2) О, точно кстати. JWT же можно распарсить и завалидейтить. приложенька в браузере для этого есть, значит и библиотечка найдется :) 

MissLeman, как Вы иначе пройдете авторизацию oauth2.0 без UI? Я бы первый тест сделал авторизацию через UI, остальные тесты через api. Авторизация не прошла, тесты не гоняем. Можно первый тест засунуть в подготовку ТД.

Ну да. Эта штука с согласием пользователя только в одном гранте. В остальных (password, client_credentials) UI не требуется, там грант получается через один запрос. Но это, как я уже говорила, только пример.

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

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

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

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

Я бы начал с ответа на вопрос "А зачем" и посмотрел, оправдывает ли цель все сопутствующие сложности.

 

У нас, как и в вашем примере, это, скорее всего войдет в приемочное тестирование.
Ну и я пока в процессе, посмотрю, как оно пойдет. Руками это все проверять тоже удовольствие из средних.

(пример теста - в браузере открываем УРЛ, пользователю отображается окно "Вы согласны предоставить приложению такому-то доступ к таким-то данным?", пользователь жмет "Согласен", дальше в УРЛ получаем авторизационный код, с его помощью access token (через oauth api), а затем с токеном через рест апи проверяем выполнение каких-то действий. но это не единственный тест, где требуется сочетание действий апи и ui).

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

 

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

Знаю  по опыту знакомого можно работать в питере за 40-60 тыр ручным - никто толком за тобой не следит, главное не сдавай задачи совсем не тестируя. Можно задачи делать по принципу половину времени делаю задачу половину хрен пинаю ибо тебе виднее сколько они занимают. 

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

Но это только один такой расклад знаю.

Очень много где такое, к сожалению :(

Не очень понятен вопрос, что вы понимаете под фразой "правильно написать автоматизированный тест"?

Эффективно. По фэншую. Да даже здесь на форуме вон недавно был вопрос - хочу тестировать апи селениумом + как-то там еще ужасно, человеку покрутили у виска и написали: гуглить вот это, делать вот так. Не хочется, образно говоря, как в той байке, надевать штаны с разбега, чтобы потом узнать, как это делают нормальные люди.

А так ничего не мешает, конечно, у меня описанный мной тест тоже укладывается в 6 строк.

Как правильно написать автоматизированный тест, где одновременно есть действия на UI и запросы через API? Можно ли задействовать в одном проекте, скажем, Frisby и Protractor? Не будет ли это монстр.

(пример теста - в браузере открываем УРЛ, пользователю отображается окно "Вы согласны предоставить приложению такому-то доступ к таким-то данным?", пользователь жмет "Согласен", дальше в УРЛ получаем авторизационный код, с его помощью access token (через oauth api), а затем с токеном через рест апи проверяем выполнение каких-то действий. но это не единственный тест, где требуется сочетание действий апи и ui).

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

Я сам из Питера. Самое интересное, что там есть имхо это Lesta Studio, Saber Interactive - самые крутые проекты + проекты на игровых консолях. Так то наверное на игровых консолях Saber в Питере.

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

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

Я проделывала такой финт два раза, правда, с другим направлением развития.

один из неочевидных, но работающих путей - это уйти в компанию, где проджект-менеджеры вырастают из тестеров. поузнавайте в своем городе. у нас например таких две. там, как правило, этот финт уже отработан и обкатан.

из литературы, меня как-то занесло на курсы ПМ-ов в своей конторе (правда, столь же быстро оттуда и вынесло), но помню советовали:

- Голдратт, Цель и Цель-2

-Том Демарко Человеческий фактор (и вообще у него много хороших книг)

Запомнился кстати совет оттуда же, который нам дали одним из самых первых и на полном серьезе:

- Ребята, сразу начинайте искать для себя собственные способы расслабляться: спорт, шоппинг, медитация, а то сопьетесь

Дык кто его посылал. Вопрос конкретизировать хотели. Если автор не умеет/не любит пользоваться Постманом - это одна проблема. Если не умеет тестировать АПИ вообще - другая.

Т.е. беда в том, что медленно продвигается написание автотестов, а не тестирование фич, как я понимаю.

Взялись - делайте, он же и спрашивает, как сделать. Правда, я ничегошеньки не понимаю, что именно у автора не получается :)

Вы имеете в виду, что у вас медленно идет процесс автоматизации? Или вы не отдаете фичу в релиз, пока не напишете для нее автотесты? )

Чтобы ответить про ЗП, надо знать как минимум локацию, но вообще, чисто по моему опыту, требования к джуну-автотестеру или такие же, как к джуну-программисту, или ищут более-менее опытного мануального тестера, а возможность "развиваться в автоматизации" предлагают ему как плюшку, т.к. считается, что все туда хотят (спойлер - на самом деле нет). Я это к тому, что даже для должности автотестер джуниор немножко уметь кукумбер недостаточно :)

А в чем проблема-то?

Не хотите постман - можете, например, писать запросы в Visual Studio Code и запускать с помощью экстеншена Rest Client, в некоторых случаях это удобнее.