Это копия, сохраненная 14 марта 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Гайд, который вы можете дополнить:
http://pastebin.com/6p6gmxNv
Старые треды на архиваче:
https://arhivach.org/thread/144412/
http://arhivach.org/thread/100295/
http://arhivach.org/thread/66881/
http://arhivach.org/thread/177364/
http://arhivach.org/thread/186448/
Всем привет.
Вопрос к ДС и ДС-2 : поясните за компанию Logrocon?
Пришёл на собеседование, и, пока ждал начальника, залез в интернеты и почитал отзывы - якобы пидорашья контора, без соц.плюшек, со штрафами, увольнениями и прочим угаром.
В ходе собеседования я задавал провокационные вопросы на сей счёт, и на это все как-то уклончиво было отвечено в итоге. Оффер дали, даже чуть больше, чем я сам просил. Стоит идти вообще или лучше подыскать что-то получше?
Оффер - это приглашение на работу. Как тебе могли дать приглашение больше или меньше?
Алсо, проходил там собеседование. По тех. части вроде бы Игорь спрашивал- хороший специалист, дал чёткое понимание, что должен уметь тестер с опытом 3 месяца, полгода, год и т.д. ЗП новичка без опыта работы выше, чем в Перфоманс Лаб раза в 1,5- 2 (около тридцатки). Начальник тоже понравился, собеседование хорошо прошло, поговорили с ним по душам. Но я устроился в другую компанию, пока ждал ответа от них. Так что больше ничего не знаю.
Требуется литература или просто какие-нибудь статьи, не обязательно на русском, где бы были максимально подробно описаны примеры тестирования каких-то крупных систем/проектов, успешно применяемых ИРЛ в наше время. Я не могу даже нормально запрос в гугл сформулировать, но уверен, вы можете помочь. Хотя бы одну ссылочку, плз))
ctrl+t ctrl+l g test planning best practice enter
книга "как тестируют в гугл" тебе подойдет, по остальному спрашивай тут
>дал чёткое понимание, что должен уметь тестер с опытом 3 месяца, полгода, год и т.д.
Расскажи нам плз
Могу по книгам рассказать.
Тестирование программного обеспечения (Канер) - с нее можешь начать
Как тестируют в Google - зарядись настроением и веслая дальше
Tester's Pocketbook - удачи в поисках электронки, я не нашел, если найдешь - напиши
Lessons learned in software testing - морально приготовься читать её год или больше
А больше ничего посоветовать не могу, потому что весь свой небогатый опыт пришлось получать на практике. Поэтому, задавай вопросы.
Ещё за pairwise testing тоже самое спросить хочу.
Всем добрый вечер, возможно вопрос платиновый, но все же. Хочу вкатиться в тестировку, почекал объявления на хх в своем залупинске - везде требуют высшее образование. Это серьезно так? Я дропнул сраный вуз и возвращаться туда не хочу. Реально ли дорасти до сеньора и быть успешным тестером без вышки7
Запросто. Игнорь это требование и шли резюме.
Если ты им не понравишься, то у них будет удобный повод тебе отказать, вот и все.
оффлайн pocketbook от пола джеррарда урвал на sqadays20, а в электронке на халяву и правда нету
серега заебал бля, го в танки
Сейчас в моде говорить, что тестер должен тестировать и ставить задания разрабам.
А код пускай пишут те, кто это делает 8 часов в день.
А так да, есть.
В-основном, пишу тесты на бэкэнд (NUnit, Approvals, FluentAssertions если по фреймворкам смотреть).
Фронт тестирую руками. Мог бы писать селениумные тесты, но это очень долго, поэтому чаще не пишу, чем пишу.
Вышка не важна в большинстве компаний. Курсы тоже, как и стажировка - курсы преподаются ради курсов и заколачивания бабла. Напиши в резюме что работал 3 мес где-нибудь с друзьями-фрилансерами, почитай определения, и за месяц найдешь работу
После нового года подожду пару месяцев и пойду устраиваться или "чистым" автоматизатором, чтобы больше не вникать в эти все тестовые случаи и спокойно писать тесты, или устроюсь говнокодером на джаве и так же не буду больше ни во что вникать. Никогда.
Просто выговорился.
тоже собирался но не пошел, у них манагеры оч. хорошие. Прям по общению понравился, даже стыдно было отказываться в итоге
Двачую, правда я пришел вобще нихуя не зная, вообще1 Мне дали порешать логические задачки, чтобы убедиться что я не олигофрен. Так в 27 лет я стал около айтишником.
Нет, я люблю вкалывать, челленджи, своего рода трудоголик. Но именно тестирование само по себе не возбуждает. Была коллега, так она действительно относилась к этой деятельности очень трепетно и изучала технололгии именно с точки зрения "как это сломать", продумывая не только хеппи пасс, но и самые невообразимые для нормального человека кейсы. А я отношусь к этому холодно, скучно.
Хм, очень интересная позиция.
Я вот стремлюсь тоже к автоматизации, и, наверное к составлению кесов самостоятельно. Т.е. есть полное понимание того, что тестировать, как тестировать и какие результаты на выходе следует ждать.
кризис среднего возраста тестировщика как он есть
все через это проходили, не все в тестировании остались
Ага, постоянно же просят "Создать баг", ну вот я и...
>>803169
Да нельзя так, сидеть и выполнять роль и тестера, и аналитика, и разработчика. В итоге слишком огромный пул ответственности и должностых обязанностей выходит
>>805339
Но опыт фактический у меня небольшой. Сначала такие мысли были когда только начинал, месяца через два, и вот опять
1) Плюсы, минусы на твой взгляд.
2) PICT'ом или подобным софтом пользуешься/пользовался? Или сам ебошишь кейсы?
3) Новую фичу лучше тестить в режиме Exploratory testing или скажем накидать тестов при помощи pairwise и оттестив можно сказать что работает? Реально ли оттестить какой нибудь функционал достаточно годно, только при помощи pairwise методики?
4) Ну и если есть желание то можно высказаться по поводу exploratory testing vs тестирование по тест кейсам
5) Саня это ты?
Теперь думаю есть ли смысл вообще лезть в тестирование, не имея технического профиля?
Во всех стажировках и вакансиях указывают в требованиях "ВО техническое"
Я прямо опечален, неужели у меня дорога к тестированию закрыта?
1) Да хуй знает, мужик. Я как-то на курсах его юзал как бы. По идее этот метод может покрыть весь функционал тестами, но, как правило, в компаниях нет времени на такое долгое тестирование, поэтому Smoke Tests, регрессионное - наше всё.
2) Я пользовался файлом pairwise. Т.е. создаешь excel - файл, вписываешь свои параметры, которые надо. Затем заходишь в командную строку - запускаешь этот файл, указываешь путь к эксельке и вуаля - на следующем листе он тебе всё формирует.
3) Тут как тебе удобней, и ещё зависит какой объем фичи, в общем-то. Можно, конечно, и исследовательским пройтись, но что-то упустишь, скорее всего. А pairwise можно заюзать, если функционал небольшой.
4) Тестирование по тест-кейсам заебись в том плане, если ты новенький. Берешь кейс, и проходишь ручками, заодно знакомясь с продуктом. Для автоматизаторов тоже хорошая штука - всё перед глазами: что сделать и что следует ожидать. Плюс это документ, который ты можешь показать начальству, дескать, я не только капчую на работе.
5) Нет, не Саня.
https://habrahabr.ru/company/rambler-co/blog/303254/
Если ты начинающий. По этой статье вкатился. Сейчас уже автоматизирую, например.
Никто не станет не брать только потому что "нет ВО", просто это очень удобное самооправдание нулевым знаниям и общей собственной тупости.
Ой! А ты считаешь, что диаграммы состояний уже не актуальны?
Сложно поверить в то что блок-схемы(считай тоже самое что state transition diagram) вообще когда нибудь станут неактуальны.
Ведь грамотно используя эту поебень можно:
1) Тестить (визуализация флоу, например)
2) Документировать например код (да блядь погромисты не любят этим заниматься, но представляешь если бы ты получил на тестирование переделанный в корне процесс сайнапа документированный при помощи state transition? мне кажется ты бы жопу целовал тому прогеру)
3) Просто наглядная визуализация чего угодно (и даже неба, даже Аллаха)
Не начинающий.
Просто столкнулся с такой проблемой что порой в связи с нехваткой времени не могу нормально оттестить новую фичу.
Соответственно пытаюсь найти подход который помог бы мне быстрее и качественнее тестить.
State transition раньше не пользовался, но кажется что это может помочь ускориться. Ибо
как я уже написал в посте >>810061
Это должно помочь увидеть весь флоу в целом + при написании сразу автоматом всплывают -хорошие негативные кейсы или же дыры в стори. (ну это при хорошем уровне знания проекта собственно, что вроде бы у меня есть).
Хотелось бы услышать мнение по поводу поможет ли это решить распространённую проблему нехватки времени. Вот собственно в таком разрезе и хотелось бы услышать мнение людей которые пользовались этим методом.
1) То есть в реале не практиковал... Печаль. А вообще какими нибудь методиками пользуешься?
2) Звучит как будто PICT. Такая утилитка через консоль виндовую работает и да сохраняет результат в excel файлик
3) Ну ок если не исследовательское, то как тестить? Я один тестер на проекте, например.
4) Тест кейсы хороши не только в этом плане. Как минимум есть ещё полезная особенность. Когда описываешь функциональность нормальными тест кейсами, ты потом можешь по ним же её и тестить вообще моск не напрягая. (очень хорошо, когда например в конце рабочего дня выдают хотфикс, который блядь надо мёржить 100% прям сичас сука, для какого то функционала, а бошка уже не варит). Тут конечно надо поддерживать их и тд тп. Отдельная история.
5) Ну, ок
В реальности времени на это ни у одной конторы нет, я не видел, в военке/космонавтике наверняка такое дрочат, в энтерпрайзе - хуй там.
1) Я больше по документации сейчас, друг. Тест-кейсы, инструкции, FAQ, Wiki вот это всё. Иногда тестирую ручками какой-либо новый функционал, но тут я тестирую именно функционал. Могу задать наводящие вопросы, что приводит к дикому холивару в переговорках, лол.
2)Именно. Если надо, могу поискать и залить куда-нибудь.
3)Обмажься майнд-картами. И от неё уже исследовательское тестирование будет более осознанным.
4) Тест-кейсы наши всё вообще.
Ну скажу диковатенько. Если честно посмотрев на весь стек технологий понял что это мне не то. Не уверен что приняли. Но если и так, то ясно что я сейчас объективно буду уровня говноджуна, который тупить непроходимо будет. Если они готовы взять - их проблемы. Я конечно хуи пинать не собираюсь, но уверен что поседею в свои 23 от натуги за первый месяц.
Я думал меня хоть пощадят, на что полегче кинут как еьюфага.
.понял еще что вне сред разработки на листочке с ручкой я блядское ничтожество.
Не уверен что взяли, ну и хер с ним.
>>817821
Года полтора, плюс минус
Да ебать, вообще не понимаю: нахуй давать задания с написанием кода на листке? Когда в любой момент есть интернеты с документацией к любому фреймворку со стековерфлоу, где можно найти ответ на любую ошибку.
Бывало, что обсирался так, а бывало, что нет, но все равно не понимаю этого дроча. Логические задачи с двумя стульями - тоже. Обсмотрятся своих Тим Куков и ябутся в жёпу и давай так же себя вести.
Как по мне, что важно на собеседованиях: сама теория тестирования, поговорить, какой опыт имеет, с чем человек работал, как работал, какие инструменты использовал + тестовое задание какое-нибудь. Можно перед собеседованием, например.
Мне однажды на собеседовании дали тестовое задание на дом сделать автотест на Selenium + Python, с кучей условий, а я вот-вот только синтаксис выучил. Я, благодаря этому, втянулся в автоматизацию очень быстро, вел переписку с работодателем, тот мне давал советы, что да как. Хоть меня и не взяли, но отношение очень крутое у этих ребят. Респект им.
Не ебу. Да и логические задачки(про стрелки на часах давали). Не скажу что это шибко сложно все, просто я тупарь.
Жаль конечно, ну поищу себе менее навороченный проект. Так то хер с ним, я и щас не шибко на жизнь жалуюсь, просто функциональной макакой быть подзаебывает, слышишь как тупеешь порой.
Мне на собеседовании (меня туда взяли, кстати) задавали такие загадки:
1) Есть ящик с носками, всего 3 цвета носков в этом ассортименте. Через сколько вытащенных носков ты достанешь пару?
2) Есть многоэтажный дом у берегу реки. Как сделать так, чтобы дом оказался на другом берегу реки? Я ответил, что перекопать реку, изменив русло, парень мальца охуел от ответа, а как иначе-то?
Поставить на другом берегу большое зеркало, под таки ракурсом чтобы река не задваивалась.
Сраный хомяк. Улыбается.
Вот мне HR-ы также улабываются, а потом говорят "мы вам перезвоним."
Тупые вопросы, 1 - чистый тервер, я вот нихуя не помню уже, я бы на него спросил, а что, проект на который меня посадят как-то связан с расчетом вероятностей?
2) Тут я бы молча встал и поссал со беседующему на ебало, эта хуйня в 2016 уже не то что не смешна, а вполне заслуживает занясения подобных маняработодателей в черные списки.
Тогда тебе не перезвонят. Кому нужен работник, который при виде любой неожиданной задачи по тестированию встанет и уйдет?
Ты не понял, это я выбираю фирмы, а не они меня. Мне не нужна фирма, где собеседуют ебланы.
2. Переплыть на другой берег, очевидно же.
Считай, что система координат привязана не к дому, а к тебе.
>Считай, что система координат привязана не к дому, а к тебе.
Где об этом сказано в условии? Мы вам перезвоним.
Где в условии сказано, что решение только одно, которое ты прочитал в интернете, когда готовил вопросы к собеседованию?
Ещё раз, ты начал придумывать не уточнив условия - это сразу пошел нахуй для QA. Одна из ошибок за которую сразу нужно пиздить ногами стажеров.
Это ОНИ не уточнили условия. Значит, я могу трактовать задачу как угодно.
И вообще я в этом треде мимо, просто блистаю смекалочкой.
Лол, тебя бы на собеседование в любую дно-контору даже, посмеяться можно знатно было бы с твоих профанских высеров.
Наверное проблема в том, что ты хуевый QA, раз начинаешь отвечать на задачу не уточнив явно упущенные детали.
Блядь, я понятия не имею, что такое QA, и писал об этом выше. Я зашел сюда и опустился до вашего уровня, только чтобы блеснуть нестандартным мышлением и великолепным образованием, а больше мне с тобой говорить не о чем.
Только ты обосрался на нашем уровне, уебывай, клоун.
Ты не поменял положение себя относительно дома и берега, он остался на том же берегу, где и был. А то, что ты сначала видел его слева, а потом справа, роли не играет.
Компания вполне нормальная, и загадки эти задавались на на серьёзных щах.
Касаемо дома и берега: его в буквальном смысле надо было перенести на другой берег, без систем координат и зеркал.
И да, на самом деле мне и сказали, что эти вопросы задаются, чтобы проверить: потеряется ли человек или начнет генерировать идеи.
>QA-эксперты в треде
А с чего ты решил, что нет?
>не на серьёзных щах
Это дебилу ясно, только вопрос, насколько логично в 2016 году баловаться детсадовскими психулохическими проверочками из 1980-х вместо нормальных вопросов по работе.
Не хочу тебя подъебать.
Чисто для поддержания беседы: какие вопросы ты бы задавал на собеседовании соискателю на должности: джуна, миддла, сеньора?
Можешь сам определить, какие скиллы у кого должны быть.
Для этого тред и затевался, чтобы пообщаться с QA-экспертами, но пока что дело дальше бахвальства и мерений хуями не зашло.
Ну, хотелось человеку ещё со мной пообщаться и что-нибудь ещё спросить, ибо по теории, практическому опыту он спросил всё, что нужно. Спросил, как я буду действовать в той или иной рабочей ситуации. И в конце, как бы нехотя, задавались эти загадки, которые, я думаю, не совсем уж и влияли на отбор.
Все от специфики компании зависит же. Какими инструментами она пользуется, на каком языке пилится софт, пишутся автотесты, web - desktop - android - ios ? И ещё куча факторов, какие знания потребуются джуну/миддлу/сеньору.
Нет смысла разжевывать и так получится полотно, для начала определимся с требованиями к градациям:
Джун - должен знать базовую теорию, не быть идиотом, думающим что работа тестера - это находить баги\ломать продукт, уметь и желать учится, уметь в социалку. Работает по указаниям сверху, задачи ему ставят.
Мидл - хуй пойми что, недолид(сеньоров как факт не существует в QA, если не идти в градацию testing/qc/qa). Самое важное отличие от джуна - может самостоятельно выбирать и создавать задачи, понимает какой приоритет какой выставить при создании, т.к. хорошо ориентируется в бизнес логике и ожиданиях клиент согласно требованиям.
Сеньор в 100% лид\йоба-автоматизатор, знающий все предыдудщие уровни. Вообще, в целом, автоматизация здесь так-то не при чем, автоматизатор не понимающий QC/QA - это конечно охуенная штука с точки зрения продажи лоху-клиенту, но абсолютно бесполезная обуза для проекта.
Чтобы задавал? Ну джуну с мидлом понятно. А вот предтоп сеньору\сеньору уже сложнее. Важно понять понимает ли человек, что есть QA и как обеспечить именно качество, а не тестирование на проекте, в 95% случаев тут нужен именно опыт, никакие бахи с мейлру курсами тут никак не помогут. В целом накидал бы ситуаций вроде "есть 100 задач" за какую сам возьмешься, на какую джуна посадишь. Ну и у них естественно разная бизнес-ценность( о чем вечно забывают джуны с горящими глазами, для которых критерий один - критичность) и т.д. Про автоматизацию все же не хочу, это надолго расписывать. Так то начал бы с элементарщины вроде интерфейсов и прочей хуйни, затем именно по тестированию прогнал бы с точки зрения организации фреймворка для удобства переиспользования и поддержки.
Да дохуя можно по каждому пункту добавить, но описывать всё в целом - это много, лучше конкретные вопросы задавайте ситуационные, т.к. наверняка многое, что можно в общем описать упустил.
Просто я не вижу смысла тратить на этот детсад время вообще, на наших собеседованиях и так по минимуму рабочих и теоретических вопросов занимает 30 минут, а это уже достаточно много если прогонять 2-3 кандидатов в день лучше побольше конкретики и реальных примеров извлечь из соискателя, подобную хуйню можно хоть на электронку слать, если уж хочется посмотреть че за херню понапишут из интернетов.
Напиши автотест со входом во ВКонтакте. Залогинься - выйди с неё - снова залогинься ( верстка поменяется), введя неправильный логин или пароль - введи корректный логин и пароль. Тебе пока что хватит этого.
Ну, если ты сам ищешь работу, то можно и проявить терпение в таких ситуациях - убудет, что ли, с тебя, если ты ответишь на отвлеченные вопросы?
Другое дело, если на тебя сами выходят - зовут на собеседование, и там уже дают анкету, в которой надо заполнять данные по опыту работы, то там можно и нахуй послать таких артистов, хотя тоже, тут дело такое. В сфере нужны стрессоустойчивые люди, без заскоков и истерик, если что-то пошло не так.
Просто у меня есть выбор и МНЕ не нужна контора в которой нужны особо стрессоустойчивые люди.
Предыстория:
Ищу работу джуном-мануальщиком без опыта вот уже 4 месяца. За это время почитал Савина и теорию на Хабре, посмотрел немного вебинаров по QA, попрактиковался на клаудтестинговых площадках, в основном на test.io, там же заработал и вывел первые деньги (каких-то 35 евро, но для висящего на шее у родителей хикки уже хоть что-то). Справлялся вроде бы неплохо, судя по тому, что мои баги почти не rejectили. Английский хороший, вышка профильная есть.
Но вот нормальной работы найти так и не смог - почти нет нифига вакансий в этом городе, это при том, что я их просматриваю каждый день благодаря настроенной рассылке с сайтов поиска работы. Везде требуется либо опыт и/или знание кучи всяких технологий, либо навешают помимо самого тестирования обязанности хелпдеска, а то ещё и сисадмина, либо же автоматизация. За всё это время нашёл всего три вакансии: одна оказалась от мошенника, одна - не ответили на резюме, а о последней и поведу речь.
Вакансия была от игродельческой конторы, занимающейся казуалками для мобилочек, в основном жанра hidden object (это такой упрощенный графический квест для девочек, в котором в перерывах между историей даются картинки, на которых нужно выискивать мелкие разнообразные обьекты, коих там великое множество). В требованиях было лишь знание базовой теории, умение работать с багтрекером и любовь к играм лол. Отослал резюме, меня спросили, мол, что я тестировал, умею ли в Jira и сколько хочу денег (200$), потом выслали тестовое задание, состоявшее из двух подзаданий. В первом был типа скрин из hidden object игры, на котором было криво прифотошоплено куча всякой ерунды, и задание - найти максимальное количество графических багов. Во втором - кривая программулина, которая умеет сортировать добавленные строки текста по заданным подстрокам, со спецификацией, задание - найти и подробно описать 5 багов на инглише. Нашёл 22 бага на картинке и 6 в софтине (хотя их там было больше, но я остановился на 6), причём старался - завёл под баги doc-файл, в который вставил картинку с найденными багами в красных пронмерованных рамках и коротким описанием каждого, рассортированных по severity, и багрепорты к софтине, разбитые на поля аналогично интерфейсу заведению багов в багтрекере (т.е. заголовок, шаги воспроизведения, actual/expected result, severity и прочее) с записанными видео по каждому багу. Всё это красиво оформил стилями (и зачем оно мне было надо).
В итоге пригласили на собесод. Так, как раньше я на собеседованиях не был - жутко трясся, вычитал все интернеты на эту тему, а по QA вызубрил всё, что они могли спросить, упражнялся вслух рассказывать перед зеркалом. Из-за нервов же приехал к месту на час раньше, лол.
Собеседовали меня двое. Один из них, как я понял, был тимлидом. Спрашивали сперва, в основном, теорию тестирования (виды/типы, что такое тест-план, тест-кейс и чеклист, из чего состоит багрепорт, уровни severity и прочее) и что у меня за опыт, потом дали тестировать нарисованную на листе программу, которая вычисляет площадь прямоугольника. Теорию я им оттараторил наизусть, они лишь кивали и почти не задавали вопросов (спросили только лишь, доводилось ли писать тест-планы (нет)), но вот на программе начал от нервов фейлить и описал почти все возможные кейсы, кроме самого простого - надо тупо посчитать умножение a на b и проверить, правильный ли резльтат выдаёт программа. Один из них сказал, что это самый первый тест, который я должен был провести. Стыдоба, блджад.
Ещё спрашивали, мол, почему хочу быть тестировщиком. Я начал описывать, как я любил всегда ковырять софт и игры, и что очень хочу к ним, потому что хочу в геймдев (что, собственно, правда). А ещё меня спросили, есть ли у меня какие-то вопросы про компанию - и я не догадался ничего больше спросить, кроме как про зарплату... Пиздец.
На следующий рабочий день написал эйчару, на что она мне ответила, что, мол, "мы не готовы продолжить с вами общение по данной вакансии". На вопрос - чем я не угодил, написала, что у меня "очень хорошие знания и в целом достаточно умений", но взяли чувака с опытом коммерческого тестирования игр.
Как-то так.
Анон, подскажи, так уж ли я сфейлил? И, на будущее - какие вопросы (кроме очевидных зарплата-условия-соцпакет) стоит задавать? Ну и просто интересны твои мысли по этой моей писанине.
Олсо, спасибо, если дочитал до этой строки :)
Предыстория:
Ищу работу джуном-мануальщиком без опыта вот уже 4 месяца. За это время почитал Савина и теорию на Хабре, посмотрел немного вебинаров по QA, попрактиковался на клаудтестинговых площадках, в основном на test.io, там же заработал и вывел первые деньги (каких-то 35 евро, но для висящего на шее у родителей хикки уже хоть что-то). Справлялся вроде бы неплохо, судя по тому, что мои баги почти не rejectили. Английский хороший, вышка профильная есть.
Но вот нормальной работы найти так и не смог - почти нет нифига вакансий в этом городе, это при том, что я их просматриваю каждый день благодаря настроенной рассылке с сайтов поиска работы. Везде требуется либо опыт и/или знание кучи всяких технологий, либо навешают помимо самого тестирования обязанности хелпдеска, а то ещё и сисадмина, либо же автоматизация. За всё это время нашёл всего три вакансии: одна оказалась от мошенника, одна - не ответили на резюме, а о последней и поведу речь.
Вакансия была от игродельческой конторы, занимающейся казуалками для мобилочек, в основном жанра hidden object (это такой упрощенный графический квест для девочек, в котором в перерывах между историей даются картинки, на которых нужно выискивать мелкие разнообразные обьекты, коих там великое множество). В требованиях было лишь знание базовой теории, умение работать с багтрекером и любовь к играм лол. Отослал резюме, меня спросили, мол, что я тестировал, умею ли в Jira и сколько хочу денег (200$), потом выслали тестовое задание, состоявшее из двух подзаданий. В первом был типа скрин из hidden object игры, на котором было криво прифотошоплено куча всякой ерунды, и задание - найти максимальное количество графических багов. Во втором - кривая программулина, которая умеет сортировать добавленные строки текста по заданным подстрокам, со спецификацией, задание - найти и подробно описать 5 багов на инглише. Нашёл 22 бага на картинке и 6 в софтине (хотя их там было больше, но я остановился на 6), причём старался - завёл под баги doc-файл, в который вставил картинку с найденными багами в красных пронмерованных рамках и коротким описанием каждого, рассортированных по severity, и багрепорты к софтине, разбитые на поля аналогично интерфейсу заведению багов в багтрекере (т.е. заголовок, шаги воспроизведения, actual/expected result, severity и прочее) с записанными видео по каждому багу. Всё это красиво оформил стилями (и зачем оно мне было надо).
В итоге пригласили на собесод. Так, как раньше я на собеседованиях не был - жутко трясся, вычитал все интернеты на эту тему, а по QA вызубрил всё, что они могли спросить, упражнялся вслух рассказывать перед зеркалом. Из-за нервов же приехал к месту на час раньше, лол.
Собеседовали меня двое. Один из них, как я понял, был тимлидом. Спрашивали сперва, в основном, теорию тестирования (виды/типы, что такое тест-план, тест-кейс и чеклист, из чего состоит багрепорт, уровни severity и прочее) и что у меня за опыт, потом дали тестировать нарисованную на листе программу, которая вычисляет площадь прямоугольника. Теорию я им оттараторил наизусть, они лишь кивали и почти не задавали вопросов (спросили только лишь, доводилось ли писать тест-планы (нет)), но вот на программе начал от нервов фейлить и описал почти все возможные кейсы, кроме самого простого - надо тупо посчитать умножение a на b и проверить, правильный ли резльтат выдаёт программа. Один из них сказал, что это самый первый тест, который я должен был провести. Стыдоба, блджад.
Ещё спрашивали, мол, почему хочу быть тестировщиком. Я начал описывать, как я любил всегда ковырять софт и игры, и что очень хочу к ним, потому что хочу в геймдев (что, собственно, правда). А ещё меня спросили, есть ли у меня какие-то вопросы про компанию - и я не догадался ничего больше спросить, кроме как про зарплату... Пиздец.
На следующий рабочий день написал эйчару, на что она мне ответила, что, мол, "мы не готовы продолжить с вами общение по данной вакансии". На вопрос - чем я не угодил, написала, что у меня "очень хорошие знания и в целом достаточно умений", но взяли чувака с опытом коммерческого тестирования игр.
Как-то так.
Анон, подскажи, так уж ли я сфейлил? И, на будущее - какие вопросы (кроме очевидных зарплата-условия-соцпакет) стоит задавать? Ну и просто интересны твои мысли по этой моей писанине.
Олсо, спасибо, если дочитал до этой строки :)
Да нигде не сфейлил, просто продолжай искать. 100% собеседований не пройдет никто, ни бах, ни канер. Спрашивать стоит все от проекта на котором тебе работать, о вообще проектах фирме топовых, которую её кормят( отсюда можно понять, сколько тебе потенциально могут платить) о распорядке рабочего дня(дрочят ли приход к 8). Да бля, спрашивай, что тебе интересно, некорректных вопросов тут быть не может, это ты им платишь, чтобы они тебя подгоняли и получали себе прибыль, а не наоборот.
Нигде. Если есть возможность, то попробуй сразу же после собеседования поговорить с директором/лидом (ненавязчиво, иначе только хуже сделаешь), взять номер/дать свой, если есть возможность. Я так без опыта вкатился на фронт, хотя потом из хипчата прочитал, что все хотели взять другого паренька, который имел год опыта (его потом тоже взяли), а меня ставили на второе место после него, но начальство решило, что иду я, просто из-за того, что после собеса перекинулся парой слов с директором, взял номер и дал свой.
А я тебе скажу, где ты проебался - в самом собеседовании. Даже если ты признаешь, что волновался и трясся, то смело можно масштабы произошедшего умножать на два.
То, что ты знаешь теорию - это заебись, но работодателю нужен уверенный в себе человек, который умеет в общение, и сможет влиться быстро в коллектив, для которого не проблема ПРОСТО взять и подойти к специалисту, со стороны которого всплыли баги, и причем не слиться от :"Это фича, иди гуляй, Вась".
Работодателю нужен работник, который на реплику: "Блядь, релиз вечером, а у нас кровь-кишки-распидорасило, тестируй и давай оценку" не будет рвать волосы на себе и трястись в конвульсиях, а возьмет, и протестирует до вечера и скажет свою оценку. Спокойно. Тебе это надо прокачивать. Иначе тебе искать только аутсорс придётся. Да и 200 у.е. это конечно вообще ахуеть - не проще кассиром пойти? Там, наверное, столько же платят. С какого ты города и страны, например?
>200$
Сирисли? Я как то упустил этот момент, нахер за такие гроши идти куда-то кроме как просиживать жопу охранником? Да и те меньше 15-20к не получают.
Всё также ищу, просто хотелось попасть именно туда, в геймдев - это ж мечта детства, лол. Ну или хотя бы софт для ПК или мобилок тестить. От веба, который в большинстве вакансий, уже тошнит но согласен уже на всё, ибо деньги пиздец как нужны.
За вопросы спасибо, возьму на заметку. У меня вот вообще в голове было пусто, да и боялся неуместное что-то спросить. Например, интересно было, планируется ли у них выпуск игр не pay-to-win free-to-play, а по нормальной премиумной монетизации, но боялся, что спалят мою нелюбовь к донату и не возьмут. Ещё интересовало, опенспейс у них или кубиклы, но это я уже придумал, когда ехал домой, блджад.
>>823224
Ох, как бы не намолоть лишнего при такой беседе. Если выдастся шанс, на следующем собесе попробую, спасибо.
>>823264
Дело в том, что в общение по делу я таки умею. Про "фичу" - хотя бы попробую возразить, что юзеру такая фича не понравится, например. Про "релиз вечером" - буду сидеть и тестировать, хоть не отрицаю, что буду оче волноваться.
А трясся но собесе потому, что очень хотел попасть туда и боялся что-то лишнее ляпнуть (я это, увы, умею, лол). Ну и первый собес как-никак, всё ж волнительно, что-то новое в жизни.
>>823264 >>823433
>200$
Ну хрен знает, в вакансиях часто стоит подобная зарплата, выше только для людей с опытом/знаниями покруче. Кроме того, боюсь перегнуть, чтобы не сказали, мол, "а ты не охуел столько просить?" или просто общение дропнули. К тому же, живу экономно (хикка же), меня и меньшее устроит, но тут уже боюсь продешевить. У меня друг врачом-аспирантом ещё меньше получает, например.
>С какого ты города и страны, например?
Украина, город почти-миллионник, приморский.
Не отчаивайся. Ты должен завалить какое-то количество собеседований, чтобы тебя приняли, это просто такое вот испытание статистикой для джунов. И волнение на собеседовании тоже улетучится через какое-то время. Я помню, что всего пару лет назад мне аж водичку яростно предлагали, так сильно трясло. Зато после работы над ошибками и успешного прохождения собеседования в другую контору все очень сильно изменилось.
А вопросы работодателю обязательно продумывай заранее. Нет ничего такого, что ты должен спросить, однако это практически единственный шанс узнать, в каких условиях придется работать и что за проект. Я обычно выбираю, что бы НЕ спрашивать, лол. Самый минимальный набор без технической части:
- Сколько человек в команде, сколько разработчиков/тестеров, кто продуктовнер?
- Какая методология разработки на проекте? Как часто релизы?
- Какой график? Приходится ли перерабатывать? Есть какая-то система штрафов?
- Белая / серая зп?
- Как оборудовано рабочее место, где я буду сидеть? (в последнее время на этом моменте меня приглашают прогуляться по офису и познакомиться с командой, если они еще на рабочем месте)
- Кого вы действительно ищете, какие будут задачи у нанятого человека
- Критерии и срок завершения ИС (если контора серая)
Алсо, в геймдеве нужно быть готовым строить из себя соционяшу и показывать, что ты в теме. Мне раньше часто попадались всякие конкурсы типа "пилим 100 игр за 10 дней" где ньюфаги делали свои простенькие игры на движке. Думаю, стоит влиться в такие сообщества и грамотно указать о своем участие в резюме
Вообще беда какая-то, я, кажется, слишком хорошо умею проходить интервью и составлять резюме, однако когда меня взяли на жирную вакансию как бы на вырост, но с конской зп, я уже две недели не могу осилить схватиться за сраный локатор.
Я тоже после этого первого собеседования уже не так боюсь идти на следующее. Стараюсь это воспринимать больше как просто разговор, а не как сдача модулей/экзаменов/защита диплома в вузике, из которого свалил полгода назад. Охуеть время быстро летит.
За спискоту спасибище, схоронил.
Только вот что есть ИС? Гугл подсказывает только интеллектуальную собственность и какие-то там танки.
>>824453
>соционяшу
Вот с этим-то и немного сложности. Я не то, чтобы необщительный, но когда начинаю слишком волноваться или когда хочу сказать какой-то термин, который до этого обдумываю в голове (т.е. как именно я это скажу), начинаю заикаться. И иногда ляпаю лишнего или чего-то реально упоротого, лол. Поэтому стараюсь помалкивать и много слушать. Включая двачи, ага.
>Думаю, стоит влиться в такие сообщества
Внезапно, у меня такой опыт уже есть. Ездил участвовать в трёхдневном конкурсе с двумя одногрупниками, нифига не шарящими в играх, запилили небольшую головоломку в ТРИДЭ от третьего лица в лоу-поли стиле, но не успели сделать уровни (большую часть уровней, если быть точным). Причём я был геймдизайнером, так что опыт управления небольшим коллективом уже есть.
Строчку про это в резюме вписал, но внизу, где у меня увлечения и интересы, хоть и выделил отдельным пунктом. Стоит поднять?
>Только вот что есть ИС?
Сорян. Испытательный срок.
>Строчку про это в резюме вписал, но внизу, где у меня увлечения и интересы, хоть и выделил отдельным пунктом. Стоит поднять?
Наверное не стоит, если не выносишь какой-нибудь блок об участии в проектах и опенсорсе отдельно. Можно писать об этом в сопроводительном письме, как аргумент о заинтересованности. И обязательно не забывать об этом рассказывать на стадии "расскажите о себе, своем профессиональном опыте и т.д."
>начинаю заикаться. И иногда ляпаю лишнего или чего-то реально упоротого, лол. Поэтому стараюсь помалкивать и много слушать. Включая двачи, ага.
С этим тоже нужно как-то жить и мириться, я тоже как аутист порой выражаюсь, что совсем не круто для QA, однако лечится дружелюбным настроем и легким юмором, это зачастую перерастало в лишний плюс, т.к. тимлид видит, что с тобой будет легко общаться, а хрюша начинает относиться более положительно
Типичный дискриминатор МУЩИНАДОЛЖЕН. Иди землю копай в -30, а не в офисе сиди, как девка, нажимая кнопочки.
Спешите видеть, шкура осознает шо она не человек.
Уж лучше чем быть тестировщицей и получать половину от зарплаты настоящего программиста.
Пидоролиберал пожаловал, небось и нянечкой бы в садик работать пошёл, выблядкам жопы вытирать?
>писать об этом в сопроводительном письме
А я как-то сопроводительное письмо игнорил. Не особо понимаю, что в нём писать-то - и так всё есть в резюме же.
Бекэнд-то твой не болит? Вротенд-то больше разработан.
Почитал протухшую пасту в лурочке, соснул хуйцов в своей говноконторе по традиции, и пришёл сюда повыёбываться. Вот лол. Вы обосрались, сэр.
>А трясся но собесе потому, что очень хотел попасть туда и боялся что-то лишнее ляпнуть (я это, увы, умею, лол). Ну и первый собес как-никак, всё ж волнительно, что-то новое в жизни.
То-то и оно.
Никогда не потей над одной вакансией. Откликайся на всё подряд вообще, и не заостряй внимания. Для меня они все на этапе поиска на одно лицо. Потом, когда уже звонят и зовут к себе, я начинаю гуглить и смотреть, что да как. Прихожу максимально расслабленным, ибо мне ещё сегодня на два собеседования ехать, допустим. То, что знаю - говорю, что не знаю - говорю сразу, что не зню, дабы хуйни не нагородить. И важно просто по-человечески с людьми разговаривать, суметь расположить к себе. Ты может быть не слишком подкован в теории, но в общение с тобой очень приятно, и в практике тебя поднатаскают к специфике - не проблема.
Статья про тестировщиков в Лурке. Про то, что тебя могут не взять из-за того, что у тебя нет сисек, и вместо тебя возьмут дуру с сиськами. Видно, что часть этой статьи написал какой-то обиженный.
Конечно, не стоит засиживаться в макаках, а стремиться быть специалистом в этой сфере, что хорошо описано в той же статье.
Устроился недавно - на днях корпоратив, коллектив дружелюбный, работа работается. :)
Я так понимаю, у тебя что-то канбаноподобное? Джира есть? Я бы попробовал следующее:
0. Что вобще нужно начальству/заказчику?
1. Четко определить состояния таска от заведения и до релиза. Например, ввести в джире статусы типа Open (тикет только завели) -> Ready for development -> In progress -> Code Review -> Ready for testing/In testing -> Staging -> Prod (тикет закрывается). Рядом с Ready for testing/In testing должна быть еще колонка Failed QA, куда должны попадать все зафейлившиеся тикеты. Каждый статус - отдельная колонка. Чем нагляднее, тем лучше.
2. Далее, для каждой фичи делается "выключатель" в коде. В базе заводится табличка, где проставляя True-False для каждой фичи, можно сконфигурить билд так, как тебе надо. Это позволит не допускать выливания недотестированных фич в продакшен. Формально, код будет залит на прод, но выключен. Поможет сэкономить овер9000 нервов. После релиза нужной фичи, выключатели удаляются из кода и базы, чтобы не усложнять код.
3. Приоритезировать все таски. В первую очередь чистить борду джиры от того, что находится в Failed QA, потом - все остальное по проставленным приоритетам.
4. Избавиться от коммитов прямо в мастер. Одна фича - один бранч. Коллективно лить в мастер не надо.
5. Из предыдущего пункта вытекает то, что нужны пулл-реквесты. Будьте мужиками, не надо мерджить все и сразу.
6. Делайте код ревью. Один девелопер сделал фичу - двое других вспоминают, как они двачевали капчу в /po и начинают обсирать его код с головы до ног до тех пор, пока не станет хорошо.
7. В любой момент времени должен быть билд, который можно зарелизить.
8. После любого мерджа с мастером должны прогоняться селениум тесты. Сколько их у тебя, какой навскидку процент покрытия?
9. Релизьте как можно чаще. В идеале - каждый день, кроме пятницы (в крайнем случае - утром пятницы, чтобы было полдня на исправление).
Видится как-то так для начала. Обсирайте, предлагайте лучшие решения. У нас на проекте как-то так все выстроено, хочется понять, нет ли тут явных косяков и что можно сделать лучше.
Я так понимаю, у тебя что-то канбаноподобное? Джира есть? Я бы попробовал следующее:
0. Что вобще нужно начальству/заказчику?
1. Четко определить состояния таска от заведения и до релиза. Например, ввести в джире статусы типа Open (тикет только завели) -> Ready for development -> In progress -> Code Review -> Ready for testing/In testing -> Staging -> Prod (тикет закрывается). Рядом с Ready for testing/In testing должна быть еще колонка Failed QA, куда должны попадать все зафейлившиеся тикеты. Каждый статус - отдельная колонка. Чем нагляднее, тем лучше.
2. Далее, для каждой фичи делается "выключатель" в коде. В базе заводится табличка, где проставляя True-False для каждой фичи, можно сконфигурить билд так, как тебе надо. Это позволит не допускать выливания недотестированных фич в продакшен. Формально, код будет залит на прод, но выключен. Поможет сэкономить овер9000 нервов. После релиза нужной фичи, выключатели удаляются из кода и базы, чтобы не усложнять код.
3. Приоритезировать все таски. В первую очередь чистить борду джиры от того, что находится в Failed QA, потом - все остальное по проставленным приоритетам.
4. Избавиться от коммитов прямо в мастер. Одна фича - один бранч. Коллективно лить в мастер не надо.
5. Из предыдущего пункта вытекает то, что нужны пулл-реквесты. Будьте мужиками, не надо мерджить все и сразу.
6. Делайте код ревью. Один девелопер сделал фичу - двое других вспоминают, как они двачевали капчу в /po и начинают обсирать его код с головы до ног до тех пор, пока не станет хорошо.
7. В любой момент времени должен быть билд, который можно зарелизить.
8. После любого мерджа с мастером должны прогоняться селениум тесты. Сколько их у тебя, какой навскидку процент покрытия?
9. Релизьте как можно чаще. В идеале - каждый день, кроме пятницы (в крайнем случае - утром пятницы, чтобы было полдня на исправление).
Видится как-то так для начала. Обсирайте, предлагайте лучшие решения. У нас на проекте как-то так все выстроено, хочется понять, нет ли тут явных косяков и что можно сделать лучше.
>Я так понимаю, у тебя что-то канбаноподобное? Джира есть? Я бы попробовал следующее
Аджайл бодишопоподобный. Жирка конечно имеется.
>Что вобще нужно начальству/заказчику?
Чтоб все было заебись. А заказчики сами не знают чего хотят - суть в том чтобы получать от максимум информации и на возражения тыкать лицом в это подобие "тз"
>1. Четко определить состояния таска от заведения и до релиза. Например, ввести в джире статусы типа Open (тикет только завели) -> Ready for development -> In progress -> Code Review -> Ready for testing/In testing -> Staging -> Prod (тикет закрывается). Рядом с Ready for testing/In testing должна быть еще колонка Failed QA, куда должны попадать все зафейлившиеся тикеты. Каждый статус - отдельная колонка. Чем нагляднее, тем лучше.
Колонка "готов к разработке" кажется лишней - все остальное так же, отсуствует только код-ревью(нихуя не делаем) и проваленный qa(кидаю задачку обратно в девелопмент). Пожалуй failed qa неплохая идея, но я в принципе пока что лично могу пнуть разраба допиливать задачку в случае бага.
>2. Далее, для каждой фичи делается "выключатель" в коде. В базе заводится табличка, где проставляя True-False для каждой фичи, можно сконфигурить билд так, как тебе надо. Это позволит не допускать выливания недотестированных фич в продакшен. Формально, код будет залит на прод, но выключен. Поможет сэкономить овер9000 нервов. После релиза нужной фичи, выключатели удаляются из кода и базы, чтобы не усложнять код.
Фича тоглинг наверное круто, когда есть изменения в бизнесс логике - у нас чаще вебморду перехуярить пару раз в нескольких местах(новые поля в модельке, пару модалок). В общем спорный вариант - интересен уже опыт применения.
>3. Приоритезировать все таски. В первую очередь чистить борду джиры от того, что находится в Failed QA, потом - все остальное по проставленным приоритетам.
И так первым делом в новом спринте разбираем баги и только потом новые фичи(так как три человека - продавить какой-то критичный баг не проблема)
>4. Избавиться от коммитов прямо в мастер. Одна фича - один бранч. Коллективно лить в мастер не надо.
>5. Из предыдущего пункта вытекает то, что нужны пулл-реквесты. Будьте мужиками, не надо мерджить все и сразу.
Я не совсем понимаю как процесс должен выглядеть, типа каждый делает фичу в своей ветке, я её проверю и что дальше?
>6. Делайте код ревью. Один девелопер сделал фичу - двое других вспоминают, как они двачевали капчу в /po и начинают обсирать его код с головы до ног до тех пор, пока не станет хорошо.
Дельно, хотелось бы услышать отзывы опять же, ибо процесс это затормозит знатно(+час к задаче как минимум).
>7. В любой момент времени должен быть билд, который можно зарелизить.
Ну вот с этим немного нихуя не выходит, есть только тестовый стенд на который периодически сливается говнецо. Как это должно выглядеть в идеале?
>8. После любого мерджа с мастером должны прогоняться селениум тесты. Сколько их у тебя, какой навскидку процент покрытия?
Штук тридца - дай бог процентов 10-20 наберется от всего функционала(но покрыт как раз критичный для ломания). Идея нормас, упирается в мое на обслугу тестов, в условиях ежедневно меняющейся морды. Хотелось бы отзывы по всяким юнит-тестам или еще какой новомодной фигне - сегодня вон видел тесты на JS был бы рад отзывам или статьям.
>9. Релизьте как можно чаще. В идеале - каждый день, кроме пятницы (в крайнем случае - утром пятницы, чтобы было полдня на исправление).
Что мы релизим-то? Условно стабильную версию?
>>839642 кун
>Я так понимаю, у тебя что-то канбаноподобное? Джира есть? Я бы попробовал следующее
Аджайл бодишопоподобный. Жирка конечно имеется.
>Что вобще нужно начальству/заказчику?
Чтоб все было заебись. А заказчики сами не знают чего хотят - суть в том чтобы получать от максимум информации и на возражения тыкать лицом в это подобие "тз"
>1. Четко определить состояния таска от заведения и до релиза. Например, ввести в джире статусы типа Open (тикет только завели) -> Ready for development -> In progress -> Code Review -> Ready for testing/In testing -> Staging -> Prod (тикет закрывается). Рядом с Ready for testing/In testing должна быть еще колонка Failed QA, куда должны попадать все зафейлившиеся тикеты. Каждый статус - отдельная колонка. Чем нагляднее, тем лучше.
Колонка "готов к разработке" кажется лишней - все остальное так же, отсуствует только код-ревью(нихуя не делаем) и проваленный qa(кидаю задачку обратно в девелопмент). Пожалуй failed qa неплохая идея, но я в принципе пока что лично могу пнуть разраба допиливать задачку в случае бага.
>2. Далее, для каждой фичи делается "выключатель" в коде. В базе заводится табличка, где проставляя True-False для каждой фичи, можно сконфигурить билд так, как тебе надо. Это позволит не допускать выливания недотестированных фич в продакшен. Формально, код будет залит на прод, но выключен. Поможет сэкономить овер9000 нервов. После релиза нужной фичи, выключатели удаляются из кода и базы, чтобы не усложнять код.
Фича тоглинг наверное круто, когда есть изменения в бизнесс логике - у нас чаще вебморду перехуярить пару раз в нескольких местах(новые поля в модельке, пару модалок). В общем спорный вариант - интересен уже опыт применения.
>3. Приоритезировать все таски. В первую очередь чистить борду джиры от того, что находится в Failed QA, потом - все остальное по проставленным приоритетам.
И так первым делом в новом спринте разбираем баги и только потом новые фичи(так как три человека - продавить какой-то критичный баг не проблема)
>4. Избавиться от коммитов прямо в мастер. Одна фича - один бранч. Коллективно лить в мастер не надо.
>5. Из предыдущего пункта вытекает то, что нужны пулл-реквесты. Будьте мужиками, не надо мерджить все и сразу.
Я не совсем понимаю как процесс должен выглядеть, типа каждый делает фичу в своей ветке, я её проверю и что дальше?
>6. Делайте код ревью. Один девелопер сделал фичу - двое других вспоминают, как они двачевали капчу в /po и начинают обсирать его код с головы до ног до тех пор, пока не станет хорошо.
Дельно, хотелось бы услышать отзывы опять же, ибо процесс это затормозит знатно(+час к задаче как минимум).
>7. В любой момент времени должен быть билд, который можно зарелизить.
Ну вот с этим немного нихуя не выходит, есть только тестовый стенд на который периодически сливается говнецо. Как это должно выглядеть в идеале?
>8. После любого мерджа с мастером должны прогоняться селениум тесты. Сколько их у тебя, какой навскидку процент покрытия?
Штук тридца - дай бог процентов 10-20 наберется от всего функционала(но покрыт как раз критичный для ломания). Идея нормас, упирается в мое на обслугу тестов, в условиях ежедневно меняющейся морды. Хотелось бы отзывы по всяким юнит-тестам или еще какой новомодной фигне - сегодня вон видел тесты на JS был бы рад отзывам или статьям.
>9. Релизьте как можно чаще. В идеале - каждый день, кроме пятницы (в крайнем случае - утром пятницы, чтобы было полдня на исправление).
Что мы релизим-то? Условно стабильную версию?
>>839642 кун
>Колонка "готов к разработке" кажется лишней
Как правило в нее переводят тикет из состояния "открыт" после того, как над ним поработает бизнес-аналитик. Когда все критерии приемки выработаны, его можно перемещать в кучу тех, над которыми можно начинать работу. Если у тебя в проекте нет в этом нужды, можно забить.
>Фича тоглинг наверное круто, когда есть изменения в бизнесс логике - у нас чаще вебморду перехуярить пару раз в нескольких местах(новые поля в модельке, пару модалок). В общем спорный вариант - интересен уже опыт применения.
Для изменений в вебморде идея тоже нормально отрабатывает. Главное, опять же, не забывать подчищать тоглы за собой.
>И так первым делом в новом спринте разбираем баги и только потом новые фичи(так как три человека - продавить какой-то критичный баг не проблема)
Гуд.
>Я не совсем понимаю как процесс должен выглядеть, типа каждый делает фичу в своей ветке, я её проверю и что дальше?
Разработчик отбранчовывается от мастера, коммитит в новую ветку изменения и когда считает, что все готово, маякует тебе и остальным девелоперам, что готов мерджить с мастером (пулл-реквест). Дальше девелоперы делают код ревью и смотрят, что их коллега написал. Если их все устраивает, то возможны два варианта:
1. Ты выкачиваешь ветку к себе и тестируешь ее ДО мерджа с мастером. Это имеет смысл довольно редко и как правило, делается потому, что после мерджа с мастером проверить уже нельзя.
Пример: мы тестировали т.н. Honeypot на формах. Суть такова: у нас на сайте есть формы, которые при заполнении отправляют письма в колл-центр. Для защиты от ботов, которые норовят скрейпить сайты и юзать формы, мы сделали финт ушами: добавили невидимое поле, которое юзер не видит, а боты заполняют. В результате, если форма содержит заполненное поле HoneyPot, то содержимое этой формы никуда не отправляется, а пишется в специальный файл на серваке, который раз в сутки отправляется по определенному почтовому адресу и удаляется с серва. Надо было потестировать эту фичу (заполнение формы, создание файла и его отправка по нужному адресу) локально у себя, чтобы быть уверенным, что после мерджа с мастером все подхватится.
2. Спокойно мерджим с мастером и тестируем уже его.
>Дельно, хотелось бы услышать отзывы опять же, ибо процесс это затормозит знатно(+час к задаче как минимум).
Лучше трата час-два на тикет, чем через полгода-год осознать, что ЭТО не поддается ревью, архитектуры нет, и приложение сыпет в логи "УБЕЙ МЕНЯ!!!111"
>Ну вот с этим немного нихуя не выходит, есть только тестовый стенд на который периодически сливается говнецо. Как это должно выглядеть в идеале?
Заведите еще одно окружение между тестов и продакшеном (типа, стейджинг), на которое можно взять и накатить любую нужную версию. Тимсити такое вполне позволяет проделывать. Это будет окружение со стабильной версией, которую можно готовить к релизу.
>Хотелось бы отзывы по всяким юнит-тестам
Юнит-тесты должны писать девелоперы. Надо их к этому приучать и настаивать на том, что без юнит-тестов таска не пройдет код-ревью. Я согласен с тем, что не все вещи надо покрывать юнит-тестами. Но хотя бы необходимый минимум был.
>Что мы релизим-то? Условно стабильную версию?
Стабильную версию, в которой есть хотя бы одна новая фича. В идеале, каждая версия содержит 3-4 новых сделанных и проверенных таска.
>>839691-кун
>Колонка "готов к разработке" кажется лишней
Как правило в нее переводят тикет из состояния "открыт" после того, как над ним поработает бизнес-аналитик. Когда все критерии приемки выработаны, его можно перемещать в кучу тех, над которыми можно начинать работу. Если у тебя в проекте нет в этом нужды, можно забить.
>Фича тоглинг наверное круто, когда есть изменения в бизнесс логике - у нас чаще вебморду перехуярить пару раз в нескольких местах(новые поля в модельке, пару модалок). В общем спорный вариант - интересен уже опыт применения.
Для изменений в вебморде идея тоже нормально отрабатывает. Главное, опять же, не забывать подчищать тоглы за собой.
>И так первым делом в новом спринте разбираем баги и только потом новые фичи(так как три человека - продавить какой-то критичный баг не проблема)
Гуд.
>Я не совсем понимаю как процесс должен выглядеть, типа каждый делает фичу в своей ветке, я её проверю и что дальше?
Разработчик отбранчовывается от мастера, коммитит в новую ветку изменения и когда считает, что все готово, маякует тебе и остальным девелоперам, что готов мерджить с мастером (пулл-реквест). Дальше девелоперы делают код ревью и смотрят, что их коллега написал. Если их все устраивает, то возможны два варианта:
1. Ты выкачиваешь ветку к себе и тестируешь ее ДО мерджа с мастером. Это имеет смысл довольно редко и как правило, делается потому, что после мерджа с мастером проверить уже нельзя.
Пример: мы тестировали т.н. Honeypot на формах. Суть такова: у нас на сайте есть формы, которые при заполнении отправляют письма в колл-центр. Для защиты от ботов, которые норовят скрейпить сайты и юзать формы, мы сделали финт ушами: добавили невидимое поле, которое юзер не видит, а боты заполняют. В результате, если форма содержит заполненное поле HoneyPot, то содержимое этой формы никуда не отправляется, а пишется в специальный файл на серваке, который раз в сутки отправляется по определенному почтовому адресу и удаляется с серва. Надо было потестировать эту фичу (заполнение формы, создание файла и его отправка по нужному адресу) локально у себя, чтобы быть уверенным, что после мерджа с мастером все подхватится.
2. Спокойно мерджим с мастером и тестируем уже его.
>Дельно, хотелось бы услышать отзывы опять же, ибо процесс это затормозит знатно(+час к задаче как минимум).
Лучше трата час-два на тикет, чем через полгода-год осознать, что ЭТО не поддается ревью, архитектуры нет, и приложение сыпет в логи "УБЕЙ МЕНЯ!!!111"
>Ну вот с этим немного нихуя не выходит, есть только тестовый стенд на который периодически сливается говнецо. Как это должно выглядеть в идеале?
Заведите еще одно окружение между тестов и продакшеном (типа, стейджинг), на которое можно взять и накатить любую нужную версию. Тимсити такое вполне позволяет проделывать. Это будет окружение со стабильной версией, которую можно готовить к релизу.
>Хотелось бы отзывы по всяким юнит-тестам
Юнит-тесты должны писать девелоперы. Надо их к этому приучать и настаивать на том, что без юнит-тестов таска не пройдет код-ревью. Я согласен с тем, что не все вещи надо покрывать юнит-тестами. Но хотя бы необходимый минимум был.
>Что мы релизим-то? Условно стабильную версию?
Стабильную версию, в которой есть хотя бы одна новая фича. В идеале, каждая версия содержит 3-4 новых сделанных и проверенных таска.
>>839691-кун
> если все эти тесты пишутся считай отдельным программистом?
Есть юнит-тесты. Это такие низкоуровневые тесты, которые проверяют, что отдельные методы работают так, как надо. Их пишут программисты.
Есть интеграционные тесты. Это уже тесты, которые пишут автотестеры. Сейчас модно писать на селениуме, потому что альтернативы нет.
>Я понял что есть Selenium у него какая-то IDE?
IDE есть, но она довольно примитивная. Если нужны нормальные тесты, иди на офсайт http://www.seleniumhq.org/download/ и качай байндинги для нужного тебе ЯПа (ява в твоем случае)
>Что должен делать селениум - пишется на питоне?
Переформулируй, плз. Слабо понятно вобще.
>Про типы тестирования дофига умных слов, какие тесты юзаются чаще всего?
Зависит от задач. Спец по тестированию безопасности врядли будет тестировать функционал на предмет соответствия функциональным требованиям.
>Например изучая яву, я переодически впихиваю всякого рода println в промежуточные методы, чтобы поглядеть где что-то не так. Это своего рода junit?
Это своего рода дебаг на коленке. Учись работать с дебаггером в IDE.
JUnit - это явовский фреймворк для юнит-тестов. У дотнетчиков он называется NUnit. Их предназначение - дать кодеру/тестеру возможность писать юнит-тесты и авто-тесты.
>какими прогами/фреймворками тестятся?
В C# после сборки проекта создается dll-ка, содержащая все тесты. Специально обученный Nunit-runner берет эту dll-ку, расковыривает ее, детектит тесты и начинает их запускать. Сильно подозреваю, что у явы примерно так же (очень мало с ней работал, и давно). Пусть ява-господа этого треда расскажут.
>Нужный годный roadmap для переезда в QA.
Хотя бы попсовую "Тестирование дот ком" Савина прочти. Ее рекомендуют, наверное, всем желающим вкатиться. Не вопрос, она очень легко читается. Надо только после нее не останавливаться, а понять, что тебе дальше надо и читать сответствующие книжки/статьи/форумы
Спасибо. Автотесты и юнит тесты представляются как позапихивать все возможные варианты данных в метод. Байндинги это наверно то что я имел ввиду под "то что должен делать селинум", типа скрипты. dll создается отдельная с тестами? Которые предварительно понаписал разработчик программы пока писал программу? Спасибо за инфу!
>Автотесты и юнит тесты представляются как позапихивать все возможные варианты данных в метод.
Для юнит-тестов это справедливо, потому что они как правило, прогоняются очень быстро. С автотестами на селениуме (которые предназначен для имитации действий пользователя) все в разы хуже, потому что тесты могут прогоняться очень медленно (допустим, секунд 40 на каждый тест с одним набором данных). Запихивать в него все возможные комбинации входных данных, нет смысла, потому что времени всегда не хватает.
>Байндинги это наверно то что я имел ввиду под "то что должен делать селинум", типа скрипты.
Строго говоря, селениум - это прослойка между кодом и браузером. JUnit/NUnit запускает тесты, стартует браузер, который ты указал для запуска, селениум при запуске устанавливает в него плагин под названием WebDriver, который дергает api самого браузера, делая те действия, которые ты в тесте задал.
>dll создается отдельная с тестами?
Зависит от организации кода в проекте. Можно сделать один солюшен с несколькими проектами: код основного проекта, юнит-тесты и селениум-тесты. При билде появятся отдельные dll-ки под каждый проект. Если все проекты слепить в один, то будет одна dll-ка.
Да это в целом хуйня полная, которая сводится к тому, что надо изучать sql, субд, xml, использовать различные инструменты типо SoapUI, работать с менеджерами очередей (на многих крупных проектах используется), уметь писать тесты, разбивать их в различные наборы по функционалу/предусловиям, знать как работают веб- сервисы, клиент-серверные приложения, основные виды ошибок, какие видишь в браузере (500, 404 и т.д.)выучить основы программирования, представлять как работает код, тупо хотя бы понимать какие бывают типы данных и какое влияние/ограничение оказывает - я бы назвал это просто хорошим кругозором в IT. Ну и немаловажный фактор- коммуникативность, общение: конференции, собрания, переговоры с админами, аналитиками, различные согласования тестов и тестовых данных, обзор и обсуждение документации- надо уметь задавать вопросы, не молчать, иметь своё аргументированное мнение и готовность его отстаивать.
Ну и по времени- очень странно, если тестер с 1-2 годами опыта этого всего не умеет. Я вообще считаю, что после примерно 2 лет в мануальщине остаются сидеть только семьянины, которых все устраивает, люди без амбиций и девочки.
Чет странно, что в основном после мержа тестите, хотфиксить не заебывает потом мастер? + это же потенциальные блокеры для других связанных веток.
Да не особо. После мерджа тестим потому, что если дойдет до релиза, то дойдет именно мастер. Как правило, один девелопер работает над одной таской в одном бранче. Нам нужно, чтобы фичи между собой нормально уживались, и не было такого, что мы вроде и проверили каждый бранч по-отдельности, убедились, что все ок, потом смерджили все с мастером и выяснилось, что фичи между собой как-то конфликтуют при взаимодействии. Иногда случаются конфликты мерджа, это да. В таком случае девелоперы сами между собой разбираются и мерджат руками.
Ну а хули ты хотел? Знание ПК и MS Ofice? Ищи без опыта, иногда можно найти, только там зп как у кассира в Пятерочке.
Ну так домохозяйки вкатываются как правило в джуниоры. Сеньором на диване не станешь.
на первой же странице hh нашел две вакансии без опыта, где ты там мониторишь я хз
Ну он наверное поставил галочку "скрыть без указания зарплаты", либо в ожидаемой зарплате написал неадекватную сумму.
>Иногда случаются конфликты мерджа, это да
>В таком случае девелоперы сами между собой разбираются и мерджат руками
А ничего, что в таком случае имеется нихуёвая вероятность ретестить заново ветку с изменениями, если конфликт был серьезный? Если вы там не калькулятор на троих соображаете конечно, странная у вас практика, тесты отдельных бранчей с мержем в текущий мастер - единственно логичное, что я видел и избавляет от горы проблем.
>А ничего, что в таком случае имеется нихуёвая вероятность ретестить заново ветку с изменениями, если конфликт был серьезный?
Да, в таких случаях надо перетестить, базара нет. Но такое случается достаточно редко, потому что проект здоровый, и девелоперы достаточно редко правят одни и те же файлы параллельно.
Ну я к тому, что изменив порядок тестирования вы нихрена не потеряете в скорости и только приобритете избавление от потенциальных проблем, поэтому меня и удивил подход.
А если из практики, то насколько часто всплывают эти потенциальные проблемы, сколько времени занимает их решение и не быстрее было бы решить все фиксом мастера с последующей перепроверкой? Интересует именно сравнение двух подходов с точки зрения затрат времени и сил.
Вполне всплывает на крупных проектах, если ещё и сильно законфликтовали( это вполне себе реальность на стартанувших\с хуевым тимлидством\общением внутри команды проектах), то команда вполне может проебать дохуя времени, ожидая пока пофиксят мастер. Встанет и тестирование и частично разработка если параллельно ветвились от мастера со смерженным багом. По времени разница будет минимальна для обоих подходов. Самая большая проблема в данном случае - если нужно разрабатывать какую-то фичу, зависящую от ветки, которую нужно смержить. Но это вопрос к планированию разработки, таких ситуаций при правильной организации рабочего процесса команды не должно быть в принципе. Бывало и на день и на два вставал мастер из-за того, что смержили и не нашли сразу баг.
>если нужно разрабатывать какую-то фичу, зависящую от ветки, которую нужно смержить
+ а она на тестировании
Благодарствую за идеи. Подумаю над внедрением у себя в проекте. Может и удастся что сделать после праздников. Правда, придется остальных троих тестировщиков включая куа-лида индуса, лол научить пользоваться гитом, рассказать про бранчи и т.д. Но это дело на две-три ссаные тряпки.
зп довольно сильно различается от города, судя по твоим 40 ты видимо в дс2, если так то все верно - первый год будешь джуном за 25-30. скилы программирования очень хорошо, sql до уровня простых запросов догнать можно за неделю, гайд в оп-треде. если постоянно изучать выбранное дело через год догонишь зп до уровня 50-60, дальше зависит от тебя. а насчет стоит-не стоит себя и слушай, если с усидчивостью и концентрацией внимания проблемы будет плохо и дропнешь.
Для начала перейти от тестирования к QA.
ананасы, есть у кого ответы на listboxer?
Так же, как и карандаш.
>>846725
Я тебе дам ответы, иди сам пиши, нехер на курсы ходить, если тут ответы ищешь. Тем более если это не курсовое, а вступительное задание.
я сделал около 32 багов нашел. интересно, правильно или нет.
разделяются ли баги, например у меня есть баги с вводом символов. я написал их в один. мб они разделены должны быть? много вопросов впервые этим занимаюсь
В лист через функцию "Вставить" можно добавлять знаки !"№;%:?*
Вот например. Это один баг? или несколько?
Один, в нем стоит описать требование, согласно которым вставлять спецсимволы нельзя и либо перечислить их все(плохая идея) либо что-то вроде "с помощью буфера обмена можно вставлять спецсимволы". А на вопрос "один это баг или несколько" ответ довольно прост. Природа "Багов" одна? Зачем тогда делать их >1?
Просто кокококо гугл говорит чтоу листбоксера допизды багов. и я думал, мб они в этом нашли.
А так я мимокрокодил. хочу вкатиться в qa. думал ответы помогут мне далее рассмотреть курс моего движения
Не нужно плодить сущности и делать из 1 бага о вводе спецсимволов 150 багов на каждый спецсимвол, за такое точно не похвалят.
Вот хорошее тестовое задание мне давали, например.
В интернетах ответы есть, но смысл обманывать самого себя, правда же? Попробуйте найти 18 из 18. Можно обмениваться скринами, например.
Нормально, жить можно, но уже пованивает говнецом.
Помню на работе кидали, нашел 16 из 18, остальные никак поначалу, написал автору теста, он кинул подсказки - нашел 2 оставшихся. Не скажу, что хорошее задание, блин и не проспойлерить не получится если начать обсуждать в чем недостатки, но скажем так, один метод(место) где нужно искать около 6 вещей вообще нихуя не очевидно из описания задания.
Конечно пиши, лишним не будет. Только жди доп. вопросов в таком случае.
>>848646
За конкретно ДС2 не поясню, но если у тебя там клубок то иди на любые БЕСПЛАТНЫЕ курсы более-менее топовых контор, уж в питере их море. "Ставишь джиру и т.д." это все хуйня, тебе нужно понять концепцию тестирования, инструменты под проект учатся за 1-3 часа.
Беглое гугление показало, что в вакансиях у варгейминга особняком стоит требование "интересоваться военной техникой". Поклей танчики там, самолетики, кораблики, почитай профильные форумы, немного истории. Даже если не возьмут в варгейминг, кругозор расширишь.
Я сомневаюсь, что даже исключительное знание военки тебе что-то даст при 0 познаниях в тестировании, так, небольшой +, это же не исторического консультанта вакансия. Когда "работал" у них на супертесте - гораздо важнее было знать азы тестирования, багртрекеры и все такое.
Я знаю азы. Проходил курсы при крупной конторе, топ-2 в городе. Но не прошёл туда на работу, т.к. зафейлил при окончании немного и тестировал на отъебись
Ну, если тебе с ноября задерживают ЗП, то по ТК ты вообще можешь не выходить работать и ждать, пока тебе заплатят. Намекни, что ты прогуляешься в трудовую инспекцию и поделишься своими переживаниями с ними. Авось, чего и уладят.
Набивай опыт и молча уходи, ищи куда уже сейчас. Кризис нормальные ИТ конторы только укрепил, т.к. у большинства из них в рашке клиенты баксовые, а рабы рублевые.
Курсы вообще ничего не значат вот так вот сами по себе, крупной хуюпной. Один епам чего стоит со своими скоморохскими курсами.
Это хреновый совет, нужно молча уходить, пусть ебуться сами как хотят, разводить конфликт на ровном месте глупо. Я не говорю, не брать зарплаты, но грозить трудовой нафиг не нужно - себе больше головной боли будет.
Ну так уходи молча, без зарплаты. Кто мешает?
Каждый сам кузнец своего счастья - пошёл работать по черной или дай Бог в серую, то потом не жалуйся на произвол.
Устроился по-белому - имеешь право качать права при невыполнении каких-либо обязанностей, но как правило у таких контор всё хорошо.
Все просто - на белых работах выполнялись все обязательства, увольнялся по собственному, со всеми вытекающими выплатами.
В серой конторе тоже не было проблем с зарплатой, разве что задержки на несколько дней бывали. Так же выплатили все, когда увольнялся.
Потому что есть наверное понимание того, в каких конторах тебя кинут, а в каких нет. Отзывы о компании иногда не мешает читать.
Ну и что теперь делать тогда? Джаву учить чтоль? Курсы прошёл, пару учебных хуетеней сделал, форум тестинга перелопатил, книги из шапки почитал. Хуй знает, что тогда. Пойду в танки чтоль бои ботом набивать, а то там акк не менее, чем с 7к боями нужен.
>>852631
Я не так выразилась. Я работаю всего лишь около двух недель, согласилась на эту контору так как долго была без работы. А зп задерживают ребятам, которые там работают( и это у них норм практика. Я скорее всего поработаю тут для реального опыта пока другую работу не найду...
Время больше всего жалко!
>Пойду в танки чтоль бои ботом набивать, а то там акк не менее, чем с 7к боями нужен.
Лучше в доту, сразу в valve возьмут, ага.
Мой тебе совет: если видишь, что работодатель - чмо, то лучше уйти незамедлительно. В своей жизни я кучу раз просто вставал и уходил, ибо уважал себя, наверное.
А сидеть в такой конторе ради опыта - тоже так себе занятие. За это время можно нехило так перегореть в этой сфере - это же ОЙТИ! Тут зачастую же условия труда должны быть чуть выше среднего. Уважай себя, короче, и ищи параллельно новую работку, и там объяснишь, почему ты решила оттуда уйти.
>Это требование, прописанное в вакансии.
Ага, как и фулстек программинг, знание всех CI, великолепное понимание всяких теорий графов и т.д. Не знать в 2017, что вакансию пишут из ожиданий соответствия кандидата хотя бы 50% её содержимого - это да.
Постой. Ты не откликнулся на вакансию, дорожишь ей, пытаясь набить скилл под компанию?
Просто я не знаю, как ответить, если меня спросят что-то вроде "Хм, вы претендуете на должность тестировщика игры, в которую сами даже не играете?"
>>854506
Я откликнулся, но тогда они набрали людей. Сейчас перезвонили и предложили прислать резюме. А у меня его и нет.
Нормальная тема. Я XMind'ом обмазываюсь, например.
>"Хм, вы претендуете на должность тестировщика игры, в которую сами даже не играете?"
>Сейчас перезвонили и предложили прислать резюме. А у меня его и нет.
Это бамп зеленотой что ли, я не понимаю.
Ни разу. Я отправил отклик, указав, что у меня окончены курсы. Тогда набор закончился, обещали перезвонить. Перезвонили через два месяца и спросили, интересует ли меня вакансия и если да, то мне нужно выслать резюме. Всё.
Странные курсы какие-то у тебя. На моих курсах было отдельное занятие по составлению резюме и пути развития в этой сфере. Покури гугл - есть достойные ссылки на составление резюме тестировщика.
Если ты за теорией, то можно просто литературой обмазываться на самом-то деле.
>Напиши автотест со входом во ВКонтакте. Залогинься - выйди с неё - снова залогинься ( верстка поменяется), введя неправильный логин или пароль - введи корректный логин и пароль. Тебе пока что хватит этого.
насколько сложно это сделать на питоне?
это норм задача на собеседованиях мидл авматора? Буду спрашивать
Ну не особо сложно на самом деле. У меня с этого вкатывание в автоматизацию началось, но для мидла - слабоватое задание.
В принципе можно написать громоздкий но работающий код, но можно обернуть в Page Object, и код будет выглядеть элегантней.
Гугли, кури сайт селениум (есть на русском языке) и действуй. Ничего сложного в этом нет.
>насколько сложно это сделать на питоне?
Несложно. За вечер можно сделать.
>это норм задача на собеседованиях мидл авматора? Буду спрашивать
Норм. Достаточно просто выглядит (обманчивое впечатление для слабого кандидата) и довольно много спросить можно по тому, что кандидат напишет.
Лучше давай такие задания, где нужно циклы задействовать в коде.
Было такое задание на курсах: Зайти на страницу, в которой таблица из списков стран. В таблице был столбец, который отображал число штатов, т.е. только у США и Канады были эти штаты, у остальных = 0.
Задание заключалось в том, во-первых проверить, что список стран по алфавиту расположен (считай ещё узнаешь, как кандидат со списками умеет работать), во вторых кликнуть по стране, у которой штатов больше, чем ноль, в-третьих посмотреть, что список штаток тоже в алфавитном порядке.
Очень много выебал мозгов с этим заданием, но зато после его выполнения, какое-то прям облегчение и чувство собственного достоинства повысилось (не путать с ЧСВ).
Все курсы - это развод для долбоебов, книжки читай лучше.
Для мидла слабовато будет, я такое на курсах давал людям впервые вкатывающимся и в QA как профессию, а не просто в автоматизацию. Процент выполнения нормальный был.
А то начал недавно интересоваться QA, но в вакансиях почти исключительно один веб. А хочется тестить что-то десктопное (в идеале - игры), или хотя бы на мобилках.
Есть, конечно. Гугли встроенные системы и все, что с ними связано. ZigBee, умные дома и т.д. Там как правило, нужно тестировать кучу всего на реальных устройствах. Довольно узкая специализация, по крайней мере в нашем мухосранске-миллионнике. Как правило, это аутсорс. Насчет умений не подскажу, ибо не пошел туда из-за собственного слабоумия в области микроконтроллеров и всего, что с ними связано.
Тебе в аутсорс компании крупные, в них как правило много проектов и какие-нибудь и будут десктоп.
Могу писать тест-кейсы, работать в баг-трекере, могу протестировать сраный карандаш и прочую хуиту.
Из требований:
- ответственность
- готовность изучать C# (именно, что готовность, у меня вообще ноль опыта в нём)
- желание развиваться в области тестирования
Завтра иду на собеседование сюда - не хочу обосраться. Компания изготавливает умные кассы и кассовое ПО, какие вопросы и тесты могут быть на собеседовании, к чему подготовиться? Что могут попросить протестировать?
Лол, работал в подобной огранизации онлайн-кассы. Писал документацию там (тест-кейсы). Если такое, то придется много считать, проверять корректность работы всяких тех.карт, учета остатков товара на складе и корректности учёта скидок.
Посмотри, чем фискальные регистраторы отличаются от принтеров чеков, например, что такое ЕГАИС.
Но, как я понял, будешь макакой обычной, которая кнопки нажимает и тестирует функционал.
Очевидно изучить предметную область. Вообще я бы не шел в фирмы у которых единственный профильный продукт, по мне это дико уныло, я не представляю, как люди сидят на одном проекте дольше 2 лет.
Или с таким резюме учить не будут и сразу нахуй пошлют?
учить тебя в любом случае никто не будет, либо ты сам учишся и вкатываешся либо идешь нахуй чеканя шаг, собственно как и в любой другой сфере.
>учить не будут и сразу нахуй пошлют?
А может тебя ещё должны научить зарабатывать 300к/сек?
Учи самостоятельно теорию. Чем больше знаешь, тем больше вероятность вкатиться. Теория тестирования не слишком уж и сложная - всё достаточно ясно и понятно. Пробуй в автоматизацию, и вообще стремись к пополнению IT-бэкграунда - лишним не будет.
Никто тебе пищу в открытый клюв не положит, короче.
По-моему хуйня какая-то или контора сама по себе стремноватая плюс написана статья с явной предвзятостью со стороны разработчика.
Со стороны тестера можно такую же статью накалякать о том, что ты сообщаешь круглое лучше катить, а не подымать и нести, но разработчик говорит, что это такая фича, ты хуй и говно, - ничего не понимаешь.
Правда не понимаю, хотя зачастую кто-то из прошлых коллег пишет что у него есть чувак который хочет вкатиться на макаку за еду, опыта нет, зато прошел 5 уровней джавараш или еще чего.
Чем тут хвалиться, лол?
Каждый выбирает сам, как и что делать ему. Если хочешь просто мануалить - пожалуйста. Кому-то этого мало, тот и вкатывается в автоматизацию, применяя выученный синтаксис языка, который он изучал. Просто знания синтаксиса особо ничего не дают мануальщику - это да.
Лично я учил синтаксис разных языков, но забрасывал потом, т.к. не знал, как и где мне их применить. Через автоматизацию я понял, что код может делать всякие прикольные вещи - это и подзатянуло, в принципе.
Потому что мануальное тестирование через некоторое время может остоебенить и захочется уйти например в автоматизацию. Лучше уже что-то уметь в программировании, чем вкатываться абсолютно с нуля.
Зачем уходить в автоматизацию ? Это же кардинально иная профа, которая намного ближе к девелоперам, чем к собственно QA.
лучше в тест-лиды расти, в менеджеры и тд
Стартапы - впизду и нахуй сразу.
Я работал в 1-в-1 такой-же конторе, только называлась не "Меркато", а "КвикРесто" - и это днищще по всем фронтам.
Самое лучшее для тестировщика-ньюфага это вкатиться в интерпрайз какойнибудь, где работа нормально отлажена за 15 лет до твоего рождения еще.
>менеджеры и тд.
Почему-то у очень многих людей единственный карьерный путь в фантазиях выглядит как "джуниор-миддл-сеньор-лид-менеджер". Менеджер и руководство людьми - это вобще другой род деятельности, нежели "работа в поле". Человек может быть хорошим работником, но хуевым организатором. Все тогда, карьерный рост ему противопоказан?
Я тебе рекомендую не обчитываться теорией, а пойти и хотябы года 2-3 поработать. Тогда, возможно, ты и поймешь, что
а) QC-QA не имеет разницы по факту, это как различать современного админа с девопсом.
б) мануальное тестирование, автоматизация тестирования и нагрузочное тестирование - 3 слабо пересекающиеся между собой отрасли. И если хочется одного - то и учи его, а на другое забей хуй.
мимо QA лид небольшой команды
>Человек может быть хорошим работником, но хуевым организатором. Все тогда, карьерный рост ему противопоказан?
Именно так. Если ты не знаменитость мирового уровня и пишешь книги / выступаешь на конференциях, конечно.
"Горизонтальный рост" - наебалово
Ключевая фраза у тебя "небольшая команда".
У нас, например, девочка-лид, которая и в автотесты может, а может и руками потестить. Сейчас частично фронтендом занимается. Вот это я понимаю - лид. А мануальщик, поработавший два года, и пересидевший других мануальщиков - так себе лид, если честно.
>>если меня спросят что-то вроде "Хм, вы претендуете на должность тестировщика игры, в которую сами даже не играете?"
Проиграл.
Пойми, ваша мелкоконтора - ваша проблема. Когда один человек и шнец и жрец и хуе игрец - это НЕ является НОРМОЙ от слова совсем.
>QA лид небольшой команды
>ваша мелкоконтора - ваша проблема.
Кого ты там лидишь, маня? Левую или правую?
Что-то такое слышал, да. Говорят, что тестировщиков там от 0 до 2 единиц.
Ну, ты очень проницателен, кьюалид - ничего не скажешь.
Наш QA-Lead постепенно уходит в разрабы, не бросая резко свои обязанности, только и всего, а управлять макаками, будучи такой же макакой, но более старожильной, без профессионального роста - это профессионально, ага.
3 месяца уже спамлю резюме безуспешно, ответили только пару контор, и те позорно слились: до сих пор выставляют всё те же вакансии, как выставляли их и три месяца назад, 0 фидбека на тестовые задания (а я время на них тратил, однако, и не пол часа).
А тут внезапно фортануло: позвонили вчера, позвали на сегодня. Сходил, пообщался с тремя симпатичными девочками :3 Хорошая галера, годная: и сиденья удобные, и вёсла приятные на ощупь, и обед включен в 8часовой рабочий день (первый раз такое вообще вижу).
Теперь ждать блин две недели, я второй человек, которого они прособеседовали, небось, вагон желающих ещё, а у меня чёт не шибко густо с вариантами. Сейчас буду прозванивать конторы, куда на этой неделе отправлял резюме: сюда меня позвали после телефонного звонка, а не после безликого мыла с резюмешкой.
Такие дела. Вилку заломил 300-600, потому что пиздец хочу вкатиться обратно и готов работать за еду; на предыдущем месте 600 и получал — но я там главный петух на проекте на 4 ебала был Харьков
Да ладно, он просто долбоёб, которому попалась плохая контора, и где один человек на все руки мастер. Таких контор большинство, вообще мало где поставлен грамотный QA процесс, а если ты не visionary и не имеешь уже опыта нормального QA, то, разумеется, выполняя QC в должности QA Lead ты будешь считать что QC=QA.
> 300-600
Хренасе у тебя "заломил". Для 2 лет реального опыта на коммерческих проектов это дно, если конечно не мартышкой идешь.
Я просто не представляю, как человек имеющий реальную экспертизу в QA, может кукарекать, что для обеспечения хотя бы большинства нормальных QC активностей может хватить 1 человека на проект, чей уровень выше тетриса. Если этот человек будет активно заниматься и QA - ему не то что на автоматизацию, на тестирование 100% не хватит времени.
Опыта год.
Я знаю, что даже 600 долларов — низковато, но я очень хочу вкатиться обратно в индустрию и набить ещё пару лет опыта, прежде чем запрашивать верхнюю планку по рынку.
Алсо, медианная с годом опыта в городе — 500
Да ты больше смотри на кассиров, если свой уровень по их оцениваешь. Хотя если важно именно вкатиться - то ок.
Няша, нутыпонел. Я знаю, что дёшево, но я ОЧЕНЬ хочу обратно, всё остальное — говно.
Если б при среднерыночной 500-600 за джуна ко мне бы пришел чувак, умоляющий взять его за 300, я б заподозрил, что он ебанутый. А ебанутые нам не нужны. Хотя я сам, когда приходил в первую свою контору, не знал, какая там зарплата вобще. Когда эйчар на беседе сказала, что зарплата у меня как у джуниора будет 600 баксов, я подохуел, потому что на даже на тот момент (4 года назад) это было лишь немногим меньше того, сколько мои родители получали, проработав преподавателями по 20+ лет.
Не знаю, чем хвалиться, потому и спрашиваю. Просто это же абсурд, когда к тебе на собеседование приводят вчерашнего студента или дворника 40 лет, который еле вспоминает что такое тест-кейс по книжке из 15 страниц, зато в ответе на каждый вопрос пытается вклинить то, что он что-то там пытался программировать. Но по факту программирование это на уровне "прочел пару глав какого-нибудь Шилдта или Рихтера, могу с гуглом написать цикл for а про классы и объекты еще не читал" и на вопрос как это относится к вакансии как-то совсем не находятся адекватные ответы. Вообще я по автоматизации изначально, но сейчас компании потребовались в штат макаки и они отвлекают людей которые хоть примерно представляют что спросить у тестировщика, а у меня уже волосы дыбом.
Если изначально в автоматизацию вкатываться, может пригодиться, разумеется, но не нужно ведь тогда занимать место мануальщика и тратить свое время, для автоджунов без опыта тоже вакансий полно
>>863078
Ну так вопрос в том, зачем специально все задрачивают программирование, пробуясь на начальные вакансии для "ручников" Лучше бы SQL осваивали, сейчас люди, которые умеют что-то помимо простого селекта и джойна двух таблиц на вес золота. И английский.
Хотя я тут подумал и понял, что это те самые ребята, которые хотели бы в погромирование вкатиться, но обучение не осилили и решили пока так перекантоваться.
Во, SQL + English в этом году хочу освоить - лишним не будет.
В моём резюме написано, что могу и руками поработать, могу и в автоматизацию, вот вам мой гитхаб с проектами - это вполне устраивало работодателей. Но я до сих пор не считаю, что владею языком на должном уровне.
Гитхаб это уже показатель заинтересованности в сфере и иллюстрация способностей, а не абстрактное "умею учу зачем не знаю"
Честно говоря, сам с таким сталкивался. Учил ЯП, а зачем - хуй знает. Когда ставишь задачи себе ЗАЧЕМ, то и осваивание предмета намного лучше происходит. Я вот тут недавно фотошоп скачал с четкой целью сделать афишу с уже сформированной идеей, как это сделать. В итоге, с помощью ютабчика и гугла вышла очень даже не дурная афишка - народ оценил.
>все
Кто "все"? На собеседованиях на мануальщиков дай бог 1 попадался на десяток с хотя бы не забытыми институтскими знаниями на уровне "как сделать условие, что переменная меньше 10". Может у вас описание вакансии такое ебанутое, что "все" почему-то решают что вы их ждете с навыками программирования?
У меня просто критерии качества низкие для этого треда, да для любого треда.
Ты несколько преувеличиваешь. 300 мною был назван как абсолютный минимум, за меньшую сумму я просто не буду работать, 600 — комфортную для меня на данном этапе.
Вангую, если получу оффер от них — те же медианные 500 баксов и выйдут, а, как уже было сказано, галерка мне очень понравилась, с душой™.
Ну, предполагается что человек уже немного знает про tcp и http/smtp whatever. Либо знает что-то по предметной области. Ну и мануальное тестирование в 90% случаев реально очень уныло, надо уметь что-то еще.
Мимо нагрузочник, но приходилось немного заниматься мануальным т.к. макаки-аутсорсеры ничего не успевали и не могли простейшие вещи типа снять tcpdump и посмотреть в логи.
>вкатиться в интерпрайз какойнибудь, где работа нормально отлажена за 15 лет до твоего рождения еще.
Такие-то фантазии. Эх, анон, у меня один коллега ушел в крупный российский интегратор, и рассказывает иногда, что у них там происходит - волосы дыбом встают. А уж они с таким ынтырпрайзом работают - дальше некуда.
>Наш QA-Lead постепенно уходит в разрабы
>Наш главный дизайер постепенно уходит в сантехники
Повторяю - это РАЗНЫЕ сука профессии
Я о том и говорю, что не надо путать мануальное тестирование с автоматизированным - это разные профы. Одно НЕ является продолжением другого
Просто я работал сначала в стартапе, а потом в интерпрайзе. Небо и земля просто
А что тут тестировать? Наличие страницы типа "логин" после выхода, и страницы с ошибкой после неправильного логина?
Или ты предлагаешь просто закодить эту последовательность действий?
По тому, как это реализует кандидат, можно уже сказать, какой у него уровень. Но опять же, задание может выглядеть просто, для того, кто не сталкивался с такими задачами в реальности. Человек с опытом расспросит интервьюера про требования к тестам, и я уверен, уже тут могут всплыть дополнительные требования вроде снятия скриншотов при фейле теста, ведение лога со всеми действиями, реализация Page Object'а, написание синглтона для вебдрайвера, возможность параллельного запуска, интеграция с каким-нибудь TestRail или еще какой системой. Я бы первым делом спросил конкретные требования по реализации у того, кто дает задание. Если он говорит, что ничего этого не надо, то базара ноль, стандартный Page Object и несколько тестов можно сделать за пару часов. Если говорит "на твое усмотрение" или ничего не говорит, то делал бы по максимуму из того, что выше описывал.
другой анон
И какую реализацию page object'a ты хотел бы видеть? В деталях, в разумных пределах.
Все зависит от требований. Нет универсального решения на все случаи жизни, но по моему мнению и не самому большому опыту работы, общий костяк всего page object'а делается следующим образом:
1. Для каждой страницы приложения заводится отдельный класс, в котором прописаны локаторы для вебэлементов и методы по работе с ними. Названия элементов должны быть говорящими и отображать то, чем они являются. Локаторы, по которым ищутся элементы, не должны искать их, опираясь на какой-либо отображаемый текст. Айдишник, название класса, какие-то уникальные для элемента аттрибуты - да. Но не текст.
2. Тесты тоже разбиваются на классы по отдельным страницам. Если тест затрагивает несколько страниц, то было бы логично писать его в классе той страницы, где он начинается. Сами тесты должны быть атомарными и не зависеть друг от друга. Один тест - одна проверка. Проверки делаются через Assert'ы.
3. Навигация между страницами тоже должна быть продумана. Хорошо бы завести отдельный класс типа WebsiteNavigator, в котором прописаны методы для перехода между страницами и заданы относительные урлы для разных секций сайта, типа "/about-us", "/faq", "/menu" и т.д. Тогда при навигации по страницам в тесте можно дергать методы сайт навигатора, вместо жесткого хардкода урлов в самих тестах. Опять же, жесткий хардкод можно заменить чтением из конфига (см. п.7), но как правило, навигация по веб-приложению меняется не очень часто, поэтому ничего критичного в том, чтобы захардкодить пути нету.
4. Страницы инициализируются с помощью Page Factory. Впринципе, не сильно обязательно, но можно и так.
5. Запуск вебдрайвера. При запуске название браузера, его версия и настройки (для прокси, например), должны быть считаны из конфига (если предполагается прогонять тесты удаленно, на каком-нибудь BrowserStack или Souce Labs, то дополнительно нужно указывать еще ряд параметров). Вебдрайвер не должен быть статичным. Написать синглтон - дело полезное, потому что это нужно для запуска тестов в параллель.
6. Урл(ы), на которых гоняются тесты, также должны быть прописаны в конфиге и вытаскиваться из него кодом при запуске тестов.
7. Общие методы, не относящиеся непосредственно к тестам (скажем так, вспомогательные методы, вроде SelectRandomElementFromList(IWebElement webelementList), которые могут использоваться больше, чем в одном тесте) выносятся в отдельный класс типа Helpers или Utils. Использование Actions, ExpectedConditions, JavaScriptExecutor, понимание отличий между явными/неявными ожиданиями - только плюс.
8. Написание своих методов для вебэлементов (Extentions), для расширения возможностей вебэлементов, кастомные проверки (вроде собственного метода Displayed, который не выкидывает исключение, если элемент не найден, а возвращает человеческое False).
9. Если в тестах используются какие-то данные (заполнение форм, например, логин, регистрация и т.д.), то надо завести отдельный класс, объект которого будет иметь поля с данными для теста. В идеале было бы использовать внешний источник данных для тестов: CSV-файл с наборами валидных и невалидных данных для кредов, JSON, .xlsx табличка, и т.д. В крайнем случае можно захардкодить данные в код модели, чтобы при создании объекта класса его поля инициализировались одними и теми же значениями.
10. Хотелось бы видеть использование аннотаций из фреймворка для тестов, будь то NUnit, TestNG, или еще что. Из основных: OneTimeSetUp, OneTimeTearDown, Test, TestCaseSource, TestCase, Category. Опционально - разделение тестов по категориям. Удобно тем, что при запуске можно указывать, какие именно категории тестов запускать.
11. Ведение логов и отчетов о прогнанных тестах. Какой тест запустился, во сколько, с какими параметрами, как прошел и т.д. Полезно при отладке. То же самое со снятием скриншотов в случае фейла теста.
Че-т дохрена букаф получилось. Вкратце, повторюсь, все проекты разные, везде свои требования, поэтому я допускаю, что что-то из перечисленного может быть лишним, а чего-то наоборот, может не хватать. Я перечислил то, с чем приходилось сталкиваться в рамках одного из последних проектов.
Все зависит от требований. Нет универсального решения на все случаи жизни, но по моему мнению и не самому большому опыту работы, общий костяк всего page object'а делается следующим образом:
1. Для каждой страницы приложения заводится отдельный класс, в котором прописаны локаторы для вебэлементов и методы по работе с ними. Названия элементов должны быть говорящими и отображать то, чем они являются. Локаторы, по которым ищутся элементы, не должны искать их, опираясь на какой-либо отображаемый текст. Айдишник, название класса, какие-то уникальные для элемента аттрибуты - да. Но не текст.
2. Тесты тоже разбиваются на классы по отдельным страницам. Если тест затрагивает несколько страниц, то было бы логично писать его в классе той страницы, где он начинается. Сами тесты должны быть атомарными и не зависеть друг от друга. Один тест - одна проверка. Проверки делаются через Assert'ы.
3. Навигация между страницами тоже должна быть продумана. Хорошо бы завести отдельный класс типа WebsiteNavigator, в котором прописаны методы для перехода между страницами и заданы относительные урлы для разных секций сайта, типа "/about-us", "/faq", "/menu" и т.д. Тогда при навигации по страницам в тесте можно дергать методы сайт навигатора, вместо жесткого хардкода урлов в самих тестах. Опять же, жесткий хардкод можно заменить чтением из конфига (см. п.7), но как правило, навигация по веб-приложению меняется не очень часто, поэтому ничего критичного в том, чтобы захардкодить пути нету.
4. Страницы инициализируются с помощью Page Factory. Впринципе, не сильно обязательно, но можно и так.
5. Запуск вебдрайвера. При запуске название браузера, его версия и настройки (для прокси, например), должны быть считаны из конфига (если предполагается прогонять тесты удаленно, на каком-нибудь BrowserStack или Souce Labs, то дополнительно нужно указывать еще ряд параметров). Вебдрайвер не должен быть статичным. Написать синглтон - дело полезное, потому что это нужно для запуска тестов в параллель.
6. Урл(ы), на которых гоняются тесты, также должны быть прописаны в конфиге и вытаскиваться из него кодом при запуске тестов.
7. Общие методы, не относящиеся непосредственно к тестам (скажем так, вспомогательные методы, вроде SelectRandomElementFromList(IWebElement webelementList), которые могут использоваться больше, чем в одном тесте) выносятся в отдельный класс типа Helpers или Utils. Использование Actions, ExpectedConditions, JavaScriptExecutor, понимание отличий между явными/неявными ожиданиями - только плюс.
8. Написание своих методов для вебэлементов (Extentions), для расширения возможностей вебэлементов, кастомные проверки (вроде собственного метода Displayed, который не выкидывает исключение, если элемент не найден, а возвращает человеческое False).
9. Если в тестах используются какие-то данные (заполнение форм, например, логин, регистрация и т.д.), то надо завести отдельный класс, объект которого будет иметь поля с данными для теста. В идеале было бы использовать внешний источник данных для тестов: CSV-файл с наборами валидных и невалидных данных для кредов, JSON, .xlsx табличка, и т.д. В крайнем случае можно захардкодить данные в код модели, чтобы при создании объекта класса его поля инициализировались одними и теми же значениями.
10. Хотелось бы видеть использование аннотаций из фреймворка для тестов, будь то NUnit, TestNG, или еще что. Из основных: OneTimeSetUp, OneTimeTearDown, Test, TestCaseSource, TestCase, Category. Опционально - разделение тестов по категориям. Удобно тем, что при запуске можно указывать, какие именно категории тестов запускать.
11. Ведение логов и отчетов о прогнанных тестах. Какой тест запустился, во сколько, с какими параметрами, как прошел и т.д. Полезно при отладке. То же самое со снятием скриншотов в случае фейла теста.
Че-т дохрена букаф получилось. Вкратце, повторюсь, все проекты разные, везде свои требования, поэтому я допускаю, что что-то из перечисленного может быть лишним, а чего-то наоборот, может не хватать. Я перечислил то, с чем приходилось сталкиваться в рамках одного из последних проектов.
Я вообще-то только про саму страницу и объекты спрашивал, а ты ринулся. Но в целом все верно, кому-то ещё итт точно не лишним будет почитать.
Как стать таким же умным, покурить что-нибудь? Просто где-то после 3 пункта пошёл тёмный лес и штуки такие ни разу не имплементировал и слабо представляю как. алсо ассерты должны проверять что вернет метод класса, которой страницу описывает?
Нужно просто взять реальный проект и начать под него писать тесты, периодически задаваясь вопросами "а все ли я правильное делаю?", "а не делаю ли я дублирующей работы?", "а не изобретаю ли я велосипед?" и т.д.
>Написать синглтон - дело полезное, потому что это нужно для запуска тестов в параллель.
Вот про это проясни подробнее.
Ну тип писал, позадавал вопросы - вынес данные в интернал константы, вот и вся оптимизация. Код тестов выглядит примерно так:
Страничка = новая страничка(инициализируемый браузер)
Страничка.написатьхуйню(123)
Страничка.сабмитфоры()
Ассерт.Истру(страничка. Залогиненно())
>>866086
Кстати говоря, решил память освежить в селениуме, чет не получается после открытия страницы по ссылке в новой вкладке получить имя, например, этой новой вкладки, все время возвращает старой атрибуты. Как корректно к новой вкладке, она чем является новым объектом типа драйвер или что? Интернеты гуглил, но чет не выходит как предлагают.
>Я вообще-то только про саму страницу и объекты спрашивал, а ты ринулся.
Ахах) Да что-то начал вспоминать, одно потянуло за собой другое, потом еще и еще.
>>866048
>Как стать таким же умным, покурить что-нибудь? Просто где-то после 3 пункта пошёл тёмный лес и штуки такие ни разу не имплементировал и слабо представляю как.
Дело практики. Я начал изучать автоматизацию где-то года полтора назад, и за 2016-ый год удалось у себя на проекте с нуля автоматизацию поднять в какой-то степени, включая интеграцию с TeamCity. Гугл и документация наше все.
>алсо ассерты должны проверять что вернет метод класса, которой страницу описывает?
Ассерты нужны для сравнения ожидаемого и фактического результата. Assert.Equal, Assert.IsTrue, Asset.IsFalse, и т.д. Например, надо нам проверить, что на появившейся странице есть нужный элемент: Assert.IsTrue(webelement.IsDisplayed()); Или, например, надо проверить, что урл страницы сответствует ожидаемому: Assert.AreEqual(expectedUrl, actualUrl);
>>866071
>Вот про это проясни подробнее.
Можно написать код для запуска браузера так, что сама переменная вебдрайвера будет статической. Подробнее про статику можно почитать на хабре (https://habrahabr.ru/post/206082/, например) или в документации. Я не уверен, что смогу достаточно полно описать самостоятельно. Фишка в том, что если запускать тесты параллельно при статическом вебдрайвере, тесты просто попадают. Запускаются два теста, открываются два окна браузера, и дальше получается так, что они перехватывают команды друг у друга и через некоторое время один тест проходит, браузер закрывается, драйвер сделал Driver.Close(), а второй тест начинает биться в конфуциях и падает. Синглтон призван решить эту проблему. Для каждого треда (допустим, мы хотим запустить несколько тестов параллельно, каждый в своем треде) создается свой объект вебдрайвера, который никак не зависит от других. В таком случае для каждого треда создается свой объект вебдрайвера и все в шоколаде. Но опять же, это частный случай решения, в яве параллельный запуск делается в разы проще и хоть на уровне тулзы для интеграции типа Jenkins'а. У дотнето-холопов есть NUnit, в котором параллельный запуск завезли недавно и он умеет гонять тесты параллельно в рамках 1 и больше тредов (https://github.com/nunit/docs/wiki/Parallel-Test-Execution). Тут опять же, много подходов возможно, включая дополнительные расширения для NUnit типа PUnit, своих костылей и т.д. У всех по-разному. Если итт есть дотнет-ананасы, поделитесь, своими сображениями по поводу параллельного запуска, какие подходы и как вы делали?
>Я вообще-то только про саму страницу и объекты спрашивал, а ты ринулся.
Ахах) Да что-то начал вспоминать, одно потянуло за собой другое, потом еще и еще.
>>866048
>Как стать таким же умным, покурить что-нибудь? Просто где-то после 3 пункта пошёл тёмный лес и штуки такие ни разу не имплементировал и слабо представляю как.
Дело практики. Я начал изучать автоматизацию где-то года полтора назад, и за 2016-ый год удалось у себя на проекте с нуля автоматизацию поднять в какой-то степени, включая интеграцию с TeamCity. Гугл и документация наше все.
>алсо ассерты должны проверять что вернет метод класса, которой страницу описывает?
Ассерты нужны для сравнения ожидаемого и фактического результата. Assert.Equal, Assert.IsTrue, Asset.IsFalse, и т.д. Например, надо нам проверить, что на появившейся странице есть нужный элемент: Assert.IsTrue(webelement.IsDisplayed()); Или, например, надо проверить, что урл страницы сответствует ожидаемому: Assert.AreEqual(expectedUrl, actualUrl);
>>866071
>Вот про это проясни подробнее.
Можно написать код для запуска браузера так, что сама переменная вебдрайвера будет статической. Подробнее про статику можно почитать на хабре (https://habrahabr.ru/post/206082/, например) или в документации. Я не уверен, что смогу достаточно полно описать самостоятельно. Фишка в том, что если запускать тесты параллельно при статическом вебдрайвере, тесты просто попадают. Запускаются два теста, открываются два окна браузера, и дальше получается так, что они перехватывают команды друг у друга и через некоторое время один тест проходит, браузер закрывается, драйвер сделал Driver.Close(), а второй тест начинает биться в конфуциях и падает. Синглтон призван решить эту проблему. Для каждого треда (допустим, мы хотим запустить несколько тестов параллельно, каждый в своем треде) создается свой объект вебдрайвера, который никак не зависит от других. В таком случае для каждого треда создается свой объект вебдрайвера и все в шоколаде. Но опять же, это частный случай решения, в яве параллельный запуск делается в разы проще и хоть на уровне тулзы для интеграции типа Jenkins'а. У дотнето-холопов есть NUnit, в котором параллельный запуск завезли недавно и он умеет гонять тесты параллельно в рамках 1 и больше тредов (https://github.com/nunit/docs/wiki/Parallel-Test-Execution). Тут опять же, много подходов возможно, включая дополнительные расширения для NUnit типа PUnit, своих костылей и т.д. У всех по-разному. Если итт есть дотнет-ананасы, поделитесь, своими сображениями по поводу параллельного запуска, какие подходы и как вы делали?
Гугли по "webdriver handle new window". http://stackoverflow.com/questions/19112209/how-to-handle-the-new-window-in-selenium-webdriver-using-java, например. Скорее всего, тебе надо переключиться со старого окна на новое открывшееся, и уже после переключения получать его название.
Да, все получилось по твоему линку, то что перефокусироваться нужно я сразу понял, а вот нагуглить что-то не получалось.
Чёто много написал, но большинство - нюансы.
Синглтоны, фабрики в 2017 лучше заменять DI + IOC.
Имхо, в таком задании я бы тупо сделал упор на разделение логики:
Слой PageObject - инкапсуляция работы с вебдрайвером, элементами, методами.
Тесты идут над слоем PageObject + навигаторами (ом).
>>866354
Как ты синглтоном решаешь проблему многопоточного доступа на время? В Java для этой хуйни есть ThreadLocal - переменные, которые держат копию на поток - вот их можно и в статику и в синглтон.
Непонятно правда: почему ты хочешь выдавать отдельные инстансы вебдрайвера на поток, а не на тест? Или у тебя есть тесты, юзающие несколько потоков?
мимо-младший погромист-перекатчик в тестеры
>Ты их с разрабами не путаешь случаем ?
Ага, по твоей логике разраб скажет "ну я хуй знаю, что это такое, это к админам", и будете так день пинать тикет в котором работы на 5 минут. Если можно приложить к багу достаточно информации, чтобы разраб не был вынужден его руками воспроизводить еще раз - так и надо сделать.
Это же не разбирать руками какой-нибудь бинарный протокол - просто запустить одну команду, потом сказать файлик и прикрепить к тикету.
Я уже чего только не слышал:
- питон-хуён, полторы библиотеки и никто не работает
- жаба-хуяба, монстрокод, терабайты оперативки, спагетти и говно
- руби-хуюби, мёртвая нераспараллеливаемая параша
- сишарп-хуярп, жаба для спермоворов и даунов
- ... жс, го, даже на новомодном элексире пьют смузи и автоматизируют
И всё же, что выбрать (интересует автоматизация функционального тестирования в вебе в первую очередь), чем обмазаться в связке с селениумом, полагаю??
Обычно ява\шарп из-за легкой интеграции со всякой хуйней типа CI - пишут на них, это если говорить про автоматизацию. А вот для нагрузочного хз даж.
Часто привязываются к языку проекта, но не обязательно, просто очевидно проще интегрировать тесты дергая методы основного проекта напрямую на том же языке, если это требуется. Питун просто моднявый, чего-то такого, что не дают другие языки для автоматизации у него нет. Руби вообще исключение, на нем в основном всякие миграции разве что на стопядисите гемах.
Ява\шарп, лучше ява, под нее больше утилит, в любом случае лучше смотреть исходя из потребностей реального проекта, кому то и на хаскеле удобно будет автоматизировать.
>Синглтоны, фабрики в 2017 лучше заменять DI + IOC.
Не слышал даже о таком, надо почитать.
>Непонятно правда: почему ты хочешь выдавать отдельные инстансы вебдрайвера на поток, а не на тест?
Создавать тред под каждый тест не сильно ли жирно в плане потребления ресурсов типа памяти и проца? Тестов-то не один десяток, и даже не одна сотня. Не дешевле ли создать, условно, 5 тредов, в которых будут создаваться максимум 5 драйверов?
>ThreadLocal
Есть и у дотнета, но не пользовался пока что.
На яве есть четкая штука для нагрузочного тестирования под названием JMeter. У дотнета для студии есть Test Manager Studio, так вот в ней тоже есть инструменты для нагрузочного тестирования, автоматизации функциональщины и т.д.
>Создавать тред под каждый тест не сильно ли жирно в плане потребления ресурсов типа памяти и проца? Тестов-то не один десяток, и даже не одна сотня. Не дешевле ли создать, условно, 5 тредов, в которых будут создаваться максимум 5 драйверов?
Ну раз у тебя отдельный тест выполняется от начала до конца в одном потоке - почему просто не создавать новый экземпляр драйвера на время жизни теста? Тем более, что при этом, в этом же потоке могут ебать и другие тесты.
А ты хорош.
Хочу попробовать в JavaScript'е пописать автотесты с помощью Selenium. Только капчую я с Mac'а, и не могу настроить. Есть, кто сможет помочь?
inb4: макоблядь соснула
Можно, кстати тупо код в тред? Класс странички, класс тестов, базовые классы и отдельно инициализацию вебдрайвера?
Искать новую работу где человеку с 0 навыков не дают задачу, от которой зависит успех проекта.
Мощно. Один вопрос: почему бы не вынести тесты в отдельные классы? Допустим, класс для смоука, класс для основного скоупа, может еще класс для тестов в процессе разработки.
Зачем? Чтобы не мешать в кучу тесты, переменные и методы страниц.
>почему бы не вынести тесты в отдельные классы?
Дело индивидуальное, имхо. На моем текущем проекте так и сделано, но еще и категории навешены для разных типов тестов. Есть набор классов с тестами для отдельных страниц (класс с тестами для одной страницы, класс с тестами для другой, и т.д.) и есть класс для смоука, в котором вынесены основные тесты на основной функционал. Ну а в тулзе для CI уже прогоняются нужные классы с тестами в зависимости от задачи. Плюс вынесения смоук-тестов в отельный класс - сразу видно, где какие тесты, без необходимости выискивать их по всему коду. Плюсы использования категорий - можно группировать по категориям тесты как угодно, даже если они в одном классе находятся, а при запуске достаточно перечислять названия категорий. В дотнете это выглядит примерно так: Типа nunit3-console.exe Tests.dll --where:cat=Smoke. В этом случае Nunit берет длл-ку, проходит по ней, находит все тесты с нужной категорией и запускает только их. Неважно, в каких они классах находятся, если нет дополнительных условий, типа "игнорировать тесты из такого-то класса".
>может еще класс для тестов в процессе разработки.
Мысль интересная. Допустим, мы завели еще класс для тестов на фичи, которые только делаются и еще не выкатили в прод. Фичи доделываются, тесты дописываются и что мы делаем с этими тестами дальше?
>Зачем? Чтобы не мешать в кучу тесты, переменные и методы страниц.
А они и так отделены. В одном классе - локаторы, вебэлементы и методы, которые взаимодействуют с этими элементами, в другом - тесты, состоящие из последовательности методов.
Из п.2 решил, что тесты лежат в одних классах с методами и полями страниц.
Категории - это здорово. С ними еще проще, чем с разделением тестов пол классам.
>что мы делаем с этими тестами дальше?
Включаем в основной скоуп тестов (категориям или классами, если категорий нет). Ведь до этого нам нужно было отделить их, чтобы не запускать вместе с основным скоупом старых тестов.
Единственный проблемный момент, который видится в этом случае. Предположим, у нас есть страница, для нее есть классы: Page.cs (с вебэлементами и методами) и PageTests.cs (с уже существующим набором тестов для страницы). На весь класс навешена категория, допустим "Regression". В один момент появляется таска: добавить дропдаун со ссылками на другие страницы на страницу Page. Мы хотим создать класс для тестов в процессе разработки и покрыть этот дропдаун. Мы добавляем класс TempPage.cs с локаторам для нового дропдауна, пишем несколько методов для работы с ним (если их еще нигде не приходилось писать раньше), добавляем класс TempPageTests.cs, пишем тесты, навешиваем категорию "Temp". Когда фича релизится и дропдаун становится неотъемлимой частью страницы, нам надо эти тесты перенести в категорию Regression. Но нам надо не просто поменять название категории с "Temp" на "Regression", нам еще надо аккуратно смерджишь Page.cs и TempPage.cs (классы с элементами и методами), а также PageTests.cs и TempPageTests.cs, чтобы не плодить кучу файлов на каждый чих.
Конечно, мы можем вместо заведения TempPage.cs просто обновить Page.cs, добавить туда локаторы и методы. Тогда останется только перенести тесты из TempPageTests.cs в PageTests.cs. Но переносить все-таки придется.
Возможно, я не до конца понял идею, если я не прав, поправь.
Есть как минимум еще один путь: под каждую таску девелоперы делают отдельный бранч в репозитории, делают в нем свою таску, отдают ручным тестерам. Когда те заканчивают, передают автоматизаторам. Новая фича покрывается тестами в этом же бранче и при мердже с мастером все изменения автоматически мерджатся. Из минусов: возможны конфликты мерджа, в этом случае надо очень аккуратно мерджить тесты, чтобы не потереть лишнего.
Последний вариант кажется правильнее.
В первом - зачем на весь класс повешена категория? Это разве не сводит на нет все плюсы категорий?
Если повешена только на один класс, то сводит. Если на несколько - избавляет от перечисления N классов, которые надо запустить. Подразумевается, что это лишь один класс из десятков, просто для примера взял один.
Upd: Опять же, никто не мешает вешать категории только некоторые тесты, и при запуске говорить раннеру "запускай только тесты с такой-то категорией, а остальные не запускай", или "запускай все тесты, кроме тех, у которых категория такая-то".
На мой взгляд, не добавляет. По мне так проще сделать разделение по классам, чтобы не запутаться, когда приложение здоровое, и повесить категории на разные группы тестов, чем внезапно осознать, что у меня ~1к тестов намешано в 2-3 классах на 10к строк, которые поддаются только рефакторингу уровня "снести все нафиг и написать с нуля будет быстрее".
Категории нужны для организации сьютов из набора пересекающихся классов\тестов, структуризация по классам - для поддержки архитектуры фреймворка и её частей. Не добавляет, избавляет от жопы при рефакторинге\передаче проекта.
В общем пока я остановился на testng + bamboo + ant( хз пока нужен ли, экспертизы нет у меня в нем). Хотелось бы про альтернативы послушать, бамбу убрать нельзя, знаю, что под дженкинс больше всего.
Не работал с bamboo, но года 3 назад чуть-чуть ковырял связку селениума, джавы и TestNG. Почему ант выбрал, а не мавен?
>Почему ант выбрал, а не мавен
Да не почему не выбрал, просто чаще видел такую связку, опыта в тестнг около нуля.
Остались две годные вакансии. Пойду вечером думать, что в резюме цепляющего написать.
В общем я остановился на restassured + testng, через месяцок-другой отпишусь по результатам и граблям собранным.
Давай, интересно было бы послушать
Ант сосет, выбирай maven или Gradle
Нужно быстро разобраться с RCPTT, а я не могу понять, как она работает.
очень много времени на сессию проебал
Посоветуйте годные гайды, мануалы, видео.
С меня как обычно нихуя)
Лол, во-первых не пизди, во-вторых ты как себе это предполагаешь? Глава 1 - дрочим поиск, глава 2 - дрочим логин и т.д. для всех возможных видов форм? Тебе может в бухучет пойти, там все четенько, по инструкции, думать не нужно, уметь переходить от общей теории к частному случаю тоже.
Ебать ты))))))))
Это же обычное текстовое поле, только с кнопкой и отправкой запросов на сервис, вот и думай
1.Заходишь на http://google.com
2. Параллельно открываешь определение термина "Тест-кейс"
3. Задрачиваешь поле для ввода поискового запроса разными способами
4. Анализируешь, что именно ты делаешь, применяя все известные методики вроде тестирования пограничных значений, классов эквивалентности, чтобы тест-кейсы покрывали поле достаточно плотно.
5. ?????
6. PROFIT!!!
может, оно тебе вобще не надо? ПОДУМОЙ, анон, есть куча других профессий
Минут 20 ковырялся, больше не могу сдаюсь
какие еще есть 4 проверки?
Тестеровщиком не работал, пока лишь планирую вкатиться
>>878824
Xss-ка ещё, хотя смысла нет в ней сейчас как и в поиске иньекций, если перед тобой не самописное говно на пыхепе
Лично видел, как на достаточно большом проекте, уже крутящемся в продакшене некоторое время, в полях для ввода отсутствовало экранирование спецсимволов и все говно протекало прямо в бекэнд.
@
ПРОВЕРИЛ ТРИ РАЗА
@
ЗАВЕЛ ТИКЕТ
@
ОТВЕТ: CUNT REPRODUCE
@
ИЗ АРГУМЕНТАЦИИ КОПИПАСТ КОДА, ВОТ, ВСЕ РАБОТАЕТ, ТАК И НАДО
@
КОД ИЗ ДРУГОГО МЕСТА
@
"Я ДИКА ИЗВИНЯЮСЬ А ВЫ ПРОБОВАЛИ ВОСПРОИЗВОДИТЬ ЛОКАЛЬНО?"
@
ПОСТ СКРИНШОТА С ОПИСАНИЕМ ШАГОВ
@
ЧИТАЕТ ШАГИ СО СКРИНА И ПЕРЕСПРАШИВАЕТ
@
ДОЕБАТЬСЯ ДО ШАГОВ НЕ ПОЛУЧИЛОСЬ
@
ЗАМОЛКАЕТ
Бля, да че делать-то? Гордость за код проснулась или что это за невебомая ебаная хуйня? Разработчик со стажем, работает долго, в одном проекте джва года, почалося в декабре
И шо в этом плохого, если их надо так хранить? Задача в том, чтобы их не выполнять
>если их надо так хранить?
Зависит от требований. Кому-то нужно все говно в базу писать, кому-то нет.
Пиши подробные тесты для нововведений и параллельно для старых частей. Со старыми не спеши особо, выдели самые важные старые части и пиши сначала для них, менее подробно, чем нововведения. Для начала пойдут даже кейсы вида "проверить страницу хуйнейм", по необходимости расширять.
Пока пишешь и находишь баги, заводи заявки, если на проекте это можно. Если нет, ну, просто в тестах помечай. Если старые баги, пришедшие от пользователей, чинят, для починенного бага тоже добавляй тест.
Перед каждым релизом проходить всю эту хуйню, если появляются новые баги, настаивать на починке (см. регрессионное тестирование)
Это в общем, я бы скозал, твоя главная задача это вести тестовые документы и записывать все баги, идеально в баг-трекер. Для новых частей если чинят сразу - хорошо. За бардак в старых ответсвенный это главный за продукт, ты не лезь все сам исправлять, твоя задача заносить информацию, а главный уже будет ставить прогромистам задачи починить.
А что, потанцевать нельзя?
Поддвачну вот этого >>883219. Сначала определи основной функционал, который 100% должен работать. Напиши чеклисты. Прогоняй их перед каждым релизом, чтобы этот функционал не отваливался. Параллельно пиши тест-кейзы сначала на этот основной функционал, потом на тот, который к нему "прилегает", потом уже на всякие вторичные вещи. Это может пригодиться в последствии при написании автотестов для регрессионного тестирования. Как у вас процесс разработки выглядит? Аджайл, канбан, вотерфол?
Я не он, но иногда не так просто определить методологию разработки. Например, у нас релиз выдается заказчику каждую неделю на внешнее тестирование, но при этом поинтов нет, и назвать это кроме как "хуяк хуяк и в продакшн" язык не повернется.
А при чем здесь поинты? Иди следом читать.
>работаю 4 месяц
>выглядит как хаос а не как МЕТОДОЛОГИЯ
Если ты один и тот же анон, то можно забить на все, что писал я выше в >>883513 и другой анон в >>883219. Если на проекте нет более опытного человека, который может построить процесс тестирования, то ты ничему не научишься а так и дальше будешь участвовать в хаотическом метании. Через год, если ничего не изменить, вы все так же будете делать бессознательные действия. Поэтому, тебе надо или хорошо обмазаться гуглом и выяснить все про методологии и построить все по-человечески, или валить на другой проект/в другую компанию, где уже есть поставленный на рельсы процесс и набираться уму-разуму там. В противном случае, если оставишь как есть, твоя ценность как специализда будет КРАЙНЕ МАЛА.
Ну зря ты его так обрываешь в попытках, многие с 0 так поднимали процессы, но тут нужно время и желания разбираться + конечно мозги определенные в обще-концептуальном, а не функционально-прикладном мышлении.
Пусть пробует, конечно. Но нужно для этого нужно сесть и начать гуглить, для начала.
Мне кажется несколько подозрительным, что ты должен платить за то, что делаешь какую-то работу. Пусть даже джуниорскую, но все равно, это же работа.
Ну хуй знает. ДАже стажёрам порой что-то платят.
Пф, нет конечно, совсем погонщики охуели. У тебя самого вообще в голове никаких мыслей не возникает при фразе "платить за возможность поработать на дядю"?
Что ж ты творишь, содомит? Хз как там у вас у бацки, но у нас в рф при зарплате 170 баксов люди меньше всего думают о том, чтобы 100 отдавать за какую-то стажировку. Всякие секты типа тяньши и прочей срани не в счет.
>по другому не берут никуда.
Ну если каждый раз человек платит чтобы устроиться на работу, я даже не удивлен, что по другому его, дебила, никуда не возьмут.
> И, на будущее - какие вопросы (кроме очевидных зарплата-условия-соцпакет) стоит задавать?
Тебе это, возможно, уже не актуально, а кому-то и поможет. И, на будущее - какие вопросы (кроме очевидных зарплата-условия-соцпакет) стоит задавать? Осторожно! Мова!
Вот кстати что нужно в шапку докинуть, если кто-то хоть раз её читал конечно, но в мову не могу, да и полотно там, в шапке же выжимка по возможности.
> мова
Я кстати хуею с рассказов о хохляцком ойти. В филиалах уважаемих бодишопов шмонают вещи, пиздят ноутбуки, а зарплаты у них всех - не менее 2.5 тысяч далларов. Убери-ка лучше эту ссылку, нормальным людям она ни к чему, а жителей лимпопо выручит генетическая память.
Вот блядь хохлосрачей тут только не хватало. Давайте дебилами-залетными-погромистами-1-курса ограничимся.
Двачую. Идите нахуй со своими хохлами. Здесь, блядь, тематическая доска и приличные люди сидят, а для политики и прочей ссанины есть другие доски.
Это не рассказы, это хохляцкая пропаганда рассказывает всем. Пруфов зп в 2.5к вы нигде не найдете. Реально какляцкие айтишники получают 10-50к гривен, топовые - 60.
Я для приличных людей можно сразу в $$ писать? Как-то я вашими гривнами не владею. и уж пересчитывать не собираюсь
1. Уральская мухосрань на 700к
2. Полгода опыта функциональшиком
3. 25к. на руки, к осени обещают 35к.
Мухосрань, 1.5 года автоматизации, функциональщины, управления проектами на уровне пм-ства. 50к.
Сложно сказать. Автоматизацией тоже занимаюсь (чуть выше итт мои полотна про Page Object в середине января и процессы тестирования в условиях канбана в конце декабря), но основное поле деятельности - ручное тестирование, учусь лидить небольшую команду, отвечаю за релизы. Руками сейчас тестирую не очень много, в основном что-то автоматизирую, пытаюсь придумать, что можно улучшить в текущем процессе тестирования, отвечаю на вопросы тестировщиков и иногда - девелоперов.
Расскажи про переходы по зарплатным ставкам, сам ли просил каждый раз, чем мотивировал, менял ли фирмы для повышения и т.п. Просто я сижу со своими ссанными 50к, а делаю все от аналитики до лидства и прокачки отдела. Хотя подобное размазывание по всему толку дает хуево и от этого печет.
Сам просил каждый раз. Как понимал мой уровень скилла не тянет на ту зарплату, которую мне платят, шел к начальству с описанием ситуации. После чего меня отправляли на собеседование с более продвинутыми альфа-самцами, по результатам которого принималось решение о повышении зарплаты/грейда. Просил не очень часть, где-то раз в год. Фирму не менял пока, меня текущая устраивает. Сейчас я по грейдам числюсь как миддл/миддл+. Подозреваю, что до сеньора еще пилить и пилить.
Аутсорс.
А немного подробнее? Какие именно переходы по навыкам были? Какие соответственно по зарплате?
1. ДС
2. Лет пять. Функциональщиком, потом автоматизатором, потом нагрузчиком.
3. 90 на руки.
Считаю что мои скиллы нагрузчика хуевенькие, пытаюсь научиться профилировать приложухи под прыщами, но пока то времени не хватает, то забиваю.
А ящитаю, что неправильно раздавать сеньоров направо-налево. Должны быть какие-то весомые достижения, которых у меня на данный момент не сильно много. Я знаю сеньоров, которые не знают английского языка, не общались ни разу с клиентом напрямую, которые тупо не знают, что такое тест-план и с чем его едят. Как они стали сеньорами? Социоблядство прокачано, очевидно. Совместные перекуры с начальством, приседание на уши, втирание дичи. Я так не умею, но считаю, что при первом более-менее серьезном челлендже такие "сеньоры" соснут хуйцов. На всемилюбимом западе и в загнивающей Европе для того, чтобы стать сеньором, надо ебашить как проклятый, лет за 10 при хорошем стечении обстоятельств можно чего-то добиться. Но на пост-советском пространстве почему-то считается, что если ты в 23 года не сеньор, то это все, даже червь-пидор чуть лучше, чем ты.
Енжой популяризация отрасли, натеклось всякого скама, который за лычку синьориты готов за 20к\месяц в жопу давать. В QA и так все мутно с грейдами, а подобный подход поощрения недалеких работничков ещё сильнее усугубляет, все блядь вокруг синьоры, только не знают в чем отличие тестирования от QA и как унаследовать класс или форкнуть ветку.
Чем сеньор тестер отличается от миддла и джуна, например. Чет никак не втыкну в эти грейды.
Образом мышления, стремлениями, отношением к происходящему вокруг, квалификацией, реакцией на события в проекте. Все очень субъективно, нет какого-то четко выраженного критерия, по которому можно провести разделение. Даже в пределах одной конторы, будучи сеньором в одном проекте, человек может провисать в новом проекте несколько месяцев. Это нормально, но как мне кажется, этот эффект можно немного ослабить, если активно расширять кругозор в области технологий, методологий, подходов к тестированию, к таким достаточно абстрактным вещам и идеям, которые при их реализации могут радикально различаться от проекта к проекту. Умение реализовывать такие идеи и привнесение новых, и отличает сеньора от джуниора и миддла. Опять же, это имхо анона, так что опровергать и спорить можно бесконечно.
Да, есть попытки загнать всех в рамки сертификацией ISTQB, например. Я знаю людей, которые ее проходили, как минимум первую ступень. Но по факту, этот экзамен нужен для того, чтобы систематизировать знания в голове. Вещь полезная, но не является необходимым условием для сеньора.
первый пидр, второй гей, третий какой-то не такой.
Это комплексная проблема. В аутсорсе как правило, требования к квалификации ниже, чем в продуктовых компаниях. Вот и течет туда скам, уровня "я не умею включать комп, пусть мне сеньор включит. Онжисиньор." И это хорошо для менеджеров: сунем еблану новому джуниору денег, продадим его как миддла-сеньора, и пусть работает. Ему помогут миддлы-сеньоры, которые на проекте есть, так что заказчик будет платить долго, маржа хорошая (много денег джуну не дадут, ага), контора имеет профит, менеджер имеет профит, все счастливы. Кроме миддлов-сеньоров, которые тратят время и силы на неофитов, а надежде на то, что оный возьмется за ум и чему-то научится. было дело, учил миддла-тестировщицу переоткрывать закрытые вкладки браузера
Вот я ньюфаг, закончивший айтишную вышку в сносном вузе города и собирающийся идти рработать тестером, и чет хуй знает. Ты пишешь про дырок с браузером (и как их вязли вообще?), а сверху отписывался парень, дрочивший всю теорию, знающий много для джуна, которого тем не менее послали лесом на собеседовании. И хуй знает кому верить теперь. Собираюсь отправлять резюме в продуктовую компанию, ссыкотно.
У меня был свой опыт, у того парня - свой. У тебя будет свой. Люди приходят устраиваться в разные конторы, разные люди проводят собеседования, у каждого свои требования, у каждого свои знания. Почему тебя так волнует опыт похождений других ананасов, которые с огромной вероятностью даже живут в другом городе?
> Это комплексная проблема. В аутсорсе как правило, требования к квалификации ниже, чем в продуктовых компаниях
Поддвачну. Понятно, что везде бизнес. Но в аутсорсе вообще один бизнес, как там развиваться не понятно.
В аутсосе есть, конечно, и хорошие миддлы, и сеньоры, которые охуительно знают весь платный стек банков-хуянков, но текучка кадров там пиздец. И это, по моему, показательно.
Что тестируешь, веб? Какие инструменты использовал?
Вообще с профилированием это уже не чисто нагрузочное а шире, performance (тестирование производительности), думаю, ты в курсе, но на всякий случай - есть такой чувак Brendan Gregg, пилит крутые инструменты и всякие статьи пишет, рекомендую всем, кто интересуется производительностью, хотя бы проглядеть про USE и TSA методы:
http://www.brendangregg.com/usemethod.html
http://www.brendangregg.com/tsamethod.html
По сети гулял опрос по зарплатам, локациям и опыту, так-то.
Веб, да. На прошлых работах юзал лоадранер, на нынешней гатлинг. Ну и джейметер еще смотрел, но что-то он мне не понравился.
За ссылки спасибо.
У нас на 20 рыл 5 телочек вместе с HR-ор, но ни одной в нагрузке или автоматизации, максимум одна старший инженер.
QA хороший шанс для распездолов проебавших в свое время все полимеры, стать востребованной единицей в ит, освоив нагрузку или автоматизацию или проявив лидерские качества верховодить функциональщиками и тоже стать кем-то, что не стыдно будет на встрече выпускников школы\вуза.
1. ДС2
2. Три года, начинал с функционального, сейчас нагрузкой
3. 90, через год надеюсь дорасти до старшего инженера, будет 120.
1. ДС-2
2. Чуть больше полугода, вкатился сначала через тест-документацию, сейчас добавилось функциональное и автоматизация, но в другой компании.
3. 50к
Разбавлю ценники рашки
1. Обл. центр в белорашке
2. 2 года, функциональщик
3. Где-то 550$ чистыми
Есть столичные аноны? Сколько с таким же опытом в Минске получают?
К jmeter надо просто немного привыкнуть, хотя его "графическое программирование" полный пиздец, конечно. Можешь, кстати, посмотреть на taurus - это открытый тул, который делает blazemeter, с его помощью можно разные генераторы нагрузки запускать, в основном они ориентируются на jmeter, на gatling тоже заявлен как поддерживаемый.
А вот и cockholey'ку с теми самыми бахатствами. Чай не нищие москали с жалкими ~1.5, мощная страна Украина все-таки
1. ПГТ-миллионник.
2. 1 год+ в тестировании.
3. ~38к рублей в месяц, это ставка, то есть оплата не по часам, а овертайма дохрена.
Больше скажу, надо вполне нормально относиться к собеседованию. Например, когда я менял место работы (тестировщика на тестировщика), я проходил несколько собеседований параллельно с общением по вакансии Product Owner'а. Подумал, что почему бы не сменить род деятельности, ещё не знал, что там будет проёб небольшой со стороны компании и в результате был на все сто уверен в себе, что ищу себе запасной вариант, если не возьмут на PO. В результате все собеседования прошёл хорошо, и уже начали терроризировать меня на тему "ну когда же ответишь?". В результате HR перестала пинговаться, я забил и ушёл к тем, кто тупо предлагал больше (вдвое больше, чем на прошлом месте работы). А та HR оказалась тупой пиздой, терроризировавшей многих моих знакомых, в результате там оказывалась не та работа и не те условия труда, что были оговорены заранее.
1. ДС
2. Около года
3. Начал с 35к, сейчас 40к, всё это время пока в одной конторе торчу. Думаю через несколько месяцев или выбить 2 дня удаленки, или +10к.
Известного товарного агрегатора, на последней работе - java стек. Куча внутренних библиотек, селениум (но его далеко не все используют, чисто бэкендовым автотестерам он есессно не нужен)
Хуяйвер.
Сап.
Нихуя в моей мухосрани работы нет, вот хочу попытаться вкатиться в тестирование.
Какие подводные?
Увидел в вакансии "стажер" и отправил резюме. Начал читать "Тестированиедотком" на хабре в какой-то статье нашёл
Скажут, что перезвонят, и не перезвонят. Смотри выше похождения анона, которого на младшего тестера не взяли.
Отличный настрой, наверное ты очень успешен в делах, в которых используешь такой подход?
>моя голова, когда прочитал все эти жаргонизмы
мимо_вообще_не_секущий_в_тестировании_но_желающий_вкатиться
Не, такой же лохпитурд.
Рабочий день кончился, посмотрим что завтра будет.
Пока все-еще обмазываюсь теорией и надеюсь на обучение с их стороны.
Теория - это хорошо. Не знаю, что от джунов сейчас принято спрашивать на собеседованиях. Года 4 назад спрашивали про то, что такое вобще тестирование, зачем оно нужно, какие у него цели, виды тестирования, уровни тестирования, что такое тест-кейсы, чек-листы и тест-планы. Может другие куаноны еще чего вспомнят.
Двачую, для ДС что-то хиленько, понятно, что не все боги 300кккк в наносекунду, но 40к совсем печально наверное.
Риальне маловато для ДС. А что ты делаешь вобще? Какие условия труда, неужто по дефолту запрещают работать удаленно?
Ок, первый этап пройден, вроде даже успешно.
На собеседовании был поиск багов в веб-калькуляторе на листочке и задача на логику про мужика и 4 таблетки.
Через неделю приедут дяди и тёти из ДС и будет второй этап.
Поболтал с директором, он объяснил что будут спрашивать в дальнейшем и скинул материалов для изучения.
Буду дрочить что уже дрочу Савин, протестинг.ру, хабр и то, что он скинул.
Такие пироги.
Мужик смертельно болен. Чтоб не умереть, нужно каждый день выпивать одну таблетку одного средства и другую другого.
Он вышел из дома и взял по две таблетки того и того.
При попытке приёма своих лекарств оказалось что они перемешались. Все таблетки одинаковые на вид/цвет/вес/запах/етц. Если ничего не примет - умрет. Если он примет две одинаковых тоже умрёт.
Что нужно сделать, чтобы не умереть?
Но ведь мечта же. Я любил ковырять игры ещё с детства. Да и разве не круто получить в руки игру в разработке, найти баги, помочь сделать её лучше? Работа мечты для меня, анон.
Хотя да, рутины там будет хватать, думаю. Как и в любой работе. Но, блджад, рутина в игровом тестировании все равно лучше сраных сайтов, которые ещё и надо перетестить в 3-4 разных браузерах.
экстримли слоу ответ, знаю
>рутина в игровом тестировании все равно лучше сраных сайтов
Если сайты ограничатся только визитками - да, если хоть что-то ещё - нет.
Такое вот мнение у человека, который только собирается вкатываться и пока не знает, как обстоит дело с другой стороны. Так-то со стороны оно и кажется, что сидишь смотришь на страницу в 4 браузерах сразу и тебе раз в месяц деньги приходят на карточку.
Если какая-то ecommerce-параша с магазинами и рекламой, то это куда хуже простой визитки. Такое тестить неприятно уже чисто по идейным принципам. А ты, анон, любишь рекламу, специальные предложения и слежку на каждом шагу?
ИЧСХ, такое в большинстве вакансий. Чтобы вкатиться в что-то не связанное с вебом, нужно дофига опыта и/или специфические знания.
>>897439
>кажется, что сидишь смотришь на страницу в 4 браузерах сразу и тебе раз в месяц деньги приходят на карточку
Я такого не писал. ИМХО, тестирование сайтов не проще тестирования чего-либо другого (а то и сложнее). Везде нужны тест-планы, нужно составлять и проходить тест-кейсы/чек-листы и писать правильно составленные, понятные баг-репорты. Кроме того, надо постоянно думать как юзер, который юзает продукт, и ходить по сайту/софтине соответствующим образом.
Вышенаписанное - взгляд дилетанта, никогда не работавшего в реальных компаниях.
>>897372
Ох, лол. Помню устраивался джуном после института, тоже загадывали эту загадку. Я чет затупил, они сказали "ну, рассуждай", ну я и дорассуждался в итоге до чего-то вроде "принять две любых, а если что выблевать". А в конце назвал ценник в два раза больше чем по рынку по незнанке
Хорошо, кстати, что не взяли, потом получше нашел, а про эту контору только плохое слышал.
Я вообще поначалу ответил, мол, а у него есть знакомый химик с каким-нибудь спектрометром, чтоб таблетки определить?
Ответили что есть, но дойти до него мужик не успеет.
Налицо попытка загнать кандидата в область ответов, которые сами интервьюеры знают и хотят получить. То есть они знают "условно правильный" ответ, и пытаются заставить кандидата решить задачу именно так, как надо им, отметая другие варианты, даже если они такие же результативные.
Ога. Всё так.
Анон выше писал что-то про спор о вопросе с пропускной способностью канала или что-то вроде этого.
Имею год косвенного опыта тестирования в софте , раньше не знал про эти все тест кейсы и прочее , делал то что требовал разработчик ( присылал баги , скрины , описывал их) . Косвенный потому что работал на другой специальности, а тестирование занимало малую часть раб. времени. На какую зп можно рассчитывать в дс ?
Вот уж не знаю, я сам из мухосранска-миллионника. У нас тут июнь-тестировщикам дают от 20 до 30к со старта, в зависимости от конторы.
1. Про носки:
Допустим, в наборе есть есть белые, черные и октариновые.
а. Достаем первый носок. Допустим, он белый
б. Достаем второй носок. Он может быть либо белый (уже пара), либо черным, либо октариновым.
в. Достаем третий носок. Он либо совпадает по цвету с уже вытащенными, либо является последним типом.
г. Достаем четвертый носок. Пофиг, какого он цвета, он уже гарантированно парный с одним из тех, что мы достали раньше.
Получаем правило: количество извлеченных носков = количество уникальных цветов носков + 1. Итого, максимум нужно достать 4 носка, чтобы получить пару.
2. Переплыть речку.
А одинакового ли цвета должна быть пара? В формулировке задачи об этом ничего не сказано.
Лол, как ты это сделаешь?
Вообще, все эти задачи такая же дрочь как ЕГЭ. В итоге компания просто узнает, что ты читал эти задачи и ответы к ним.
Фейспалм.
Спасибо , буду проживать 50
Даже такие игры лучше ковыряния сайтов. Хотя в перспективе (после ковыряния говноигр) хочу устроиться в нечто посолиднее. В Ubisoft Kiev постоянно открывают вакансии на тестировщиков, например.
>В Ubisoft Kiev постоянно открывают вакансии на тестировщиков
Вот почему у них игры багованое говно. Понабирают хохлов, а потом поди увольняют, потому что тестеры не доглядели
Тебе, видимо, хохол в маршрутке ногу отдавил, да? Вот ведь мрази эти хохлы, все до единого.
Цэ так.
Ну давай подумаем. Если пара необязательно должна быть одного цвета, то задача не имеет смысла, потому что достаточно взять 2 любых носка.
Жи есь. Когда я устраивался на работу, я походил на QA-курсы, которые компания организовывала, написал выпускной экзамен по темам, которые на курсах были, прошел устную беседу с одним из экзаменаторов (типа, устная часть экзамена), и через неделю мне позвонили, пригласили на собеседование с HR. А все эти задачи хз зачем нужны. Наверное, чтобы проверить скилл гугления кандидата.
Так и я о том же.
Гугления и запоминания бесполезной хуйни в огромных количествах...
1. Про носки - правильно. Я вот затупил, т.к. температурил тогда, и это было третье собеседование за день.
2. Насчет реки - здесь всё неоднозначно, по-моему, он имел в виду, что прям дом нужно перенести буквально на другой берег. Увижу его - уточню. :)
>заработаешь нервы, геморрой
А от обычного (не игрового) тестирования не?
>игровую импотенцию
Уже давно. Повзрослел, мать его. Играю в игры чисто по инерции, ибо больше хобби нету никаких. Хотя и нету особого желания. А раньше ведь так круто было сидеть и играть, играть, играть!
>А от обычного (не игрового) тестирования не?
Зависит от твоего отношения к процессу и самого проекта. Сижу 4-ый год в одном проекте, зависимости нет, брат жив.
Ну и смысл тогда в гейдев ломиться, если, как ты говоришь, тебе уже пофиг на игры.
Лично мне сейчас пердолить систему для мобильного оператора гораздо интереснее чем ебучую ферму.
Да хрен знает, в геймдев всё равно хочется. Он мне, в отличии от говносайтов, не противен.
И да, чому онли ферма? Другие жанры тоже бывают.
От знакомых, тестирующих высеры мейл.ру слышал, что зарплата у тестеров в геймдеве ниже где-то на 30% относительно веб и встроенщиков.
>что в первую очередь делать, покрытие юзерстори для полного бизнес процесса или нагрузку на отдельные контроллеры
нет универсального ответа, все зависит от скоупа релиза, времени и трудозатрат - если изменения касаются 1-3 сервисов или, например, одной БД чаще всего имеет смысл тестировать компонентно (дыры, если есть закрыть моками), если изменения в большинстве сервисов и в основных БД-однозначно проводить комплексное.
понятно что бывают конкретные задачи (стресс-тестирование конкретного сервиса или тестирование стабильности всего контура например) которые сами по-себе определяют границы.
>>899494
Да я в общих чертах-то хорошо понимаю что по отдельности и интеграционно можно протестировать, допустим есть 1-2 месяца, 50 апих, 10-20 юзерстори, использующие пусть 30 апих из 50.
"Покрыть сначала все 30 апих, посмотреть их отдельно и затем юзерстори все"
или
"покрыть необходимые для 1 юзерстори апихи и так по одной стремится к полному покрытию, и только потом покрыть 20 оставшихся?"
Вопрос больше с точки зрения камней, то что 2 вариант предпочтительней с точки зрения планирования и оценки это понятно.
Говносайты сильно разные могут быть в разрезе 1 фирмы = тебя не заебет однообразие. О фирмах, где делают принципиально разные игры я не слышал. Либо будешь реально браузерно-алаварное говно для даунов тестировать, либо танчики какие и хер тебе что новое там дадут, потому что просто нет.
Ок, давай разберём типы браузерно-алаварного (и мобильного) говна.
Такие фирмы обычно делают игры следующих жанров:
- фермы
- match-3
- головоломки
- hidden object
- F2P-сессионки
- раннеры
- tower defence
- простенькие 2D-платформеры
- кликеры
- примитивные однопальцевые игры на реакцию типа Flappy Bird, Dual или Crossy Road
- иногда простенькие MOBA, twin-stick шутеры и прочие упрощения "взрослых" жанров
Теперь подробнее о каждом, с моей дилетантской точки зрения:
Фермы - днище. Играть, а уж тем более, тестировать - малоприятное занятие. Кейсов - множество, ибо в таких играх обычно есть тонна побочных занятий, которые надо покрывать тестами, и всё это невероятно занудно.
Match-3 - тоже не особо интересный жанр. Играть скучно, но зато относительно легко тестировать. Игромеханик - всего ничего, знай складывай кристалики/сладости/фигурки/прочую хуету. И карта есть, на которой практически ничего не происходит, кроме выбора уровней. И ещё бустеры, куда ж без них. И всё.
Головоломки - обычно подчиняются строгим правилам, от которых уходить нельзя, поэтому тестить несложно. Интересность зависит от конкретной головоломки.
Hidden object - скукота... но красиво. Особенно, если арт-дизайнеры старались. Тесты почти все на гуй и их немного. Это почти как визуальную новеллу тестировать.
F2P-сессионки - то же, что и ферма, но обычно поинтересней (зависит от жанра сессионки).
Раннеры - скучно, но относительно просто. Игровая механика обычно простая, тестить несложно (хотя зависит от конкретного раннера: Temple Run или Subway Surfers - проще, Super Mario Run - сложнее).
Tower Defence - башенки, тупо и ничего особо сложного. Может быть интересно.
Платформеры - тестить довольно непросто (коллизии-хитбоксы и другая физика, ИИ вражин, разные правила на разных уровнях и это всё), но зато, чёрт возьми, интересно! Это жы аркадные платформеры, как в детстве на дендях-сегах! Также бывают паззл-палформеры, менее интересны, но обычно проще по тестированию.
Кликеры - те же фермы, только попроще, как в геймплее, так и в тестировании.
Однопальцевые игры - обычно быстро надоедают, но и тестировать там почти нечего.
Другие жанры - сложно, но интересно. Особенно, если упор больше на геймплей, чем на донат.
Если коротко: good tier: платформеры, головоломки, однопальцевые, другие жанры mediocre tier: match-3, hidden object, раннеры, TD shit tier: фермы, сессионки, кликеры.
Мета:
Социальная интеграция и Google Play Games - тут могут быть 3rd party баги, непонятые до конца прогерами API и прочий геморрой.
Донат - опять геморрой, но тут ещё добавляются приколы с оплатой, которая может не проходить, или, наоборот, проходить, но игра не выдаст юзеру плюшки, отчего тот справедливо бугуртит и идёт в стор ставить одну звезду.
Реклама внутри приложений - обычно там нет ничего сложного, надо лишь проверить, не закрывают ли баннеры важные элементы на разных разрешениях, правильно ли появляются/исчезают когда нужно и правильно ли обрабатываются клики по ним.
Проблемы браузеров - очередной геморрой, который в описании не нуждается.
To sum it up:
В некой мере согласен с твоим мнением, так как алаварофирмы обычно делают говно из последней категории. Но есть также не такой уж и маленький шанс попасть на тестирование чего-то более нормального.
Но! В вебе ведь тоже обычно дают тестить всякие интернет-магазины и прочую парашу, которая похуже ферм будет. Так что я всё же выбираю геймдев.
Ах да, ещё из тестировщика ферм есть возможность уже с опытом куда проще перекатиться на тестировщика в Ubisoft или Crytek в Киеве или хотя бы в Gameloft в Харькове. А в вебе будешь сидеть тестировать сраные магазины до старости. Так-то.
Ок, давай разберём типы браузерно-алаварного (и мобильного) говна.
Такие фирмы обычно делают игры следующих жанров:
- фермы
- match-3
- головоломки
- hidden object
- F2P-сессионки
- раннеры
- tower defence
- простенькие 2D-платформеры
- кликеры
- примитивные однопальцевые игры на реакцию типа Flappy Bird, Dual или Crossy Road
- иногда простенькие MOBA, twin-stick шутеры и прочие упрощения "взрослых" жанров
Теперь подробнее о каждом, с моей дилетантской точки зрения:
Фермы - днище. Играть, а уж тем более, тестировать - малоприятное занятие. Кейсов - множество, ибо в таких играх обычно есть тонна побочных занятий, которые надо покрывать тестами, и всё это невероятно занудно.
Match-3 - тоже не особо интересный жанр. Играть скучно, но зато относительно легко тестировать. Игромеханик - всего ничего, знай складывай кристалики/сладости/фигурки/прочую хуету. И карта есть, на которой практически ничего не происходит, кроме выбора уровней. И ещё бустеры, куда ж без них. И всё.
Головоломки - обычно подчиняются строгим правилам, от которых уходить нельзя, поэтому тестить несложно. Интересность зависит от конкретной головоломки.
Hidden object - скукота... но красиво. Особенно, если арт-дизайнеры старались. Тесты почти все на гуй и их немного. Это почти как визуальную новеллу тестировать.
F2P-сессионки - то же, что и ферма, но обычно поинтересней (зависит от жанра сессионки).
Раннеры - скучно, но относительно просто. Игровая механика обычно простая, тестить несложно (хотя зависит от конкретного раннера: Temple Run или Subway Surfers - проще, Super Mario Run - сложнее).
Tower Defence - башенки, тупо и ничего особо сложного. Может быть интересно.
Платформеры - тестить довольно непросто (коллизии-хитбоксы и другая физика, ИИ вражин, разные правила на разных уровнях и это всё), но зато, чёрт возьми, интересно! Это жы аркадные платформеры, как в детстве на дендях-сегах! Также бывают паззл-палформеры, менее интересны, но обычно проще по тестированию.
Кликеры - те же фермы, только попроще, как в геймплее, так и в тестировании.
Однопальцевые игры - обычно быстро надоедают, но и тестировать там почти нечего.
Другие жанры - сложно, но интересно. Особенно, если упор больше на геймплей, чем на донат.
Если коротко: good tier: платформеры, головоломки, однопальцевые, другие жанры mediocre tier: match-3, hidden object, раннеры, TD shit tier: фермы, сессионки, кликеры.
Мета:
Социальная интеграция и Google Play Games - тут могут быть 3rd party баги, непонятые до конца прогерами API и прочий геморрой.
Донат - опять геморрой, но тут ещё добавляются приколы с оплатой, которая может не проходить, или, наоборот, проходить, но игра не выдаст юзеру плюшки, отчего тот справедливо бугуртит и идёт в стор ставить одну звезду.
Реклама внутри приложений - обычно там нет ничего сложного, надо лишь проверить, не закрывают ли баннеры важные элементы на разных разрешениях, правильно ли появляются/исчезают когда нужно и правильно ли обрабатываются клики по ним.
Проблемы браузеров - очередной геморрой, который в описании не нуждается.
To sum it up:
В некой мере согласен с твоим мнением, так как алаварофирмы обычно делают говно из последней категории. Но есть также не такой уж и маленький шанс попасть на тестирование чего-то более нормального.
Но! В вебе ведь тоже обычно дают тестить всякие интернет-магазины и прочую парашу, которая похуже ферм будет. Так что я всё же выбираю геймдев.
Ах да, ещё из тестировщика ферм есть возможность уже с опытом куда проще перекатиться на тестировщика в Ubisoft или Crytek в Киеве или хотя бы в Gameloft в Харькове. А в вебе будешь сидеть тестировать сраные магазины до старости. Так-то.
смотри с точки зрения рисков для бизнеса - из твоих вариантов однозначно лучше выбрать второй так как в первом варианте есть большой шанс пропустить интеграционный дефект (например если на проде выяснится что при выходе из строя одного незначительного сервиса забиваются конекшн пулы и ложится все окружение спасибо тебе не скажут даже если сам сервис ты тестировал отдельно), так что всегда лучше сначала покрывать юзерстори и уже потом, если с этим все в порядке, покрывать остальные апи/сервисы. особенно актуально если до тебя НТ не проводилось вообще. из своего опыта скажу что подавляющее большинство проблем с производительностью (и не только с производительностью кстати) у нас было выявлено именно при проведении комплексной нагрузки при том что по-отдельности сервисы вполне могли тащить
Оставайся хиккой, но имей к себе уважение. Зачем зарабатывать меньше, если можно зарабатывать больше?
Двачую господ >>899759 и >>899778. Захочешь пересмотра зарплаты запросить, а тебе и говорят "мы и так платим больше среднего по городу, так что азаза, либо меняй место работы, либо жди, пока средняя по городу к твоей подтянется".
>>899778
>>899829
Господа, вы, видимо, не смотрели зарплатные предложения в вакансиях на QA-джуна без опыта в Украине. Везде 200-250$, но бывает и меньше. Больше тоже бывает, но там обычно требования уже повыше и хотят опыт хотя бы год. Я вот прошу вообще 200$ (с последующим повышением до 250-300), этого мне хватит на поесть, заплатить за жильё/инет и купить себе какую шмотку на рынке взамен износившимся + ещё немного на личные расходы. Разве плохо?
Вот отработаю хотя бы год - буду уже просить 350-400$.
https://ebanoe.it/2016/07/29/it-hr-sect/ - есть скрин с инсайдерской инфой. Знатно поджигает пердаки даже в конторах РФ.
Проиграл с рейджа аффтара-с-короной-на-голове, лол. После его выпадок на, кстати, вполне адекватные и тактичные каменты в этом документе (удивительно для HR, хотя это же IT), начинаю верить, что 90% описаний ебанавтов в этом чёрном списке - правда, а аффтару пичот именно потому что он один из них.
Ебаное вообще сбор каких-то школотронов, которые к ит 0 отношения имеют судя по комментам, либо хрелансеры\работники фирм рыл на 10. Я вот не хочу хохлосрач разводить, но ушибленные на голову там большинство, я бы с такими работать не хотел, несут откровенную хуиту, даже для хейта.
Мне кажется, ебаное - это такая борда типа /b. Все все понимают, но специфика такая, что полное ебанатство - это такой стиль, а не образ жизни
Слишком уж много лойсов под тупыми высерами на абсолютно нерелейтед для бомбления темами, вроде волги которую подарили - что это блядь вообще делает на ресурсе посвященному хейту кретинизма в ИТ.
Читал это. Про зарплаты говорю из личного опыта смотрения вакансий. Там 200-250$ почти всегда, иногда 300$. Это для джунов без опыта.
К тому же, хочу добавить, 07.2016 доллар был 24-25 грн, а сейчас 27-28. Возможно, это не столь важно, но всё же.
До сих пор считал, что такой скилл нарабатывается при расширении кругозора, обобщении полученного опыта и выделения из него общих частей, идей и т.д. Но если есть какие-нибудь спецтехники для такого, то круто, присоединяюсь к вопросу.
>QA manual middle 900-1700
>QA automated middle 2500-3000
Че правда? А в ДС тайкой-же форк? Типа я годами дрочил технологии и все равно получаю как функцональщик?
Пиздец. Говорили мне посоны с прошлой работы что я продешевил, а я не верил. Я как бы и свою зп за месяц не успеваю потратить, но нахуя получать меньше если можно получать больше?
Нет, не крупная, человек 20 в офисе и 10 на удаленке.
>>897075
Обычно мануальное тестирование нового функционала, комплексное ежерелизное тестирование "сложных" модулей системы (более простые и рутинные тестируют удаленные тестеры), тестирование процедур в СУБД, плюс всё тестирование телефонии. Условие труда неплохие, стандартный набор чай-кофемашина в офисе, формально рабочий день обычные 9 часов, фактически 8:40 получается. Почти бесплатный (5к в год для сотрудников) спортзал, бассейн. На удаленке так-то не запрещают совсем, пару раз в месяц из дома работаю, если прошу отпустить куда пораньше - отпускают без проблем. Но полностью перекатываться удаленно в этой конторе не хочу, потому что там по деньгам будет мало, у удаленщиков почасовая оплата.
А у менеджеров насколько всреднем зп вырастает относительно тех же куа? Просто сам знаю ПМов, у которых зарплата ниже моей, а я по этим картинкам из интернетов, попадаю к верхней границе
>QA manual middle 900-1700
Думаю, в какую сторону катиться дальше.
Там я был и эти цифры заставляют комплексовать, потому что я сам работаю на международной™ не самой малой галере и часть коллег из вна украины. И я б не сказал, что они топ-звезды при таких ценниках.
>тестировщика — качество процессов и скорость работы
Начал понимать, что судя по всему, пора валить из текущей конторы и продавать себя куда-нибудь еще.
>Просто сам знаю ПМов, у которых зарплата ниже моей, а я по этим картинкам из интернетов
Расскажи, рлз, чем ты занимаешся сейчас.
Автоматизация (селениум, дотнет), ручное тестирование, лидирование небольшой команды из 3 тестеров (2 мануальщика, 1 автоматизатор), последнее время отвечаю за релизы. Ну как отвечаю... Пишу/фикшу автотесты, помогаю разобраться в непонятных вещах тестерам и девелоперам, помогаю с эскалацией вопросов до начальства (бывает такое, что люди стесняются общаться с ПМом и прочим руководительским составом), пытаюсь как-то поддерживать и постепенно улучшать процессы тестирования.
> Потому что у вас продукт в основном, а у нас продажа рабов через местных погонщиков забугорным вельможам
Да, не, продукт есть кончено, но чое мало. 90% вакансий - в банки, которые, закупают продукт у зарубежных контор, и потом его дабл чекают, или интеграторы, которые, опять же, с банками работают.
Реально ли, что люди, которые не могут закрепиться в более "престижных" областях ойти, могут успешно сидеть в тестировщиках?
Это не троллинг, просто спросил честно. Никого из qa оскорбить не хочу.
Имеется желание вкатиться и получать более-менее зарплату для России, но нет никакого желания получать ВО и тратить год-два на изучение "в стол".
У меня спрашивали про ВО при вкатывании и у меня сложилось ощущение , что если бы не ВО, то шансы на вкатывание у меня упали бы примерно до нуля. Нахер компании нужен чувак без опыта тестирования, которому надо учиться будет, а он банально вышку не осилил.
Ну ты уж слишком категоричен, прямо унизил меня. Английский у меня как раз-таки нормален, на мой взгляд. По тестам upper-intermediate.
И айсикью 117. Не фонтан, конечно, но и не тупой.
Однако чего-то не хватает. Чувствую, что не стану каким-нибудь джава девелопером точно, а на фронтенд убивает количество требуемых знаний. Если раньше можно было вкатиться с кривыми макетами и неважным js, то теперь будь добр знать дохуя и больше, еще 1-3 года опыта коммерческой разработки подавай. Хотя это и исправляется пет-проектами, я в курсе.
Но с другой стороны, когда ты просто хочешь вылезти со днища и перед тобой встает выбор — или учиться самому на голой мотивации около года (как в вебе), или прочитать книжку Савина и идти на собеседование тут я утрирую, но многие так и сделали, судя по постам в инете и даже в qa тредах здесь.
Естесственно и думаешь о том, чтобы закатиться поскорее и заниматься тем, от чего не тошнит.
>>901571
Жаль, если так.
>Тут уж тебе виднее, тут ведь не только фактор зп учитывать надо.
Да дело не только в зарплате. Тут куча нюансов, из которых складывается, что зарплата вроде и выше среднего (а уж по городу так вобще), и проект вроде как нормальный (относительно, конечно), но нюансы все портят.
Благодарю за ответ. Есть желание найти что-то свое и ебашить, наверное так. Не могу пока сказать, мое ли тестирование, ибо читал о нем только вскользь. Усвоил только, что с нуля на автоматизатора попасть почти нереально, гораздо реальнее на ручника.
Ну и платиновый вопрос тебе, раз уж отвечаешь обычно тред довольно мертвый: что нужно читать или учить, перед тем как лить свою рожу на хх?
Пока что идея в том, чтобы прочитать Савина и книжку от епамщика Куликова, Канера читать не хочется. Может, еще пройти какой-нибудь курс по базам данных, ибо судя по всему без них вообще никак.
У меня тоже охуительный проект, очень много возможностей для экспериментов и с автоматизацией, и с организацией процессов, но сам заказчик весьма пассивный и бывает так, что въебываешь-въебываешь, а отдача бывает только в случае, если накосячишь и к тебе прибегает начальство с "анон, почему на вас жалуются?". А похвалы или хоть какого-нибудь одобрения добиться практически нереально. Да, конечно, можно относиться к этому как "вот вам дают деньги, хули вам еще надо?", но кмк, тело и душа должны жить в гармонии, и усилия не должны быть незамеченными.
Если хочешь кодить, то лучше дальше пытайся вписаться в кодеры. Без опыта работы сложно устроиться, и девом, и тестером.
> что нужно читать или учить, перед тем как лить свою рожу на хх?
Мимопроходил.
Вообще ничего не читал. Скроллил вакансии и увидел что требуется стажер и всему обучат сами. Тут-же написал резюме и нашёл этот тред. Полистал и наткнулся на книжку Савина, статьи на хабре, лекции на ютубе, етц. Сижу, обмазываюсь.
На собеседование пришёл на следующий день. Первый этап пройден, второй на некст неделе.
Такая роскошь в виде стажерских мест, наверное, только в ваших ДС и ДС2 и доступна. Я хоть и в миллионнике Екатеринбург, но тут ребята из Наумен стажерами зовут только четверокурсников . А я ж дно без ВО.
Я другой анон, но впишусь
>что нужно читать или учить, перед тем как лить свою рожу на хх?
Савина читай. Его советуют всем, пока никому не повредило. Но только Савиным ограничиваться не стоит, попробуй еще Луизу Тамре почитать, если Канера неохота (у меня наоборот, Тамре не зашла, а Канер пошел норм). Без применения прочитанного на практике знания очень быстро выветрятся.
>Может, еще пройти какой-нибудь курс по базам данных
Для общего образования и кругозора не помешает точно.
Вообще мимо. В городе едва-ли набереися 500к населения. Вышки тоже нет, только средне-специальное юрист, лол
>>901587
Спасибо за пост, сохранил. Изучу ссылки со свежей головой.
Радует хоть, что верстку более-менее знаю, как и девтулсы в хроме - учить меньше.
А насчет Украины — пока рыл инет на тему вката в qa, создалось впечатление, что у вас там айти-бум и профессия тестировщика расцветает. Такое ощущение, что галерам понадобилось столько рабов, что готовы учить сами бесплатно, ибо такое я часто встречал именно на украинских ресурсах.
Даже qatestlab с их бесплатными интенсивами по тестированию по - украинский.
>>901588
Повезло, значит. В моем 150к городе, откуда приехал, вакансий в тестировании вообще не было.
Если тебе лень - я пойму. Обидно просто.
>>901587
Годно, возьму на заметку.
Если кто не успел.
>>901579
Начнём с того, что вкатиться в автоматизацию с соотв. навыками проще — потому что на мануальщиков просто орды войтивайтишников как ты.
Савин — копипаст с Канера, но пойдёт. Но лучше Канера.
Вдоль и поперёк прохуячь protesting .ru
На в3скул курс по html, потом по SQL, потом на codeacademy — курс по SQL (там интересней).
Освой панель разработчика, в хроме тебе нужны будут вкладки elements, console и network.
Попроходи всякие тестики вроде упомянутого выше testingchallenges. thetestingmap. org/index.php
Учиться на кошках для автоматизатора можно тут
the-internet0. herokuapp. com
Обмажься всякими мануалами из гугла junior qa interview и прочими читлистами вроде этого guru99 .com/complete-web-application-testing-checklist.html
Всё, ты готовая макака, дальше или получаешь удвоенную от стартовой зарплату через год и деградируешь годами, или дропаешь, или растёшь в куче разных направлений.
Алсо, я устроился с английским upper-intermediate, Канером и 3х недельными халявными курсами за спиной. Вышки не было и не будет. Но это Украина, хуй знает какие у вас в Великой реалии.
>>901580
Отсутствие позитивного фидбека реально угнетает, я понимаю о чём ты. С другой стороны, если у тебя есть возможность практиковать любую срань господню на реальном проекте, я бы воспользовался таким шансом. Только главное не забывать основной вопрос: а не хуйню ли я делаю?. Но это только мой взгляд с левой колокольни, так-то я, как сказано выше, сам недавно жёлтое оперение джуна сбросил.
Если кто хочет помочь - жалоба тут https://2ch.hk/d/res/428289.html#429115 (М)
Проверка на актуальность капчи глобальна, и при попытке отправки сообщения заполненная капча в попапе разбана перестаёт считаться валидной. Хе-хе, не более.
Вряд ли, там походу автоматом за одну из ссылок. Но спасибо что сохранил, я как-то не имею привычки сохранять посты.
>>901601
Спасибо. Больше ничем.
Ну а по теме ты понял, надеюсь. Проявляющего зойчатки разуме джуна и нынче оторвут, но надо пробиться сквозь толпы неадекватов (в которые и тебя поначалу зачислят).
>айти-бум и профессия тестировщика расцветает
Скорее галеры поняли, что можно выбить с заказчика позицию мидла, взять двух юнцов за еду и продать их как одного мидла, а реально работу будут вытаскивать реальные мидлы, которых продали как сениоров и тимлидов.
Но это неточно.
Да сегодня что-то на удивление бурный вечер. В /b еще тред про фрилансеров с гаражами и аквалангами бурлит необычайно активно.
Действительно ли QA считается более женской профессией?
Без толстоты плз.
Я диванный теоретик, но по-моему тестирование и разработка это разные вещи. Многие идут просто потому что разработка слишком сложна для вката с нуля, и они надеются через тестирование потом перекатиться в кодеры. Хотя это и неправильный подход, я полагаю.
А так да, баб там много. Потому что усидчивость, внимательность, прилежность - важные качества в профессии, а у девушек они традиционно сильнее.
И да и нет. Мне кажется, тут немало девочек, которые не могут перезапустить проводник если его процесс умер. Скоуп знаний однозначно меньше чем нужно иметь чтобы пойти разработчиком. Однако, ничто не мешает тебе быть хардкорным альфа тестировщиком, умеющим и в разработку, и в настройку серверов, и в то как работает HTTP. Тогда и с другими отделами проще находить язык, и считать тебя безруким неосилятором тоже вряд ли кто-то станет.
Алсо, хватает и среди разработки кривых дебилов, некоторым приходится объяснять как подключиться к серверу через putty, хуй знает где таких берут.
Уже выпилили. Но там был адъ и Израиль.
>>901863
Не обязательно. За себя скажу, что я поначалу думал, что вкатившись в тестирование, я смогу перекатиться в девелоперы. А потом посмотрел на то, что требуется от девелоперов и понял, что мой мозг не настолько гибкий, поэтому лучше продолжу совершенствоваться в том, что я хоть как-то умею. Как говорится, "лучше править в аду, чем прислуживать на небесах". Да, конечно, у девелоперов больше денег, чем у тестировщиков, но в таком случае, есть еще кучи профессий, где крутятся еще большие бабки. Всегда найдется кто-то, кто зарабатывает больше тебя.
В общем и целом, тестирование и разработка - вещи довольно разные и не всем подходят. Кто-то может хорошо разрабатывать, кто-то - хорошо тестировать. Но если хочешь вкатываться девелоперов, надо и ходить на собеседования девелоперов.
Женщин много, но о йоба тестировщицах я не слышал, ибо большинство не способны развиваться дальше ручных макак. В моей конторе никто не относится пренебрежительно к тестировщикам и все работают как единый организм.
Как правило, совсем йоба-тестировщицы довольно быстро сваливают в менеджмент, аналитики и в прочих консультантов. А так - я сталкивался с реально крутыми тетками-тестировщицами, но их капля в море по сравнению с ручными макаками. Даже автоматизаторш среди них очень мало, а те что есть - не самые продуктивные (опять же, из тех, что я знаю)
Имею гуманитарное образование, но всегда была тяга к совершенно противоположным вещам. Считаю тестирование отличный шанс вкатиться в ойти если ошибся с образованием. Только ущербный будет считать, что это женская профессия. Можно и повара прировнять к женской профессии, но все знают какого пола лучшие шеф повара.
Вот я о этом и говорил, взять автоматизацию, мало там женщин. А про нагрузочниц вообще нигде не слышал. Так что анон не забивай себе голову, нравится тестировать, бери и тестируем, главное на месте не стой и развивайся, чтобы тебя не сравнивали с женщиной.
Блядь, это каклы, не надо пытаться их понять. Они будут получать 300 далларов и верещать про 1200. Тебе кажется это диким, мол, зачем пиздеть перед самим собой - забей, у недолюдей это в ДНК, лол. Вангую там "инсайд пруф" уровня скриншота экселя.
Такой же, в 2,5 конторах как и в хохляндии. Все знакомые хохлы из сферы что из епамов-люксофтов, что ещё откуда получают среднестатистические 100к деревянных в долларовом эквиле.
С чего начать, что учить потом, какие надо знания заиметь перед тем как в тестировщики лезть?
Из того что имею: макбук про.
Перекат запили, нуфаг. Дедушка просит.
>макбук про
Можешь даже в проектировщики вкатываться!
А если серьезно, то минимум будет заценить software-testing.ru, прочитать Савина (Тестирование дот ком). Можно еще Канера Testing Computer Software навернуть, но будет сложно.
+ хорошо бы глянуть обзорные курсы по SQL, чтобы без проблем писать селекты и инсерты на собеседованиях
+ хорошо бы глянуть что-нибудь про Perl, освежить знания. Врядли ты все забыл, а знание скриптового языка будет выделять тебя среди толпы соискателей на июнь тестировщика
https://2ch.hk/wrk/res/903817.html (М)
https://2ch.hk/wrk/res/903817.html (М)
https://2ch.hk/wrk/res/903817.html (М)
Этот перекат нелегитимен и создан обиженкой, которого изгнали ссаными тряпками с испытательного срока ручников, правильный перекат:
https://2ch.hk/wrk/res/904052.html (М)
https://2ch.hk/wrk/res/904052.html (М)
https://2ch.hk/wrk/res/904052.html (М)
Этот перекат нелигитимен и создан в попытках компенсации обиженкой, которого, как обычно, легко полуунизили господа девелоперы. Правильный перекат самый первый.
Позаябывай HRов, в нау и со второго курса при мне были, и даже один школьник, лол. Вряд ли с тех пор политика как то радикально изменилась. Ну и в контур можно попробовать вкатится, они любят свежее мясо.
Можно. Но надо быть морально готовым, что ближайшие несколько лет пиздюки младше тебя будут твоим начальством.
Это копия, сохраненная 14 марта 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.