280

Всё что вы хотели знать о Тестировании программ, но боялись спросить...

На Пикабу видел просто трильярды постов про программирование -  "C# за 21 день", "Unity игры и с чем их едят", "Лёгкий способ начать кодить" и прочее. Но почему-то я не встретил ни одного поста про тестирование! А ведь зря!
Короче, сидел я, писал доки и решил - вдруг кому будет интересно почитать не только про разработку, но и про другие области IT?

Всё что вы хотели знать о Тестировании программ, но боялись спросить... QA, Тестирование по, Тестировщики, Длиннопост, IT

Я работаю QA-Engineer'ом (Quality Assurance - обеспечение качества). QA - это человек(или целый хайвмайнд под названием "QA team"), основная задача которого - обеспечить, чтобы багов было ПРИЕМЛЕМОЕ КОЛИЧЕСТВО. Да, наша работа - не искать баги, а сделать так, чтобы баги не мешали бизнес-логике. Потому что есть такая аксиома - "Баги есть всегда". И это именно аксиома - если вы долго-долго-долго думали над структурой проекта, сделали всё вот прям идеально и сидите весь такой довольный с мыслью "А у меня в коде нет багов" - вы просто не залезли глубоко в свой проект))(Особо верующие в возможную непогрешимость девелоперов могут гуглить заезженную историю про американский самолёт в Мёртвом море и ошибку отрицательной высоты)


QA, несмотря на стереотипы - важный человек на проекте. Ошибка - вещь дорогая, и чем раньше ошибку нашли - тем дешевле её устранить. Если на стадии написания документации исправление ошибки стоит, например, 1 цент(минуту времени тестировщика, который например скажет добавить валидацию на поле), то после релиза взбешённый заказчик может очень неплохо повздорить с конторой, тем самым сильно увеличив затраты(вплоть до судебных издержек, баги в том же медицинском ПО - это человеческое здоровье, а то и жизнь)

Всё что вы хотели знать о Тестировании программ, но боялись спросить... QA, Тестирование по, Тестировщики, Длиннопост, IT

Несведущий человек скажет: "Ну что это за работа? Сиди да пялься в экран, тыкай кнопочки и проверяй, чтобы сообщение об ошибке было!". И будет неправ. Поверьте, если бы моя работа заключалась в том, чтобы сидеть на заднице ровно, рандомно тыкать кнопки и кричать "Я нашёл баааааг!!!", уворачиваясь от кружек девелоперов -- Я был бы счастлив. Первые две недели. А потом бы сильно заскучал.
На самом деле, бОльшая часть работы тестера - это документация. Ооооо, великая и ужасная Документация! Тестировщик - работа, требующая комплексного подхода, а чтобы покрыть всё - нужно это записывать. Если алгоритмизировать, то работа тестировщика выглядит примерно так:
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) - в комменты всё отвечу)
Ну и чукча не писатель, как умею - так и говорю, профессиональные писатели посмотрят и наверняка увидят кучу стилистических ошибок. Опять же приветствую любую критику в комменты))

Дубликаты не найдены

+10

Я уже писал это раньше в похожем посте и повторю еще раз. :)

Quality Assurance есть не тестирование, а обеспечение качества - работа с процессами на разных этапах разработки, проверка на соответствие стандартам и константный доеб менеджмента/девов/аналитиков на предмет того что код говно, на стандарты положен болт, дочь СЕО трахает аналитик, на кухне нет кофе, да и вообще все криворукие. По обязанностям действительно что-то между бизнес аналитиком и тестировщиком, только сам не тестирует. И да - реально QA вы найдете в действительно больших или очень серьезных проектах (крутой файнанс и банкинг например), потому что во проектах средней руки эти обязанности будут разделены между тест лидом, тест менеджером, архитектором и бизнес аналитиком. Куа может стоить серьезную деньгу, а тестировщик будет в среднем не дороже кодера.

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

раскрыть ветку 1
0

Ну термины - штука размытая, в разных процессах QA может принимать разные трактовки.

+2

У меня для вас есть одно слово - фаззинг.

+2

