• QA engineer, с чего начать?

    @azShoo
    Для начала давайте разберемся, что же такое QA? Понятие это довольно абстрактное, и в СНГ применяется зачастую в ином понимании, нежели в краях более отдаленных.
    QA - это обеспечение качества продукта, причем, в идеальном случае, на всех этапах разработки.
    Самое первое, с чем придется в большинстве случаев столкнуться QA Engineer`у это функциональное тестирование.
    Написание тестов по задачам и прохождение этих тестов., прохождение уже написанных, апдейт, заведение багов и прочее. В этом случае QA Engineer = Тестировщик. Для этого самое важное - хорошо работающая голова, умение читать задачи и задавать правильные вопросы: "А что если так? А если этак?".
    В зависимости от продукта требуются дополнительные скиллы -> в вебе своя специфика, в мобильных своя, в по - своя, в железе - своя. Ну и соответственно базовое понимание кода, работа с базой данных и прочее - тоже периодически понадобятся.

    Но, процесс обеспечения качества не заканчивается на функциональном тестировании, поэтому понятие QA шире, чем тестирование. Здесь мы уходим от банальных тестов по функциональным требованиям и переходим к анализу требований и документации (поиск узких мест в требованиях и реализации), юзабилити тестирование (поиск "косяков" в интерфейсах и функциональности), тестирование производительности и прочее.

    Отдельная часть - автоматизация тестирования. Здесь от компании к компании все по разному, и роль автотестера варьируется от "тестера который научился использовать тестовый фреймворк" до "полноценного разработчика, который автоматизирует то, что ему говорят тестировщики".
    Требования отличаются соответственно.

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

    Что в итоге?
    Мне кажется, что QA-инженер это тестировщик, который вышел в своей работе за рамки тестирования. Который работает над качеством продукта не только в плане "Требования выполнены - к продакшену готовы", а старается делать продукт лучше во всех отношениях, в первую очередь - для бизнеса, во вторую - для пользователя, в третью - для тех, кто этот продукт делает.
    Следовательно, я считаю что путь QA лучше всего начинать именно с тестирования (кстати говоря, в России понятия QA и тестирования почти всегда тождественны в умах не-тестировщиков).
    Что важно для тестировщика?
    Способность и желание разбираться в том, как это [продукт\фича\пр] работает сейчас, и как это должно работать.
    Так же стоит приготовиться много говорить "нет, так не пойдет" менеджерам и разработчикам.
    Ну и вообще, смириться с тем, что другие стороны процесса очень часто готовы действовать в ущерб качеству.

    Что хотят, что бы знал джуниор?
    1) представление о процессе разработки. Этапы, когда пора тестировать и все такое.
    2) представление о написании тестов: что представляет из себя тест-план, тест-сьют, тест-кейс, тест-степ, Definition of Done, Ожидаемый результат и тд.
    3) представление о том, что такое дефект: Severity и Priority дефектов, какие бывают; из чего состоит описание дефекта, и все такое.
    4) хотя бы общее представление о тест-дизайне: что такое, зачем нужен, какие есть практики.
    5) Базовые навыки SQL - селект, упдейт, работа с несколькими таблицами и все такое.
    А ещё хотят, что бы человек умел думать. Будь готов к задачкам на логику (которые туфта и ненужны) и к задачкам типа "Есть окно с кнопкой, посылает запрос: напиши тесткейсы" или "Протестируй карандаш".

    Как-то так.
    К сожалению, больше рассказал именно о тестировании, чем о QA в целом. :)
    Ответ написан
    2 комментария
  • API xhr/fetch/rest/soap альтернативы друг другу?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Автор, намешано конечно у тебя в списке.. ой-ой. Но если интересуешся веб-протоколами - посмотри
    еще на GraphQL https://graphql.org/ я думаю он очень интересен для современного разработчика.

    Еще посмотри на QUIC для общего развития https://cloud.google.com/blog/products/gcp/introdu... там интересно.

    REST - это вобщем-то не протокол а скорее философия или архитектурный подход к работе с http. У него - очень размытые границы в реализациях. И иногда сложно взять приложение и классифицировать что оно такое. Рест или не-рест. Рест использует коды ошибок из HTTP и поэтому существует только в слое http.
    В теле REST сообщения может быть что угодно. XML, JSON или просто текст. Неспецифицировано короче. Наивные попытки внести в рест спецификации появились сравнительно недавно. Рест хорошо интегрируется с балансерами и реверс-прокси (nginx).

    SOAP - это именно "протокол". Базируется на XML с жесткой схемой. Причем работающий почти на всех слоях сетей. Может на не только по HTTP но и по сырым сокетам бегать. Хотя в настоящее время - непопулярен. Типизирован. Имеет специальный файл спецификации (WSDL) который точно описывает все сигнатуры методов. Требует большой аккуратности в реализациях. И обычно никто не пишет SOAP клиент-сервер вручную а пользуются генераторами API. Часто используется в банках и крайне консервативных ведомствах.
    Ответ написан
    Комментировать
  • API xhr/fetch/rest/soap альтернативы друг другу?

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

    xhr, а конкретнее XMLHTTPRequest - Штука, с помощью которой изначально это можно было провернуть

    $.ajax из jQuery - обёртка над xhr для удобства использования.

    fetch - новое API, которое должно заменять xhr. Прекрасно работает во всех актуальных браузерах, но не в ноде.


    а soap и rest?

    Это уже на стороне сервера.
    SOAP никаким боком к ajax не относится, тк работает с XML.
    Это вполне стандартизированный протокол - подробнее можешь почитать, если загуглишь.
    Rest - набор рекомендаций, как следует делать API


    Или вопрос некорректен?

    Да, тк сравнивается тёплое с мягким - функции из Javascript, концепция, и серверные технологии.
    Но вообще да - SOAP тоже работает поверх http.
    Ответ написан
    Комментировать
  • API xhr/fetch/rest/soap альтернативы друг другу?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    У вас всё перемешано.
    AJAX (Asynchronous Javascript and XML) - общий принцип фоновых запросов из браузера к серверу с обновлением информации без перезагрузки страницы.
    XHR (XML HTTP Request) - способ выполнения фонового запроса в JavaSript.
    Fetch - более новый способ выполнения фонового запроса в JavaSript.
    SOAP (Simple Object Access Protocol) - протокол обмена информацией.
    REST (Representational State Transfer) - общий принцип взаимодействия распределённых компонентов приложения.
    Ответ написан
    1 комментарий