Молодое поколение подтягивается))

Так я в деле?)

Что дальше-то?)

Приветствую. Мое имя Максим, мне 17 лет.

•  Почему вы выбрали именно тестирование?

Я учусь на специальность "Компьютерные науки" или же как говорят в народе, на "программиста". Но с программированием у меня дело не сложилось. Я немного шарю в этом, но сложные задачи решать не могу. На пол года было забросил своё саморазвитие, но потом вспомнил, как к нам в колледж приходил Senior QA и проводил лекцию о тестировании. Оставил нам ссылку на книг Савина "Тестирование дот ком" и укатил в столицу делать деньги.  Я, конечно же, как и остальные 30 человек (половин из моей, половина из параллельной группы) почитали пару страниц и забросили это дело. Перед зимней сессией 2019 мой друг программист сказал, что к ним в компанию приходит много тестировщиков на стажировку и сказал мне тоже попробовать. И я взялся за книгу Савина. Буду максимально откровенен: я захотел дальше развиваться в этом плане не потому что чувствую, что это мое призвание, а потому что мне было интересно читать книгу и я очень сильно заинтересовался. Да и к тому же, надо как-то в будущем на хлеб зарабатывать)

•  Какие книги/курсы по тестированию вы изучили?

Р.Савин "Тестирование дот ком".

Курс по от Технострим Mail.ru.

Завтра-послезавтра загляну на курс Портнова(многие рассказывают о нем(сегодня поздно, пишу это в 22:00)).

•  Какие области вы изучили самостоятельно?

HTML,CSS, изучаю веб тестирование.

Спасибо большое, я вас услышал. Теперь осталось у кого-то админку выцепить :D

можно разложить веб-аппликацию у себя на машине например, ну или лучше в AWS облаке, и тестировать ее

это не так сложно, есть много туториалов, зато сразу получите понимание как что работает

ищите веб-аппликации которые сразу упакованы в докер

Если я правильно понял, то вы предлогаете скачать готовый веб-проект и чтобы я установил его у себя на ПК?

вообще наверное предлагаю пройти туториал по докеру, это займёт 4 часа

получите кучу нужных знаний

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

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

я вот этот проходил, но их много, и на русском есть
https://docs.docker.com/get-started/

Можете потестировать прямо тот сайт, на котором сейчас находитесь — software-testing.ru

вообще внешние сайты это неподконтрольное ПО, на таком и тестировать никогда не научишься

 

Ммммм, а сами-то что? Как процесс гугления, уже не в моде? Что вы уже нашли/узнали/сделали по этим вопросам?

https://www.youtube....естирование api

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

 

Посмотрите видеоролики о тестировании API и тогда более-менее будет понятно.

Вы мыслите верно, но странно))
.
 

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

 Вы пишите, что все спроектировано верно и проверять, как будто и не надо. 

Я не это имел ввиду. Я просто хотел поделиться своими мыслями, получить комментарий по поводу них. Книга Р.Савина о тестировании сайтов и я понятия не имел, как тестировать автомат, по-этому я просто решил тестировать "физически". 

П.3 - • А что, если покупатель попробует наклонить аппарат, чтобы банки посыпались как из рога изобилия?

Самому мне надо будет наклонить автомат и проверить, посыпятся ли банки. Если да, то передать инженерам, что бы доделали конструкцию, так ведь? :)

Если я попал в тот раздел, куда нужно, то помогите.
Скажите, пожалуйста, правильно ли я понял и выполнил задачу из книги Р.Савина "Тестирование dot com".
Вот сама задача:

Окей, приступим.
1.)Моя мысля, что бы проверить, ту ли банку с напитком выдал автомат такова: как бы глупо это не звучало, но проще всего, можно определить физическим способом, вставив монетку и выбрав напиток.
2.)Если покупатель нажмет кнопку два раза: продюсеры и программисты точно не дураки, которых так просто обведешь вокруг пальца, по-этому вполне логично, что в автомате должен быть закодирован предохранитель на такие случаи.
3.)Если я думаю, то это уже берет на себя техническая часть автомата, то бишь его конструкция, строение.
4.)Должно быть устройство в автомате, которое различает номинал купюр/монет и калькулятор, который делает расчеты?(Да, это вопрос!) Если да, то так же должно быть устройство, которое на основании расчетов, выдает сдачу. Если же она выдана неправильно - отремонтировать алгоритм.
5.)На любом автомате изначально написано, какую валюту он принимает. Датчик, по-идеи, должен распознавать только свою валюту, валюту своего автомата, любую другую игнорировать. Автомат - это же не обменный пункт.
Все случаю можно без всяких проблем протестировать физически, стоя лицом к автомату. Хоть на это и понадобятся средства. И только из-за траты средств, мне кажется, что все, что я написал выше - полный бред.
Я абсолютно не уверен, что я что-то написал правильно, но это все, что пришлом мне в голову. Так бы я тестировал автомат физически, забрасывая в него монетки.
Над тест-кейсами буду думать позже, так как категорически не уверен в своих нынешних мыслях.
Строго не судите, пожалуйста.