Текст про тестировщиков, а не qa)

Особенно прикололо про JSON. Вот прям оооочень необходимая вещь, которая осваивается непосильным трудом. Этот контент тайп/формат данных залетает в голову за пару минут, т.к. прост до примитивности сам по себе. Про http лучше почитайте...

+5
Комментарий удален. Причина: данный аккаунт был удалён
раскрыть ветку 14
+1
А ещё иногда эта документация написана и вам выдана, но потом выясняется, что заказчик уже сто раз передумал, а новой доки ещё нет. И вот начинается это вылавливание комментариев, цитат из переписки, и всего такого. И как правило, они местами друг другу противоречат) а ещё ирогда тз на уровне "сделайте нам вот так", а о подробностях этого "вот така" надо выяснять чуть ли не клещами)

Но вообще да, когда есть хоть какое-то описание, это очень круто.
раскрыть ветку 1
0

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

0

документация - это конечно дорого, но оно себя оправдывает. на тяжёлых и массивных проектах доки важны как воздух.

раскрыть ветку 11
0

а какие книги посоветуете?

раскрыть ветку 5
0

какие международные сертификаты тестировщика получали и какие пригодились?

какие могут пригодится?

раскрыть ветку 2
0

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

раскрыть ветку 1
+1

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

+1

Лови плюс, коллега

+1

У кого-то личная попаболь к автору или ко всей теме вообще?=)

Почти все коменты заминусованы были без объективных причин, аж устал исправлять.

раскрыть ветку 1
+1

да я не ради лайков же))) так, самовыражение.

0
Привет, коллега-багоборец!
Описанный текст, видимо, актуален для очень крупных команд.
В группах из 4-10 человек, по моему опыту, все чутка проще. Документации меньше, исследовательского тестирования больше, а тест-кейсы иногда заменяются на саму документацию (которую я по привычке именую диздоком).
раскрыть ветку 2
+1

Мне приходилось и для себя одной кучу доков писать - нереально удержать все в голове. Активно юзаю майнд-мэпы сейчас. Очень упрощает процесс

0

а вот кстати от проекта к проекту. был у меня один проект на старте карьеры, где я и доки в глаза не видел, тестируя Ad hoc)
А сейчас и проект не на крупную команду(всего 4 человека нас на проекте), но проект запутанный и сложный, и там без доков сложно.

0

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

раскрыть ветку 1
-1
Уже есть, зайди в мой профиль, первый сверху)))
Но сразу говорю -- это был мой путь, может он и не самый быстрый и верный -- но он сработал.
0

Как к вам попасть? В интернете полно разводов по данному виду деятельности.

раскрыть ветку 3
0

на сайтах с вакансиями ищешь IT контору и вперёд!

раскрыть ветку 2
0

Там полно таких, просят выполнить задание или просто не отвечают.)

раскрыть ветку 1
0

Ну лично меня интересует как вообще попасть в IT? Все-таки самому года через 3 нужно будет работу искать. Знания вроде есть, но уверенности нет)

раскрыть ветку 2
+1

Устраивайся на Trainee уровень за копейки будучи еще студентом, хоть на полставки. Фирм полно, тебя любая галера (если говорим про Россию, а не Украину - у них стартовать сильно сложнее) с руками оторвет. Через полгода интерншипа будешь уже джуном. Наберешься ещё скилла (если говорим про тестирование, года 2-3, крайне желательно мочь в разный автомейшн и менеджмент, у проггеров чуть более специфично) и можешь искать приличную вакансию.

+1

1. Фулл-тайм
Если в городе присутствует хоть пара IT контор - сходи туда, в большинстве они очень лояльно относятся к студентам/молодняку. Спроси чем они занимаются и кто им нужен и с какими навыками/знаниями. Далее за 3-6 месяцев ты сможешь подтянуть себя под это.
Рекомендую сначала подтянуть знания, а потом устраиваться на работу - от стартового уровня ОЧЕНЬ сильно зависит стартовая планка ЗП и скорость ее поднятия.

