Как быстро стать Айтишником?
Здравствуй, уважаемый читатель!
Есть некая уверенность, что сюда ты зашел не просто так, и скорей всего тебя заинтересовал заголовок. Все правильно, именно эта цель и преследовалась. Я думаю, что для продвинутых в социальном плане людей не секрет, что работа в сфере информационных технологий (далее по статье – ИТ) ассоциируется с образованными, зачастую скромными людьми, живущими в достатке. В некоторой мере именно так и есть, сфера ИТ не для людей - «фейерверков», это направление больше для планомерных, целеустремленных людей.
Но, как быть тем, кто уже потратил лучшие для образования годы, т.е. времена отсутствия обязательств? Тем, кого свое сегодняшнее социальное и материальное положение не особо устраивает и все-таки хочется еще что-то изменить, но времени не особо есть?
Не спешите вспыхнуть, в надежде узнать супер секрет и завтра стать миллионером, такие случаи происходят крайне редко и в основном в рекламах инфо коучеров и прочих.
Но и не все так плачевно, сейчас объясню.
Есть в ИТ такое понятие – ПОРОГ ВХОЖДЕНИЯ. Суть проста, это некая мера по которой можно понять долго ли нужно вникать и обучаться прежде чем, ты сможешь что-то сделать своими руками. Она не имеет конкретных цифр или оценок. Просто, когда, говорят «ЭТА» технология имеет низкий порог вхождения, то ИТ-шник понимает, что для обучения новому навыку не потребуется несколько лет. К примеру, есть обучение навыку делать программки на языке Visual Basic, а есть навык развития искусственного интеллекта – первому можно обучить даже школьника начальных классов, а второе требует нескольких этапов развития. Конечно можно посмотреть видео на ютубе из серии «Обучение <любая технология> за час», но поверьте это не значит, что они с низким порогом вхождения, так как все требует своего времени. Но также обязательно понимать, что чем выше порог, тем меньше там людей и тем выше они оцениваются. Тут в принципе все аналогично с обычными профессиями, если в твоей текущей профессии большая конкуренция за место и маленькая зарплата, то у нее низкий порог вхождения.
Тем не менее, есть одно направление в ИТ, которое в какой-то мере доступно практически каждому человеку, кто хотя бы имеет смартфон, понимает, что такое Google или Microsoft Office. Это профессия – тестировщик. Не то чтобы на тестировщика не надо учиться, просто базовые навыки этой профессии мы так или иначе уже получили и получаем в повседневной жизни.
Современный рынок создания программ (в том числе программного обеспечения, мобильных приложений) достиг такого этапа, что на первый уровень выходит не качество, а количество. Идет что-то вроде «гонки вооружений» и главным оружием компаний является большое количество опытных и соображающих программистов. Соответственно, чтобы эти «головастики» писали, как можно быстрее и больше кода, то есть кусков будущих программ, их руководители прибегают к разным способам достижения желаемого. Действенным способом является разгрузка программиста от работы, не требующей большого опыта, одним из таких мероприятий и является тестирование. Не то чтобы раньше все тестировали программисты, но эти функции как-то без проблем могли совмещаться, сейчас же тестирование – это отдельное мощное и развивающееся направление в ИТ.
Так, для чего же нужен тестировщик? В общем понимании, это некий работник, который заранее знает, как должна выглядеть программа и периодически проверяет близка ли она к конечному результату.
СТОП! Программы, программисты – я вообще ноль в ИТ, что то не понятно (дальше абзац для вас).
Еще с середины прошлого века, когда стремительно развивалась промышленная индустрия, инженерам начала приходить идея замены рутинных (повторяющихся) действий, выполняемых человеком на работу машин и устройств. Так появлялись примитивные конвейеры. Производство с применением указанных машин и устройств было и дешевле, и качественнее. Сам же процесс замены ручной силы на машинную был именован «Автоматизация». Шли годы, появлялись компьютеры, сервера, прочая техника - куда потихоньку начала кочевать информация с бумаги. Этой самой информации становилось все больше и больше и организация ее обработки также требовала дешевизны и качества. Автоматизация с применением компьютерной техники предполагает такую же оптимизацию рутинных (повторяющихся) процессов в жизни с использованием программ или сайтов, которые умеют автоматически проделывать работу за людей. К примеру, современный интернет-магазин по продаже мобильных телефонов, позволяет вам за 3-4 минуты найти подходящую под ваши цели (и кошелек) модель, сравнить ее с пятью другими, посмотреть обзор и сделать заказ. Представьте, если это делать без такого сервиса…
Так вот, чтобы такие программы создавались требуется 1 человек. Это программист, человек, который может написать для компьютера последовательность инструкций, которые в итоге и будут собой образовывать программу. Со временем, стало понятно, что таких программистов не так уж и много (чтобы еще и руки оттуда росли), а запросов на создание всяких программ и сайтов куча. В этот момент к программисту добавляется еще один коллега. Это аналитик, человек, который может понять, что автоматизировать и написать “инструкцию по сборке для программиста”, который в свою очередь напишет "инструкцию для компьютера" намного быстрее. Тем не менее, потребность в программистах не становится меньше, и к ним в команду добавляется еще специалист. Это тестировщик, человек, который сравнивает готовую программу, сделанную программистом по инструкции с самой инструкцией, для нахождения ошибок и несоответствий. И как ошибки будут доделаны и несоответствия приведены в порядок программа будет считаться готовой для передачи в массы.
Отклонение от темы завершено ?
Так вот как тестировщик поймет, что он обнаружил ошибку?
Для начала давайте разберемся с некоторыми техническими терминами, к примеру:
Баг (bug) - непосредственно сама ошибка в программе
Фича (feature) - особенность или черта или свойство или возможность в программе
Файл (file) - набор информации (данных), которые компьютер распознает как одно целое
Контент (content) - информация (данные), которые находятся в программе
Патч (patch) - файл с исправлением ошибки (бага) в программе
Мануал (manual) - руководство по использованию программы
Теперь, давайте представим, что нам нужно создать программу, типа “Конвертер валют”, то есть введя сумму в одной валюте, мы должны получить результат в другой (для примера будем использовать некоторый рубль и некоторый доллар). Хоть задача и очень простая, но давайте для ее реализации будут участвовать все, то есть и аналитик, и программист, и собственно тестировщик.
Итак, аналитик подготовил инструкцию для программиста, что-то вроде:
Визуально программа состоит из двух окон и кнопки “Рассчитать”
Первое окно имеет возможность ввода числа
Второе окно отображает результат после нажатия на кнопку “Рассчитать”
В программе имеется скрытое число “Актуальный курс”
Число “Актуальный курс” копируется с официального сайта Центрального банка и обновляется каждые 5 секунд
При нажатии на кнопку “Рассчитать” программа берет число из первого окна, умножает его на число “Актуальный курс” и отображает результат во второе окно
Отображение результата должно производиться не более чем через 3 секунды
Примерный вид программы отображен ниже.
Программист на основании инструкции разработал программу:
Подготовил визуальную форму
Реализовал связку программы с сайтом Центрального банка
Написал логику работы программы при нажатии на кнопку “Рассчитать”
Теперь то “К барьеру!” и выходит ТЕСТИРОВЩИК
Собственно ему нужно все проверить и по итогу выдать заветные слова - ПРОГРАММА ГОТОВА К МАССОВОМУ ИСПОЛЬЗОВАНИЮ.
Что нужно проверять? Требования к проверке бывают разными, но в общем случае, это обязательно функциональность (соответствует ли поведение программы документации) и производительность (как быстро работает программа), к примеру (будем заглядывать в инструкцию, написанную аналитиком):
Визуально программа состоит из двух окон и кнопки “Рассчитать” - соответствует
Первое окно имеет возможность ввода числа:
Успешно вводятся цифры от 1 до 0 - соответствует
Не вводятся буквы - соответствует
Не вводятся специальные символы - соответствует (НО! а как быть с запятой, если нужно ввести дробное число? - это баг - поэтому правильным будет написать “не соответствует” и направить описание бага на исправление)
...
...
Отображение результата должно производиться не более чем через 3 секунды - соответствует (это проверка производительности)
и т.д.
В общем и целом это и есть работа тестировщика - проверил, описал ошибки, передал на исправление - проверил заново - проверил заново - и так пока программа не будет готова.
Но стоит запомнить несколько обязательных принципов:
Выявить и исправить все баги невозможно
Баги могут возникать не только по вине программиста, но и по вине аналитика
Баги делятся по приоритетам и важности
Естественно, как и в любом деле, в тестировании имеются различные методики, практики, лайфхаки, позволяющие упростить и сократить время работы, но их незнание не является преградой для того, чтобы начать.
Думаю все, цель моей статьи - показать, что есть в ИТ направления с которых можно и нужно начинать, если очень хочется конечно, а дальше-больше.
Спасибо за внимание!
P.S. Это моя первая статья, прошу не судить строго. При этом, если информация показалась Вам полезной или хотя бы доступной для понимания, то не скупитесь на обратную связь.