на самом деле, это достаточно сложная задача с большими рисками и большим количеством кейсов.

 

"1.)Моя мысля, что бы проверить, ту ли банку с напитком выдал автомат такова: как бы глупо это не звучало, но проще всего, можно определить физическим способом, вставив монетку и выбрав напиток."

 

 

 

я даже не беру в расчет, что может надо будет кидать несколько монеток в автомат для покупки банки с колой. Упростим, все напитки стоят по 1 рублю и автомат принимает только 1 рубль.

 

Интересная мысля, возьму на вооружение, спасибо :)

на самом деле, это достаточно сложная задача с большими рисками и большим количеством кейсов.

 

"1.)Моя мысля, что бы проверить, ту ли банку с напитком выдал автомат такова: как бы глупо это не звучало, но проще всего, можно определить физическим способом, вставив монетку и выбрав напиток."

 

 

 

 

Как кидать монетку ? Реверсом или аверсом, кидать быстро или отпускать медленно, кидать скраю приемника или по центру, т.е. вариантов очень много

Я не понял, к чему это? Вы что-то хотели донести? В задачке не было вопроса по поводу того, как бросать монету.

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

В моем понимании, API - это набор функций. Апи может быть как одно, так и несколько, в каждом Апи есть n-ное количество функций. 

То есть, получается, что тестирование API - это, в каком-то роде, интеграционное функциональное тестирование(или просто функциональное тестирование(если рассматривать функционал в одном Апи)? 

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

Am i right?

 

 

То есть, нам не обязательно проводить негативное тестирование внешного АПИ, достаточно удостовериться, что все работает правильно?

 

 

Давайте еще раз убедимся что понимаем друг друга верно:

1. Ваше внутреннее АПИ - это ендпоинты, предназначенные для работы внутри вашего приложения --- Тестировать важно
   1. Проверяется работоспособность АПИ внутри вашего приложения
2. Ваше внешнее АПИ - это ендпоинты, предназначенные для работы с вашим приложением извне(например, если почта или платежная система, это вы) --- Тестировать очень важно
   1. Проверяется работоспособность АПИ как внутри вашего приложения, так и с приложениями извне. Чтобы системы извне могли успешно работать с вашими "ручками", при этом не имея возможность вам навредить или получить закрытую информацию
3. Публичное АПИ(не ваше, то есть АПИ почты. кинотеатра, платежной системы, и тд, которые вы как-то используете) - это ендпоинты third-part системы, предназначенные для использования в каких-то целях --- Как правило не тестируется
   1. Потому что это third-part система, а их не тестируют. Вы ж Джиру или Гит не тестируете :)

Сложно ли понять на практике, где наш АПИ, а где сторонний?

 

 

Как правило на проектах используется какой-то инструмент для документирования API(такие как Swagger, например), который позволяет увидеть все ваши ендпоинты, их схемы и используемые модели. А сторонний АПИ, ну, он вам не принадлежит, и не входит в список ваших апишек, так что думаю да, разработчики ваши с этим трудностей испытать не должны :)

 

Вы так четко все объясняете. Курсы ведете какие-то?)

 

 

Нет, просто работаю в этой теме и интересуюсь :)

 

 

Когда я вел с вами эту беседу - еще очень мало знал об API.

Сейчас я пересмотрел множество видеоуроков и уже примерно понял что и к чему. Спасибо вам большое за то, что уделили мне своё время :)

Привет!

На конференциях часто слышу термин "крутить ручки". Т.е. дергать те или иные АПИшки. Этот оборот очень хорошо раскрывает то, как работает АПИ.