Основной вариант вхождения в IT, потому как:
* Гораздо проще зарабатывать именно на фулл-тайме
* Только тут ты сможешь научиться грамотному ведению проекта и базовыми знаниями даже не о самой разработке, а о том что вокруг (agile, VCS, CI, etc.)
* Живое общение с людьми - когда постоянно варишься в этом, этого много дает экспириенса

2. Фриланс
Можно сразу перейти на фриланс, но не имея достаточно обширный опыт особо успешным он не будет. Более того, даже если ты хороший специалист - это не залог успеха работы на удаленке.

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

Очень полезно но скорее как дополнительный вариант - потому как чтобы выйти на самообеспечение фрилансом нужно время и знания. Когда я работал фулл-тайм периодически брал на выходные небольшие работенки по 50-150$. И не особо напряжно, и на пиво с фисташками хватает.


3. Проекты для себя
Большинство разрабов имеют хотя бы пару вещей которые они пилят после работы или на выходных. Но вынужден признать, что 95% таких домашних проектов загибаются не из-за недостатка времени/опыта, а из-за перфекционизма. Больше выхлопа давали не проекты "недосыпал 3 года чтобы сделать шедевр", а "Придумал, на выходных собрал, в понедельник показал коллегам". Гавно - в топку, годно - продолжаем работать.

Увидел какую-то интересную технологию - кофе в руки и вперед. Начинать можно с банальных сайтов/визиток друзьям(благо можно за выходные справиться) или каких-нибудь приложений "For Fun" если это мобильная разработка. Мой знакомый некоторое время дарил друзьям именованные приложения где обычно стебался над ними.
Денег обычно такие вещи не приносят, но значительно повышают кругозор в мире IT

0

4)После исправления багов QA проводит Regression Test - проверка уже проверенных кусков фич, дабы фиксы багов не создали другие баги.


ты точно тестировщик?

раскрыть ветку 3
раскрыть ветку 2
0

Wikitext-ru.svg Эту статью следует викифицировать.


Пожалуйста, оформите её согласно правилам оформления статей.


Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестаёт работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression bugs).


а не проверка пофикшенных дефектов, хоть бы прочитал прежде чем ссылку кидать...

раскрыть ветку 1
0

>QA, несмотря на стереотипы - важный человек на проекте

Это стереотипы тех, кто никогда не участвовал в процессе.

Я вот мечтаю, что бы у нас в студии был QA, но отдельный кадр пока не берут, так что занимаемся этим все понемногу, что не может не сказываться на качестве тестирования.

0

история про истребитель была напечатана еще в ЛКИ, кажется...

раскрыть ветку 2
-1
Не в курсе, если честно, историю впервые услышал от брата лет 10 назад
раскрыть ветку 1
0
ну там тоже период 2002 - 2006 года.

так что совпадает.

0

Кстати а можешь примерно вилку з\п рассказать. В своём регионе. Ну и от чего зависит. На сколько быстрый\небыстрый рост?

раскрыть ветку 4
+1

Судя по информации от моих знакомых, студентам в Минске платят в районе 300 уе чистыми, что выше зарплат большинства белорусов. Понятно, что везде есть исключения. Но 300 это самая распространённая ЗП после закрытия испыта в большинстве контор, которые берут людей без опыта работы. Само собой, что если до этого работал в IT-сфере, то стартовая ЗП будет в разы больше.

+1

Восточная Европа (Прибалтика, Польша, Чехия) - ОЧЕНЬ много вакансий на миддл/сениор/тест лид/тест манагер позиции. В последнее время русских и укров приезжает все больше и больше (часто едут даже с понижением ЗП, так как тут приличный перевалочный пункт перед Западной Европой).

Вакансии в основном с уклоном в автоматизацию и менеджмент, но и мануальщикам (если планируют развивать скиллы) довольно легко осесть.

Зарплаты в районе 1000-2000 евро за миддла (после налогов), 1500-2500+ у сениор и лидов, за манагеров не скажу.

Переехать легко, релокейшн часто оплачивают, ну и всякие блюкарды и ПМЖ через пять лет в качестве бонусной плюшки.

