Признаюсь честно: ещё пару лет назад я думал, что тестирование — это когда программист написал код, а другой чувак в очках тыкает в кнопки и ищет где-же лохонулся разработчик. Но потом я начал понимать, что на самом деле это целая культура, и если вы хотите войти в IT без навыков жёсткого программирования, то тестирование — это один из самых реальных и быстрых способов получить первую интернет-профессию.
Если говорить совсем по-простому, тестирование — это поиск багов. Но баг — это не только когда программа падает или выдаёт ошибку. Это любое отклонение фактического поведения от того, что вы ожидали. И тут есть один очень важный нюанс, о котором я сам долго не задумывался, пока не начал тестировать реальные проекты.
Баг бывает разным
Первый вид — самый очевидный: это когда программа вообще не работает. Например, вы нажали «Отправить» — и письмо зависло. Или ввели сумму в калькулятор — и получили красную надпись «ошибка». Или загрузили фото — и оно не прикрепилось. В общем, всё ясно, всё плохо, баг нашли, и все довольны.
Но есть второй вид, гораздо более коварный. Программа вроде бы работает, она выдаёт результат, форма отправляется, письмо уходит — но результат оказывается неправильным. И именно такие баги сложнее всего заметить и сложнее всего объяснить разработчику.
А бывает ещё хитрее
Вот вам пример из жизни, с которым я сам столкнулся недавно. Вы регистрируетесь на каком-нибудь сайте, вводите логин, допустим, User123 — с заглавной буквы. Система принимает его без ошибок, вы радуетесь, всё работает. А через неделю пытаетесь войти — и не можете.
Почему? Потому что система при регистрации почему-то сохранила ваш логин как `user123» — все буквы маленькие, хотя вы ввели с заглавной. А при входе она сравнивает строки строго — регистр-то чувствительный. И выходит, что логины не совпадают, хотя вы вводите те же самые символы.
В этом случае программа работает: она не падает, не выдаёт ошибку. Но она делает не то, что вы от неё ожидали. Она просто не пускает вас в аккаунт. И вы сидите и думаете: что же пошло не так?
Баг — это не только «сломалось». Баг — это когда «работает, но не так, как нужно».
Откуда мы знаем, как правильно?
Чтобы сказать «это баг», нужно понимать, какой результат считается правильным. Источником правильного результата служат требования — документы, в которых описано, как программа должна себя вести. Или спецификация.
В идеале эти требования пишут бизнес-аналитики, которые собирают пожелания от заказчика, и системные аналитики, которые переводят эти пожелания на технический язык. И уже разработчики и тестировщики пользуются этими требованиями как эталоном.
Что делать, если требований нет?
А если их нет — а в стартапах их почти всегда нет — то приходится полагаться на здравый смысл и на то, как обычно работают аналогичные сервисы. Однако в реальной жизни требования часто опаздывают, меняются на ходу или вообще существуют только в головах заказчиков, и тогда тестировщику приходится быть немножко детективом, чтобы вычислить, что же на самом деле имелось в виду.
Главная цель тестирования
Найти все эти несоответствия до того, как их обнаружит пользователь. Потому что пользователь найдёт обязательно, и он будет недоволен, и он напишет гневный отзыв, и вы будете потом думать: почему же вы это не проверили.
Но на самом деле тестирование — это не только про поиск багов. Это ещё про качество всего процесса разработки: про то, как собираются требования, как пишется код, как организовано тестирование и как происходит выпуск продукта. Если весь этот процесс выстроен правильно — продукт получается качественным. А если где-то случаются сбои или нестыковки, то качество неизбежно страдает, и это уже проблема не одного тестировщика, а всей команды.
Почему тестирование — это отличный старт для новичка
Если вы хотите получить интернет-профессию, но не знаете с чего начать, вот что вам нужно знать:
- Здесь не нужно с первого дня уметь программировать.
- Достаточно внимательности, логики и желания разбираться, как всё устроено.
- Вы сразу начнёте приносить пользу, потому что любой проект нуждается в человеке, который посмотрит на него свежим взглядом.
Со временем вы сможете вырасти до автоматизатора или даже до аналитика, но самое главное — вы получите реальный опыт и поймёте, как устроена разработка изнутри.
Так что если вы давно думали о том, чтобы уйти в IT, но не знали с чего начать, попробуйте тестирование. В следующих постах я расскажу, как правильно писать баг-репорты, чтобы разработчик вас не проклял, как тестировать формы, логику и интерфейсы, и как из новичка превратиться в востребованного специалиста.
А пока задавайте вопросы в комментариях, делитесь своим опытом и не бойтесь ошибаться. Потому что, как вы уже поняли, ошибки — это наша работа.
Свои мысли и дополнительные материалы по тестированию я буду публиковать в своем сообществе ВКонтакте — там подробнее и почаще. Подписывайтесь: vk.com/kliserga.blog
И последнее.
Не забудьте оценить статью, подписаться на канал. Надоедать публикациями не буду — сам терпеть не могу, когда заваливают контентом пачками. Так что пишу редко, но по делу.