Задать вопрос
  • Как правильно организовать разработку (python git тестирование virtualenv)?

    sim3x
    @sim3x
    tdd flow
    spoiler
    2da3f8ee7a63429484c27297479644a6.png


    У питона есть https://docs.python.org/3/library/unittest.html - не нужно придумывать велосипеды

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

    $cat requirements.txt
    -r requirements/production.txt
    psycopg
    ....
    
    $ cat requirements/dev.txt
    -r requirements/base.txt
    ipython
    ....
    
    $ cat requirements/base.txt
    Django
    ....


    git flow
    spoiler
    b66e7a34e49d43b1a58bd35533659001.png
    Ответ написан
    1 комментарий
  • Добавлять ли virtualenv в git?

    @Stqs
    senior software developer
    Частенько бывает что часть пакетов нужна при разработке и не нужна на продакшене. И наоборот. Поэтому желательно бы еще разделять requirements для разработки и для продакшена.
    Файлы с requirements могут включаться один в другой. Таким образом обычно зависимости можно разделить на 3 отдельных файла.
    Например:
    reqs/
    - common.txt
    - prod.txt
    - dev.txt

    common.txt будет содержать все обязательные общие зависимости. Пример с потолка:
    Django==1.8.5
    mysql-python==1.2.5


    dev.txt будет содержать пакеты специфичные только для разработки но включая common. Пример опять же с потолка:
    -r common.txt
    ipyhton
    ipdb
    django-debug-toolbar==1.4


    prod.txt тоже будет включать common но так же содержать вещи которые на продакшене обязательны а в Вашем локальном окружении не нужны вовсе:
    -r common.txt
    gunicorn==19.4.1
    whateverelse=1.0.0


    соответственно когда мы собираемся разрабатывать мы устанавливаем зависимости так
    pip install -r reqs/dev.txt
    в продакшене
    pip install -r reqs/prod.txt
    Ответ написан
    Комментировать
  • Поставить процесс тестирования джуну с нуля?

    Самое банальное, что должен делать тестер.

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

    Из инструментов: Инструмент для раскатки ветов (например Ansible), Инструмент для регресса (тест-раил, например).

    Но опять же, лучше взять адекватного тестера, чтобы он вам поставил все изначально, а потом уже нанимать мартышек, чтобы они по сценарию работали.
    Ответ написан
    1 комментарий
  • Берут ли в студию Фронт Енда со слабым JS скилом?

    Demi44
    @Demi44
    System administrator, devops
    ИМХО - JS, Angular, Css, html5, composer = минимальный набор, ну и неплохо бы понимание азов backend, docker, virtual+vagrant дабы не выглядеть идиотом при работе на проекте с тестовой средой. У нас не далее как в пятницу попрощались в фронтом который величал себя разработчиком, но не смог развернуть тестовую среду, не имел понятия как залить себе на локалку дамп тестовой базы, подняли ему окружение на дев серваке - человек я так понимаю вообще потерялся так как дев под *nix и нет виндовых утилиток для работы с git, редакторов и прочеих вещей, после код-ревью оказалось что он не в курсе что такое composer и в свою етку пушнул кучу сторонних либ которые загадили ветку.... В итоге как я понимаю руководство и этот человек поняли что не подходят друг другу.
    Опять же имхо - надо бы знать немного больше чем просто 2 предмета из одной области, если есть надежды на попадание в нормальный проект.
    Ответ написан
    Комментировать
  • Хорошая практика для Python?

    aRegius
    @aRegius
    Python Enthusiast
    Здравствуйте!

    Лутца читать лучше после Доусона. А вот читая Доусона, вы и сделаете первый шаг к тому, чтобы не "тупить в экран", если, конечно, подойдете к работе (именно работе, а не просто чтению) с этой книгой серьезно - там достаточное количество интересных и практичных задач.
    Ответ написан
    4 комментария
  • Какое быстрое образование программиста для корочки выбрать?

    alexprik07
    @alexprik07
    Программист, верстальщик.
    Посмотрите в сторону, Московский технологический университет ВТУ, у них и удалёнка есть. Два года и вы магистр ) Вам же корочку )
    Ответ написан
    8 комментариев
  • Как вернуть верхнюю панель инструментов в Sublime Tex 2.02?

    @elijah_leonov
    для Linux : ctrl+shift+p, в водим в поиске "menu" и выбираем "View: Toggle Menu".
    f39d4f2d793c45ae89f211d40dceeb8d.png
    Ответ написан
    Комментировать
  • 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 комментария