Для Западной Европы цифры можно смело умножать на два, но с наскока попасть туда тяжелее.

0

Всё очень индивидуально - зависит от компании, твоего ума, умения подать себя, etc Плюс какие-то рандомные факторы.

Если ты активный, шарящий, предлагаешь всякие полезные штуки и, что немаловажно, сам же эти штуки хорошо исполняешь. Тогда ты довольно быстро будешь расти.

0

От 15к р. на самом первом своем рабочем месте тестером. Через полгода 20. Еще через полгода 25. Через 2 года 35-40. Потолок в среднем 50-60. Дальше только автоматизация тестирования, она немногим уступает программированию.
Обрати внимание, что работать можно по удалёнке. Живешь в мухосранске, получаешь зарплату на уровне миллионника.

0

ТС, ты QA или AQA?
Где трудишься?)

раскрыть ветку 1
0

QA
Всё тебе скажи))) Название не скажу, "поайпивычисляторы" вычислят, да и персональные данные, все дела.
Относительно небольшая контора, нас около 200 человек

0

Сам пытался выполнить ТЗ на QA. Выполнил 90% ТЗ за 2 дня, дошёл до теста дубликатов (загруженных и созданных в системе) и тут влип вообще, ошибка на ошибке (хотя по идее так быть не должно), после перезапуска сервиса всё работает. Неделю думал как оформить в тестовом это. Время вышло - плюнул и пошёл в ТП этой же компании, с мыслью, что спокойно освоюсь и переведусь) Пока полёт нормальный.


А можешь сказать в принципе, что изучать человеку кроме данных двух книг (прочитал уже), после выполнения ТЗ - уже на работе и причём срочно? И на сколько актуален для QA - тех. англ? И ЯП для написания скриптов поначалу обязателен? Какой конкретно и уровень владения? SQL в целом общее понимание ( на уровне запросов) или конкретное знание той что в стеке? В целом какой уровень понимания базы IT нужен? Сетевые протоколы? Основы вёрстки? Ну и примерный план изучения технологий и до какого уровня можешь накидать - всем я полагаю будет полезно. За пост лови + :)

раскрыть ветку 6
0

"А можешь сказать в принципе, что изучать человеку кроме данных двух книг (прочитал уже), после выполнения ТЗ - уже на работе и причём срочно? И на сколько актуален для QA - тех. англ? И ЯП для написания скриптов поначалу обязателен? Какой конкретно и уровень владения? SQL в целом общее понимание ( на уровне запросов) или конкретное знание той что в стеке? В целом какой уровень понимания базы IT нужен? Сетевые протоколы? Основы вёрстки? Ну и примерный план изучения технологий и до какого уровня можешь накидать - всем я полагаю будет полезно. За пост лови + :)"

1)Теории в данных книгах изложено достаточно, остальное - на практике
2)Английский - необходим, Intermediate+. у нас в компании документация на английском, переписка с заказчиком на английском, иногда даже daily meetup на английском. англ наше всё))
3)Поначалу - нет, но потом, когда например будут задачи протестить API - легче использовать jframe
4)университетский курс. Джойны, вью, триггеры
5)ну... не знаю как описать уровень понимания базы IT...
6)сетевые протоколы мастхев. не на мега-высоком уровне, но шутки про UDP и TCP понимать надо)) Http запросы, TCP...
7)вёрстка и CSS - мастхев.

раскрыть ветку 5
0
А что за книги-то? Названий в посте не нашёл.
раскрыть ветку 1
0

Продвижение в QA необходимо начать с нормального знания английского языка?

Подтянуться по теории и практике тестирования легче чем выучить язык?

раскрыть ветку 2
0

2)"Тестер ничего полезного не делает.."

Это в нулевых осталось или мне везет? В любом случае инетересно что бы сказал такой "пограммист" перформанс-инженеру или автоматизатору, они относятся к QA.

раскрыть ветку 1
0

ну среди не-айтишных людей встречаются подобные. у нас даже 1 препод в универе подобное сказал как-то.

-1
Specification(подробное техническое задание продукта)

Вы наверно имели ввиду Requirement