Детальнее: Бэкенды пишут бэк. Фронты пишут фронт. Вторым нужно что-то, через что можно общаться с бэком, т.е. слать/получать/изменять/удалять данные.

Для этого нужен какой-то интерфейс. API(endpoint) - и есть такой интерфейс(Application Programming Interface).

 

Так как все нагляднее на примерах, вот два варианта АПИ с внешними интерфейсами("ручками" торчащими наружу:)

1. Всеми нами любимый пример - автомобиль.

Современные авто - это уже очень серьезные технологические вещи, внутри крепко напичканные самими разными агрегатами и механизмами. Тонкости работы большинства из них нам не неведома, да и не должна быть. Так вот все, что происходит условно "под капотом" - это бэкенд. Фронт - это красивая приборная панель, которую видит водитель. АПИ в этом случае - это точки под капотом, куда подключаются провода, идущие на приборку.

 

Но это закрытое АПИ. Что тогда тут будет внешний интерфейсом?

В любом современном авто есть специальный разъем(ODB), куда можно подключить внешние системы диагностики, или другие приборы, получающие информацию "из под капота" в обход приборной панели. И получить можно куда больше информации.

 

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

 

2. Интеграция почтовых сервисов и онлайн магазинов(по аналогии с кинотеатром и платежкой).

Думаю все мы когда-то заказывали что-то онлайн, и в конце указывали отделение почты, куда бы ты хотел оформить доставку. Так вот вопрос? Откуда эти онлайн магазины знают всю информацию о всех почтовых отделениях, их адресах, названиях, актуальном списке, ведь они все время меняются? Не нанимать же онлайн магазину специального человека, который будет сидеть и актуализировать эту информацию? Конечно нет:)

 

У почты есть сайт(бэк + фронт), и бэк дает пользоваться определенными интерфейсами кому угодно. Такими интерфейсами может быть как раз та самая информация о почтовых отделениях, их адресах, названиях, актуальном списке. Онлайн магазины просто используют АПИ почты в рамках сотрудничества. Более продвинутые почтовые сервисы делают целые виджеты, которые может добавить себе на сайт кто угодно, чтобы упростить работу с оформлением доставки. Почему это выгодно? Онлайн - магазин решает проблему доставки товара, Почта - имеет площадку для рекламы и распространяет свои услуги. По этому очень важно поддерживать внешние АПИ в актуальном состоянии, если от этого зависит бизнес.

 

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

 

Зачем нам тестировать АПИ?

Чтобы удостовериться, правильно ли работают "ручки", используемые внешними модулями. Так как АПИ - это по сути JSON схемы, они должны быть правильно описаны. Если схема говорит, что поле принимает int или bool, значит нужно проверить, что это так и есть. Это очень кратко. Тема тестирования АПИ это совсем отдельный разговор :)

 

 

Что касается интеграционного тестирования.

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

Окей, тогда тестирование АПИ ( как я понял ) - тестирование конкретного модуля и, в каком-то роде, это тестирование бэкэнда.

То есть, если брать к примеру автомобиль, то тут будет два тестирования АПИ - АПИ двигателя и АПИ всего остального.

В случае онлайн-магазинов это будет тестирование АПИ подсказок адресов, тестирование АПИ платежной системы и тестирование АПИ конкретно нашего сайта.

Верно?

Значит играю сo SWAPI(API о вселенной Звездных Войн) и хочу получить фильм по GET-запросу. Вроде бы все просто, в документации написано, что найти фильм можно по атрибуту title. Окей, без проблем. Делаю значит следующий запрос: http://swapi.dev/api/films/?search=A New Hope

Но сервер возвращает мне следующее 

{

Что я делаю не так, подскажите, пожалуйста?

 

 

GET /api/films/?search=A%20New%20Hope

Спасибо большое. Что это за магия?) Вместо пробелов ставить "%20"?

 

Нормальной доки на русском что-то не гуглится, начните с wiki https://en.wikipedia...ercent-encoding

 

Буду знать, спасибо большое :)

GET /api/films/?search=A%20New%20Hope

Спасибо большое. Что это за магия?) Вместо пробелов ставить "%20"?

Ну вы не расстраивайтесь, я видел только процентов 5 таких;) Обычно останавливаются на отрезке от 0 до 100, который любят давать на курсах и на всеми любимом Савине