bglupus

Представьте себе, что вы пишите web сервер. И к нашему серверу подключено 100 юзеров. И это, к примеру, чатик.

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

Предположим что у нас есть массив дескрипторов сокетов (или просто массив сокетов для упрощения) и мы тупо в бесконечном цикле обходим каждый и спрашиваем "есть че? нет? Ну ладно, следующий". В этой ситуации у нас 90% времени цикл будет пускаться в холостую и просто бернить процессорное время. А этим процессорным временем мог между прочим воспользоваться другой процесс, который тоже что-то важное делает.

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

Более того, эта функция ничто иное как просто системный вызов. Она реализована не в python даже а в операционной системе, а вы просто работаете с оберткой. И если мы делали все тупым перебором, то в современных операционках за это отвечают весьма хитрые и оптимизированные алгоритмы.

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

Есть несколько вариантов вашего дальнейшего развития:

1. Если вы готовы "тренироваться на кошках", смело идите (вернее, записывайтесь) на курсы Software Testing (у них еще полезный форум). Там есть разные варианты, основы вам дадут и это будет крепкая база по небольшой цене (только не выбирайте ускоренный курс, лучше возьмите простой базовый). Перед этим можно заправиться онлайн-курсом Савина и курсом от Mail.ru (про него писали выше). Есть еще бесплатный вводный курс на Udacity.

2. Пойти на стажировку/обучение при крупной IT-компании (так училась я сама). Эти тренинги проводят Epam, ITransition, Veeam и другие. Ищите на хэдхантере по словам "QA/тестировщик/специалист по тестированию", затем выбирайте графу "без опыта". В Питере, кажется, есть несколько открытых позиций. Требуется знание логики и базовое понимание SQL. Кое-где - ООП (это уже зависит от компании и направления). Если указано, что ищут выпускников, а вы уже давно не выпускник, всё равно пишите: мотивацию ценят в первую очередь.

То, что очень сложно понять, не имея опыта, но можно предположить, зная себя и свои способности: решите, каким тестированием вы хотите заниматься.
- Веб-приложения, сайты и т.п.? Продолжайте зубрить Html/CSS/SQL, попробуйте поверстать. Без этих знаний попасть на джуниорскую должность тяжело - конкуренция высока.
- Функциональное - тот же SQL, администрирование (учите запросы в комстроке), язык (лучше Python или Java).
- Плюс, спросите себя, в какой сфере хотите работать. Если игровым тестировщиком, будет проще: на позицию джуна попасть легче, но нужен большой игровой опыт. Кроме того, есть мобильное тестирование, тестирование графического контента и артов и т.д. Подумайте, в чем вы сильны.

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

Подумайте над своим резюме и сопроводительным письмом - в 80% именно они решают, позвонят вам или нет.
Удачи)

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

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

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

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

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

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

Как-то так.
К сожалению, больше рассказал именно о тестировании, чем о QA в целом. :)