QA всегда участвует во всех Scrum meetings(встреча команды с утреца)

Далекоооо не всегда.

раскрыть ветку 8
+2

1)Каждая спека - это требования, но не каждые требования - это спека. Нам всегда вдалбливали в голову, что Requirements и Specification - две немного разные сущности. Спека поподробнее, может в себя например включать Data Dictionary и бизнес-рулы.
2)Горе той команде, QA которой не знает, что творится на проекте))

раскрыть ветку 6
0

1) А, понял. У нас это называется документация и пишется в конце цикла девелопером на свою фичу с привязкой к коду. Писать ее на начальном этапе проектирования малоэффективно.

2) Зачем мне ходить на стенд-апы? Я и так знаю в нужном объеме то, что мне нужно знать. Если есть 3-4 независимых группы девелоперов, то я все утру буду по стендапам тусить, а не работать. Норм конечно, если цель "лишь бы помитинговать да потрекаться" =))

раскрыть ветку 5
0
Далекоооо не всегда.
Вы точно знаете что такое SCRUM ?
0

Проект на работе как раз проходит активную стадию QA, ох и бесите вы меня. Хотя я понимаю важность и нужность вашей работы, но бесите :D

раскрыть ветку 1
-1

примем за комплимент)))

0
1. Как тестируют свои программы инди-девелоперы?
2. Я голосую за гайд по тестированию.
раскрыть ветку 2
0

1)умные инди-девелоперы берут себе за еду в команду тестера. глупые - глупые инди-девелоперы сами и тестят свои продукты. Но нам ещё в универе вдолбили, что "Тот, кто пишет код - не может его тестировать!!"

2)посмотрим)

раскрыть ветку 1
0
Спасибо.
0

Ну и две книжки по тестированию сюда зарекомендуй.

раскрыть ветку 9
+3

Для уровня чуть выше ноля рекомендую Калбертсон - Быстрое тестирование, ну и глоссарий терминов тестирования ISTQB (да весь курс foundation level)

+1

Достойные книжки, которые рекомендовали и на курсах, и в универе -
Роман Савин "Тестирование .Com"
Святослав Куликов "Тестирование программного обеспечения"
Книжки читаются влёт, легко и приятно.

раскрыть ветку 5
0

Дружище, вот тебя то я и ждал) Суть в чем, работаю продажником (не IT), образование чисто гуманитарное, 27 лет, есть желание всё бросить и начать с чистого листа, ненавижу продажи.. Как-то взгляд остановился на работе тестировщика - работа с компами, возможность работать удаленно, гораздо меньше живого общения с людьми, да и наверное еще в юности зацепили тексты Юры Бригадира, что наложило отпечаток) Сейчас читаю Савина. Что дальше? Куда идти, что читать, на чем практиковаться? Насколько Савин близок к реальности (а то тут некоторые пишут, что и тест-кейсы бывают не так часты в реальности и всё более условно)?

раскрыть ветку 4
0

Судя по некоторым соискателям я думаю что в русскоязычном сегменте легко обходятся одним Савиным, прочитывая его в маршрутке по-пути на собеседование.

раскрыть ветку 1
-1

в русскоязычном некоторые обходятся и статьёй на википедии про Тестирование ПО)))
Честно признаюсь - сам начинал, даже Савина целиком не прочитав. После старта, учтя ошибки, и книжки с радостью прочитал, и в англоязычную литературу слегонца углубился, но большая часть - опытным путём.

-1

было бы неплохо ознакомится с литературой, которая помогла на пути становления qa

раскрыть ветку 6
+2

я тут уже 3 раза написал)))
Савин Тестирование дот ком
Куликов Тестирование ПО

раскрыть ветку 4
0

А что можешь сказать о книге " Как тестируют в google" ? (Джейм Уиттакер Джейсон Арбон Джефф Каролло)

Ну и да расскажи как попасть в профессию, интересно :D

P.s. отличный постъ =)

раскрыть ветку 2
0

благодарю

+1

Foundations of Software Testing от Rex Black/Dorothy Graham

