Обучусь тестированию ПО, QA инженер
Заметил что начинается волна обучения из-за карантина,если вдруг у кого есть желание обучить, передать знания по Тестированию ПО буду премного благодарен
@Shark_0111 в телеге
Заметил что начинается волна обучения из-за карантина,если вдруг у кого есть желание обучить, передать знания по Тестированию ПО буду премного благодарен
@Shark_0111 в телеге
Примеры с Багреда. Интересный сервис)
Тут можно быстро понять принцип.
Освоить конкретику.
Главное не нервничать!
Пост первый, прошу судить строго.
Сразу оговорюсь я живу не в Москве/Питере. Название фирмы предпочитаю не раскрывать. На остальные вопросы постараюсь ответить в комментариях. А теперь к сути.
Работал я в одном гипермаркете, чтобы оплачивать учебу. Учился я на переводчика. По окончании института начал я искать работу по специальности, и охватила меня печаль при просмотре вакансий. Везде предлагали мизерную зарплату, а обязанностей непомерно много. В общем требовался в основном секретарь со знанием английского, чем переводчик как таковой.
И когда я уже отчаялся найти работу хотя бы в смежной области я услышал от коллеги что её дочь устроилась в крупную IT компанию на позицию QA. Тут то я и понял, что искал не там. Ведь в IT требуются специалисты с хорошим знанием английского. Тут ещё стоит добавить что попасть в IT я хотел всегда, но мечта казалась недостижимой, так как думал что там нужны только программисты. А с программированием у меня как-то особо не складывалось и попытки изучить какой-нибудь язык программирования бросались после написания "Hello World!" программ (кто хоть раз учил - поймёт).
После недельных изысканий я уже был поверхностно знаком с тем что такое QA и с чем его едят.
Резюме было написано и отправлено. А я продолжил изыскания по теме. Прошерстил Хабр, посмотрел всевозможные видео лекции от Яндекс и Mail Ru (да-да, у них есть годные записи лекций по QA).
Спустя примерно 2 недели получил приглашение на собеседование с HR, это было первое собеседование из как потом оказалось 3-х. Вопросы были разные могу выделить несколько:
- Почему вы хотите работать у нас, как узнали про вакансию, (тут ответил честно что услышал от знакомых)
- Почему именно QA а не учитель/репетитор английского учитывая моё образование (тут моим ответом было, что попасть в IT это моя мечта, английский я учил потому что информацию на английском найти проще (тут я конечно слукавил немного))
- Почему вы не учились на IT специальность (Тут я ответил честно, что учебная программа устаревает намного быстрее чем идёт развитие индустрии)
- командный ли вы игрок, (Ответил - да, потому что в требованиях к претенденту было указано что требуется командный игрок)
- после были поверхностные вопросы имею ли я представление что же такое QA.
Так же я честно сказал что про QA узнал не давно, в следствие чего получил рекомендации почитать доп. Литературу (да-да того самого Савина "Тестирование дот ком") и научиться строить простые SQL запросы, т.е. знать операторы SELECT, UPDATE, знать JOIN, и уметь использовать условия AND и OR в запросах.
Тем не менее мне сказали что я их устраиваю, и через 3 недели меня ждёт техническое собеседование. Воспользовался я этими тремя неделями по максимуму.
На втором собеседовании вопросы уже были только по теме QA, проверяли английский, попросили написать SQL запрос.
По итогам второго собеседования мне предложили две опции:
- мне дают месяц, и я самостоятельно подтягиваю знания, и прихожу ещё раз на собеседование.
- бесплатное обучение в их учебном центре, с возможным трудоустройством.
Специалист проводивший собеседование подчеркнула, что второй вариант предпочтительный и вероятность получить работу выше.
Ну а дальше всё просто. Я окончил курсы, было ещё одно собеседование, а затем оффер (приглашение на работу).
Ожидая вопросов в духе как тебя взяли с гуманитарным образованием на техническую должность, отвечаю: меня взяли с условием, что я в ближайшее время поступлю в магистратуру на IT специальность.
Трудоустройство в итоге заняло чуть больше полугода.
Рекомендации:
Резюме. Как бы это банально не звучало, но от него многое зависит. Например пригласят ли вас на собеседование.
Изучите тему QA прежде чем идти на собеседования, вот парочка полезных ресурсов:
Ютуб каналы
https://www.youtube.com/channel/UC9VeXtf7fcCJUfmZ_cyweXA
https://www.youtube.com/user/TPMGTU
SQL учил на этом сайте (естественно английский)
https://www.w3schools.com/sql/default.asp
Итоги:
Если постараться, то нет ничего невозможного.
Надеюсь мой рассказ будет полезным, для тех кто задаётся вопросом, как попасть в QA.
Уважаемые Пикабушники! Нужна ваша помощь. А именно: совет.
Есть желание обучиться на тестировщика, живу в СПб. Школ полно, как онлайн и оффлайн. Отзывы на просторах читал, однако хорошим верить сомнительно, а плохие не все адекватны. Поэтому возник вопрос: где порекомендуете пройти курсы по специальности "Тестирование ПО"? Прежде всего, рассматриваю оффлайн, но если есть хорошие онлайн-курсы, то готов рассматривать и их.
P.S. Р.Савина читал, хабр смотрел. Книгу от EPAM прочитать в планах. С теорией более-менее, нужна практика и направление, поэтому и задался вопросом о курсах.
Доброго времени суток, уважаемые пикабушники. Пришел к Вам просить совета и напутствия. Мне 27 лет и я осваиваю для себя новую профессию - QС Engineer. Прошел курсы длиною 2 месяца QA Start. С техникой и миром IT связан тесно, не смотря на медицинский бэкграунд. В голове основные знания теории, HTML, CSS, SQL, ясен пень Канер. Хотел бы найти с помощью этого поста людей, которые работают в этой сфере давно/недавно для общения и просто получить совет и побеседовать. Интересно очень услышать от Вас советы в первых шагах в этой сфере. Подсказки какую литературу подчитать и на что надавить, чтобы найти свою первую работу. Можно пообщаться здесь или же стучитесь мне в Telegram - @chopalish. Спасибо за внимание и хорошего дня!
Привет.
Давненько уже задумывался над тем, что бы написать о своей работе, да и попутно разогнать туман в голове многих людей, которые не знают, кто такие тестировщики, и чем они занимаются в рамках QA. (да, @HappyMe, это текст для тебя, хоть и очень запоздавший :) )
Итак, что же такое QA? Номинально, это далёкая цель, которая недостижима сложна и опасна, ведь многие разработчики считают тестирование мартышками с мышками. И отчасти они правы, ведь даже сами ответственные за качество слабо понимают, чем они заняты. Что бы понять это более комплексно, нужно заглянуть на самое дно такой страшной среды, как IT.
Однажды, меня спросили, почему именно тестирование? Мне было сложно ответить на этот вопрос, ведь я действительно не знал ответа. Я был и сисадмином, и разработчиком, и SQL-саппортом, и обычным саппортом, но всегда на нас сгружали тестирование нового функционала, ведь "у них на это есть время, всё равно сидят ничо не делают". А потом мне позвонили, и предложили должность тестировщика. Хотя, я слабо представлял, что же это за зверь такой. Первый мой руководитель в рамках тестирования был дуб-дубом, и не мог мне объяснить, что такое тест-кейсы, как правильно составлять и заводить тикеты на баги, почему моки это не то же самое, что тестовые базы, и почему НЕ надо сидеть на QA форумах. Пришлось осваиваться самому.
И сейчас я хочу поговорить о тестировании.
Тестирование, кстати, бывает несколько типов.
1 тип - ручное тестирование:
Самый распространённый тип тестирования, когда ты просто протыкиваешь весь ресурс руками, ищешь кривое поведение приложения и пишешь об этом. Кажется простым, верно? Как бы не так!
Помимо развитой интуиции, ручному тестировщику нужно уметь думать, и принимать нестандартные решения. Например, отличать позитивные тесты, от негативных. Это, кстати, сложно, ведь негативный тест - это не тот, который "вот тут надо вводить числа, а мы введём буквы". Равно, как и надо отличать моки от инфраструктурной заглушки. Нужно знать сети, (возьмём к примеру web сегмет), как работает браузер/ОС, почему нужно чистить куки, как работают куки, быть в теме фреймворков, быть очень надоедливым, уметь отстаивать своё мнение, убеждать программистов переделать тот или иной сегмент приложения, если он вам категорически не нравится, хотя и работает правильно на первый взгляд. Нужно быть внимательным, быстрым, подкованным в среде последних тенденций развития вашего направления, желательно уметь читать код, разбираться в БД (ну хоть на уровне отличий реляционной от no-sql БД)...
Что, господа программеры, всё ещё считаете тестирование обезьянами? Ну окей, вот вам второй тип, с которым уже надо считаться.
2 тип - автотесты:
Самый интересный тип тестирования. Это недоразработчик, перетестировщик. Человек, который творит с кодом такую хрень, которую вам и не снилось. Сделать заглушку, убить, казалось бы, верный код, реверснуть то, что понаписал программист и свалил в туман без документации к коду... А самое главное, это тот, кто ковыряется в вашем говне коде, и жутко матерится, когда не находит комментариев, или пытается отделить костыль от велосипеда, ведь надо это покрыть тестами...
Самое интересное, что этот спец должен уметь читать код на любом языке, понимать, как это работает, осознавать ограничения и заставлять разработчиков быть заинтересованными на благо качества и сокращения затрат на тестирование/разработку. А ещё, это повелитель селениума, мастер багтрекеров, разработчик фреймворков и обёрток, скорее всего неплохой разработчик в python и java и не знает элементарных вещей. Страшное существо, правда? :)
3 тип - тестировщики в безопасности:
Это страшные люди. Воистину страшные. Может быть - это венец эволюции тестирования. Это люди, которые знают очень много, а ещё больше хотят вас унизить. Найти самые обидные баги в ваших программах, заставить вас просыпаться среди ночи, и заново шептать коды и пароли, которые они могут стянуть прям с вашего рабочего стола. Они смогут в три шага сломать труд многих лет... XSS уязвимости, SQL-инъекции, косяки в вёрстке, мемори-лики... Это страшный сон одминов и прочих эксплуатационщиков, люди, которые заставляют вас использовать обфускаторы и прочий бред, мешающий "творить в высших потоках"...
Но, я увлёкся описанием ролей в тестировании, а надо бы описать QA... И я не знаю, что написать об этом...
Наверное, это недостижимый абсолют, ведь QA - это когда ВЕСЬ коллектив разработки стремится к качеству своего продукта. Когда тестировщик и разработчик знают работу друг друга, когда экспертное мнение не повисает в воздухе, когда бизнес четко может определить, что он хочет, а аналитик почему это невозможно, почему это не будет работать правильно... Когда... Когда каждый знает, что он ответственный за то, что сделал. До самого последнего уборщика помещения... О, как же часто разработчик не понимает, что его "уникальное видение решения проблемы" по факту оказывается неудобным дерьмищем, но как отец этого уродца, он будет до конца защищать творение рук своих... Когда аналитик собирает не все требования, и весь сквод начинает переделывать то, что уже было сделано... Когда админ забывает почистить место, или снять бекап... Зачастую, контроль этого возлагают на плечи тестирования.
Сейчас, я больше евангелист тестирования, чем исполнитель, и стараюсь привить всем окружающим любовь к качеству своей продукции... И всё реже и реже мне приходится говорить "Здравствуйте, а не хотите ли вы переписать это г.."
Наверное, для первой пасты этого будет достаточно... Множество нюансов есть в разработке ПО, о них можно очень долго говорить. Если вам это зашло, и вы хотите более детализированной информации - задавайте вопросы, и я опишу более детально :)
Засим откланиваюсь, прошу сильно не пинать, пост не технический а скорее поныть "насниктонелюбитнепонимаит" :)
На Пикабу видел просто трильярды постов про программирование - "C# за 21 день", "Unity игры и с чем их едят", "Лёгкий способ начать кодить" и прочее. Но почему-то я не встретил ни одного поста про тестирование! А ведь зря!
Короче, сидел я, писал доки и решил - вдруг кому будет интересно почитать не только про разработку, но и про другие области IT?
Я работаю QA-Engineer'ом (Quality Assurance - обеспечение качества). QA - это человек(или целый хайвмайнд под названием "QA team"), основная задача которого - обеспечить, чтобы багов было ПРИЕМЛЕМОЕ КОЛИЧЕСТВО. Да, наша работа - не искать баги, а сделать так, чтобы баги не мешали бизнес-логике. Потому что есть такая аксиома - "Баги есть всегда". И это именно аксиома - если вы долго-долго-долго думали над структурой проекта, сделали всё вот прям идеально и сидите весь такой довольный с мыслью "А у меня в коде нет багов" - вы просто не залезли глубоко в свой проект))(Особо верующие в возможную непогрешимость девелоперов могут гуглить заезженную историю про американский самолёт в Мёртвом море и ошибку отрицательной высоты)
QA, несмотря на стереотипы - важный человек на проекте. Ошибка - вещь дорогая, и чем раньше ошибку нашли - тем дешевле её устранить. Если на стадии написания документации исправление ошибки стоит, например, 1 цент(минуту времени тестировщика, который например скажет добавить валидацию на поле), то после релиза взбешённый заказчик может очень неплохо повздорить с конторой, тем самым сильно увеличив затраты(вплоть до судебных издержек, баги в том же медицинском ПО - это человеческое здоровье, а то и жизнь)
Несведущий человек скажет: "Ну что это за работа? Сиди да пялься в экран, тыкай кнопочки и проверяй, чтобы сообщение об ошибке было!". И будет неправ. Поверьте, если бы моя работа заключалась в том, чтобы сидеть на заднице ровно, рандомно тыкать кнопки и кричать "Я нашёл баааааг!!!", уворачиваясь от кружек девелоперов -- Я был бы счастлив. Первые две недели. А потом бы сильно заскучал.
На самом деле, бОльшая часть работы тестера - это документация. Ооооо, великая и ужасная Документация! Тестировщик - работа, требующая комплексного подхода, а чтобы покрыть всё - нужно это записывать. Если алгоритмизировать, то работа тестировщика выглядит примерно так:
1)QA получает от бизнес-аналитика Specification(подробное техническое задание продукта)(и я буду сознательно применять английские термины ибо стандарт отрасли)
2)QA по документации пишет Test-cases(тестовые случаи, некий блок действий, которые нужно совершить для проверки фичи). И пишет он именно по документации, зачастую даже в глаза не видя продукта.
3)QA прогоняет кейсы. Если найден баг - заводится Bug report, и отправляется девелоперу (С комментариями "ахаха, нуп, тупейшая ошибка, лал!"(нет))
4)После исправления багов QA проводит Regression Test - проверка уже проверенных кусков фич, дабы фиксы багов не создали другие баги.
5)Если в спринте(а тут несведущим можно почитать про Agile методологии менеджмента проектов) багов нет - можно выпускать версию.
6)...
7)И вот так обычно не работает))) Это всё - в идеале, обычно все эти стадии идут вперемешку - QA может одновременно и покрывать кейсами новую фичу, и тестить продукт, и даже тестить без документации(Ad hoc), дабы просто выпустить минимально значимый продукт.
Давайте о стереотипах:
1)"Ничего делать и знать не надо, сиди да тыкай!!!" - а вот и неправда. Если тестер не знает например SQL и в принципе базы данных - он не сможет придумать, какие проверки стоит включить в тест-кейсы(например, он фатально упустит проверки про SQL-иньекции, и хитрый корейский хакер сделает DROP DATABASE, и больше не будет какого-нибудь сайтика). Тестер прогуливал в школе JSON - и когда придёт время тестить API он будет сидеть и хлопать глазами. По-хорошему, для работы тестировщиком желателен университетский курс инженера-программиста. Ну или 2 книжки по тестированию и пару месяцев изучать дополнительные технологии.
2)"Тестер ничего полезного не делает, на проекте всё делают программисты!" - отчасти правда. Да, я не пишу код на продакшен. Но я обеспечиваю качество - я делаю так, чтобы юзер не страдал от ошибок. Ошибки не нравятся никому. И QA - он не только находит ошибки, его задача - и предотвращение ошибок. QA тестит всё что угодно - продукт, макеты, документацию, ̶т̶в̶о̶ю̶ ̶м̶а̶м̶к̶у̶(Простите, Хованский головного мозга разыгрался). QA всегда участвует во всех Scrum meetings(встреча команды с утреца), где слушает и перебивает всех своими кулстори во избежание багов.
Всё в один пост не уместить, если кому интересны подробности(Agile, всякие разные людишки на проекте типа бизнес-аналитиков, какие инструменты юзают тестеры, что такое автоматизация тестирования, Как начать и как войти в IT) - в комменты всё отвечу)
Ну и чукча не писатель, как умею - так и говорю, профессиональные писатели посмотрят и наверняка увидят кучу стилистических ошибок. Опять же приветствую любую критику в комменты))