Очень приятная книженция, прочитал перед сертификацией. Доступно описывает основы.

После нее (а лучше уже в ходе работы для расширения кругозора):

The Software Test Engineer’s Handbook от Graham Bath

Advanced Software Testing - Vol. 1-3: Guide to the ISTQB Advanced Certification от Rex Black (вот эти были чуточку тяжеловаты для чтения)

-3
EPAM, да?
раскрыть ветку 2
0

Видимо, минуснул кто-то из компании конкурента Епама))

-1

не, но книжку там посоветовали.

-1

Все стереотипы, которые ты перечислил, действительно имеют основание, просто относятся не к QA в целом, а к низшему звену: манки-тестерам.

Их не очень любят за то, что эта позиция - по сути "постель", через которую подавляющее большинство пытается попасть в индустрию.

Очень многие уходят из QA в ПМы, разрабов, проектировщиков (геймдизов в контексте геймдева).

-1

Сертификат ISTQB есть ?

Позиция я так понимаю не senior раз описана "вся" документация ?

И да, QA Engineer это не про тестировщиков. Позиция называется Software tester. И это не разница терминов. Требования к QA Engineer и Software tester на западе явно показывают разницу.

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

раскрыть ветку 1
0

1)У меня есть более выгодные способы потратить почти 200 баксов.
2)Я не описывал всю документацию, иначе читатель вывернет челюсть в попытке зевнуть. но да, я не сеньор

-4

Странно как то читать через слово английский и русский. половина терминов по русски половина по английски.....
почему надо писать бизнес-аналитка по русски, а спецификая по англайски, смотрится глуповато помоему.

раскрыть ветку 7
+1

Смотрится все еще лучше, чем "помоему".

раскрыть ветку 5
-2

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

раскрыть ветку 4
-1
Привычка.
Похожие посты
490

Делай добро и оно аукнется

Прочитал тут пару постов про то как люди делали добро и с ними по-свински поступали. Хочу поделиться своей историей.
Когда-то работал менеджером по продажам и должен сказать, что это ещё то болото бесперспективное... как в плане самой работы так и в плане заработка так и в плане карьерного роста. И захотелось мне изменить свою жизнь, а именно как говорится «Войти в Ай Ти». Заобщался с нашим Head of QA и тот мне порекомендовал всякую литературу плюс ко всему взял курсы при одном из именитых столичных ВУЗов.
Где-то месяцев через 7 как закончил учебу решил пойти по собесам. Конечно я столкнулся с рядом проблем ведь решают не только знания, но и опыт. В итоге меня взял к себе вышеупомянутый коллега. Прошли года и сейчас я сам руковожу группой тестировщиков. Связался с товарищем с которым когда-то работали менеджерами по продажам и узнал, что он решил пойти так сказать по моим стопам и закончил учебу, но уже пол года никуда не берут без опыта.
Вспомнил я что когда-то мне дали шанс и решил поступить также и взял его к себе. Конечно приходится вкладываться в него, но должен сказать, что знания у него есть, а стремление и трудолюбие выше всяких похвал. Скоро пройдёт испытательный срок. Команда довольно им и думаю, что возьмём его в штат.
Что я хотел сказать: Не забывайте добра и давайте сделаем этот мир чуточку лучше :D

408

Интересное требование в вакансии

Уровень жадности работодателей выходит на новый уровень или "Срочно разыскивается гость со своим самоваром"

Интересное требование в вакансии Вакансии, Headhunter, Тестировщики, Жадность, IT, Длиннопост

Я, конечно, понимаю, что продукт свой, но куда уж настолько экономить?

P.S Хм, где-то я уже видел что-то похожее:

Интересное требование в вакансии Вакансии, Headhunter, Тестировщики, Жадность, IT, Длиннопост
Показать полностью 1
885

Про тестирование VR

Общался как-то с другом по поводу VR, далее копипаст его сообщения:

"тип который vr решение разрабатывает рассказал как у них бенчмарки устроены:

сажают юзера с плохим вестибулярным аппаратом за слабое железо - если блюванул - бенч не прошёл"

4479

Стрессоустойчивый

Со слов бывшего коллеги.

Работает он сейчас в IT-компании тестировщиком. Понадобился им на проект еще один тестер. Вывесили вакансию.Долго ищут, все им не нравится. Тут HR присылает резюме - у кандидата большой опыт работы, подходящие скиллы, требования по зп ниже рынка. Сказка, в общем. Пригласили пообщаться.

На собеседовании были коллега (как тимлид) и начальник отдела.

Пришел мужичок - около 35, такой интеллигентного вида, в очочках, в пиджачке.

Стандартно начали - где были, что умеете, почему уходите.


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


Мужичок посмотрел несколько секунд на начальника исподлобья, громко хмыкнул и сказал: "Серьезно? Я почти 10 лет в профессии, и вы меня просите протестировать форму входа?" - сделал паузу - "Да идите вы нахуй". Встал и ушел.

Начальник опешил конечно, почесал затылок и выдал: "а в резюме писал -стрессоустойчивый"

70

Пол года в тестировании или взгляд с колоколенки

Почти год назад я спрашивал мнения у вас, ребята, по поводу профессии тестировщика. Было много дельных советов, и не очень, но все они были полезны в коей-то мере. И вот, я уже ровно 7 месяцев как тестировщик. Возможно, что кому-то будет полезен пост. Вероятно, что именно ты задумываешься о том, чтобы начать строить карьеру в тестировании, но пока обременён другими заботами. Я постараюсь максимально простым языком поделиться своим скромным опытом, и возможно, повлиять на твоё решение в вопросе "хочу ли я быть тестировщиком?".В общем, заваривай чайку, хватай печенюги и усаживайся поудобнее. А я беру бокал креплёного и начинаю.

Преамбула.

Войти в Ай-Ти или хлопоты "входа"

Немного цифр. После окончания универа по профилю "Энергетика" я уже окончательно для себя решил, что хочу быть тестировщиком. У меня всегда была тяга к тому, чтобы всё, чем я пользуюсь было идеальным + большое увлечение компами и еже с ними. Небольшой опыт кодинга (говно-кодинга) в конце 10-11 класса школы и первых курсов универа, но со временем всё забылось. После получения заветной корочки и месяца беспросветных кутежей, я составил резюме и начал шерстить вакансии на хх. И вот, первый отклик. Мне выслали тестовое задание, с ним я к сожалению не справился. Как говорится, первый блин комом. Затем почти один за одним были еще 3 ответа к моим откликам. Каждая компания высылала тестовое задание, которые я уже успешно выполнил и впереди у меня состоялись 3 первых в моей жизни собеседования. Первые два я успешно провалил, а на третьем, уже имея некоторый опыт в общении с HR и тестировщиками, успешно его прошел. Спустя приблизительно неделю в один жаркий летний день мне позвонили и сообщили, что с 1 сентября я выхожу на работу. Это была моя маленькая победа. К слову, я даже рад, что в предыдущие места меня не взяли, но об этом дальше.

Ах да, цифры, подытожим - 4 отклика, 4 тестовых задания, 3 собеседования, 1 успешное, затраченное время около 3 недель.

Испытательный срок или оклад за обучение

После оффера (успешного прохождения собеседования и приглашения на работу) я начал усиленно готовиться, читал блоги, смотрел видео, впитывал и вкушал опыт других, бывалых тестировщиков. Первые два месяца я приходил на работу и изучал документацию по продукту, который мне предстояло тестировать, смотрел видео-уроки (записывали их тестировщики из компании). Очень круто, что для лёгкого входа новичков был весь необходимый материал, это очень помогло. В течение месяца я каждый день изучал новое, а два раза в неделю общался с менеджером разработки (член команды, который ставит задачи, общается с заказчиками и вообще, занимается многими организационными вопросами + защищает нас от других команд, которые хотят скинуть свои косяки на нас), рассказывал ему, что нового узнал, отвечал на его вопросы. Честно, я ощущал себя идиотом, который нифига не понимал, но очень хотел и старался вникнуть в процесс. Какие-то непонятные названия, странные слова Agile, Scrum, МР, ПМ, Тим-лид и прочие, уже кажутся такими простыми и примитивными, но тогда, будучи совсем зелёным, я их до конца не мог сложить воедино. Первые три месяца пролетели быстро, но их я запомню на всю жизнь - это самое болезненное время, когда много, просто невероятно МНОГО информации, которую нужно усвоить и научиться использовать.

И вот, наступил декабрь. К этому моменту я успешно прошёл испытательный срок. У нас была даже некая балльная система, по которой по всем критериям у меня было 5/5, что не могло не радовать + положительный отзыв МРа. И в декабре, когда я уже неплохо освоился, состоялась ретроспектива. Ретроспектива - это некое собрание, когда команда обсуждает предыдущий квартал, какие были проблемы, находит пути их решения, подводит итоги и строит планы на следующий квартал. Цель - стать лучше. Одна из задач - разрешить предыдущие проблемы. И на этой ретроспективе я понял, что эта команда та самая, с которой можно свернуть горы и сделать наш продукт очень крутым. Я много читал историй, когда коллектив, мягко говоря - хрень, но в моём случае все более, чем круто сложилось. Ребята, зная, что я совсем зеленый, легко отвечали на все мои самые глупые вопросы, чем я старался не злоупотреблять.

Пошло-поехало

Прошло ровно пол года, как почувствовал, понял, осознал (как это не назови), что тестирование - это моё. Именно спустя пол года я понял, что то, чем я занимаюсь - это призвание. Естественно, что бывают косяки, не тестируемые задачи и прочие грустны вещи, но целая картинка позитивна!

Результат работы

Спустя 7 месяцев я научился и освоил некоторые инструменты и приобрёл скиллы, а именно:

PostgreSQL (СУБД) на уровне, который нужен тестировщику (анализ связей в БД, типов данных, запросы для тестирования и выборки данных);

Консольку Linux для просмотра логов, кода на тестовых стендах, правки "на горячую", всякие curl и прочие мелочи;

Различные техники тест-дизайна;

Буквально в последний месяц начал писать автотесты в связке Ruby+Selenium Webdriver+(всякие гемы аля Browsermob-proxy);

Написание документации (тест-планы, тест-кейсы, чек-листы и пр.);

Ну и всякие мелочи из разряда "деплоить ветку на тестовый стенд", "проверить наличие задач в ветке".

Вывод и скромный совет

Хотел бы обратиться к тебе, читатель. Если ты прочитал до этого места, то тебе в принципе интересно всё о тестировании, даже бредни джуна. Запомни одно - если чувствуешь, что это твоё - "не тормози сни..." не распыляйся и занимайся этим. Тестировщики - это ценные сотрудники, они отвечают за качество продукта, а следовательно экономят деньги заказчикам и делают конечных пользователей чуточку счастливее.

Задавай свои вопросы в комментарии и я с удовольствием отвечу на них.


P.S: Под понятием "тестировщик" я объединил и, непосредственно тестировщиков, и QA, и QC, не будите занудство и не проявляйте проф. деформации :) peace.

Показать полностью
56

Все поздравляют дизайнеров, а про QA забыли

Все поздравляют дизайнеров, а про QA забыли QA, Тестировщики, День тестировщика

День тестировщика — профессиональный день тестировщиков, отмечаемый 9 сентября.


9 сентября 1947 года[1][2] учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле, и Грейс Хоппер произнесла слово «bug» (англ. «жук»), ставшее позднее термином, обозначающим компьютерную ошибку. Извлечённое насекомое было вклеено в технический дневник с сопроводительной надписью: «First actual case of bug being found» (англ. «первый случай в практике, когда был обнаружен жучок»). Этот забавный факт положил начало использованию слова «баг» в значении «ошибка». В итоге процесс выявления и устранения причин сбоя в работе компьютера получил название debugging (дебаггинг, «отладка», дословно: избавление от жуков). А само название профессии возникло от английского слова test, то есть испытание.

Похожие посты закончились. Возможно, вас заинтересуют другие посты по тегам: