почитайте OWASP, посмотрИте как зайдёт

 

 

Вы уверены, что работодателя, к которому пытаешься пробиться, стоит называть тупым?

может это та самая "свобода слова"?

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

 

 

Хм, я столько информации из одного аккаунта не соберу:))) 

а это не из одного аккаунта

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

кто-то просто спамер, кто-то парсер интернет-ресурсов, кто-то проходитель собеседований

человек зарегистрировался сегодня, поставил женский пол и женское имя, выставил возраст молодой девушки, выбрал красиво звучащий женский ник, на аватарку поставил порно-звезду Кира Уинтерс (Kiera Winters)

и потом сделал коммент не относящийся к делу

вот и все признаки спамера

"важно не только количество, но и качество найденных ошибок"

вот что ответил работодатель. Не нужно находить 101 ошибку. Это какое-то тыканье, как Сергей выше указал

тем более сразу увидели что человек "поискал по интернету", нашел уже найденные другими баги, создал пункты в своем чек-листе которые именно эти баги и найдут

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

 

 

тем более когда задание найти максимальное количество ошибок и прислать отчет какой то

там же работодатель уже ответил, что это количество в действительности не так и важно. Так что не надо воспринимать задание буквально

 

 

Можете пояснить тогда, что необходимо и как в этом тестовом сделать? Так, чтобы было правильно, человеку без опыта работы не понятно что от него конкретно хотят

ну вот например если Вы пригнали машину в сервис на осмотр - что Вы ожидаете получить в качестве результата? Список-простыню в 101 недостаток, включая пятно на заднем сиденье и царапину на бампере? Типа они постарались и нашли "максимальное число недостатков"? А может под капот и забыли заглянуть пока записывали все эти пятна?

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

 

 

они всем отвечают по видимому одно и тоже не вдаваясь в подробности, возможно даже не читая отчеты

они смотрят, прислали ли им "отчет по тестированию"

а в основном видимо присылают просто список багов, такие поделки сразу в мусорку идут

не забывайте про "Забыли пароль?" :)

 

 

Тот же вопрос у меня, что то не понял.
Как снимать логи работы iOS приложения с Мака?
Я что то по гуглил и вроде нет особо решения... или не того нагуглил)

используйте Firebase Crashlytics и будет всем счастье

 

 

Ну так опыт асессора-тестировщика и не должен помогать настраивать плагины в мавене, на мой взгляд) Это же совсем разные вещи, разве нет?

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

всё должно запускаться без проблем

а вообще это хорошая идея кандидатов отсеивать

ну как бандосы "на фене" начинают разговаривать и сразу "палят" подсадного

и тут типа вопрос кандидату: "вот у нас тут билд зафейлился, а мы резилить хотим, что делать? черри-пикать коммиты? ревертить чейнджи? накатывать фиксы?"

и смотришь как тот выкрутится :)

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

 

 

И потеряете хорошего начинающего кандидата только из-за того, что он не знает терминов?)

это просто для оценки кандидата, чтобы определить "начинающий" он или "продолжающий"

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

да и тут не в терминах же смысл, а в понимании пайплайна

 

 

Но удивляет, что на HH.ru 70% претендентов на вакансию тестировщика именно такие переквалифицировавшиеся из официантов и менеджеров по туризму.

а тут нет ничего удивительного. Люди умеют считать деньги, видят что в АйТи высокие зарплаты и пытаются "войти в АйТи", часто через профессию тестировщика, так как вроде как считается что "низкий порог входа". Часто случается что человек даже никаких знаний по тестированию не имеет, идет на собеседования, получает тестовые задания, пытается решить эти задания с помощью "помощи зала" и "звонка другу" - ведь даже если человека возьмут на испытательный срок, то он уже получит зарплату за 3 месяца "нахаляву", то есть попытка уже окупилась. Но в более запущенных случаях при некомпетентном менеджменте (который встречается не так уж и редко) такой человек может задерживаться в компании годами, просто тыкая кнопки в аппликации и время от времени регистрируя баги типа "битый линк", попутно создавая кипы тест-кейсов (ручной шлак, а если есть начальные знания в программировании - то автоматизированный шлак)

может и не стоит "входить" если проблемы с характером

ведь работа тестировщиком - в основном это именно работа с людьми, а не с компьютерами

то есть в итоге шило на мыло и поменяете, так как главную проблему не решили

может надо попробовать характер чинить, посещайте психологические курсы, читайте там Карнеги, Транссерфинг или там что угодно

 

 

Т.е. я сейчас не настоящий? :-) На какой язык вы предлагаете подаваться?

я думаю программисты 1С понемногу должны догадываться кто они на самом деле ;)

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

 

 

Я не просто так спрашиваю. Тоже думала над этим. Если брать какие то другие серьезные языки (1С это вообще больше среда для разработки), то чтобы начать что то зарабатывать нужно действительно очень много времени. Боюсь ошибиться в прогнозах, но наверное года 2. И еще я реально себя оцениваю, я думаю супер программистом я вряд ли стану. Лучше в том, что попроще становиться профессионалом, чем будет еще один программист, например С++, среднего уровня. Ни удовольствия ни денег.

тогда можно и в тестировщики, а знания/скиллы 1С-ника пригодятся

 

 

В 1с не платят? 

в 1С всегда наверное будешь на уровне каких-то местных предприятий

никогда не будешь работать с настоящими продуктами, в компаниях мирового уровня

 

 

Торговля людьми получается какая то :-) Но со мной побыстрее получится, я уже работаю программистом 1С.

а почему-бы тогда в настоящие программисты не податься?

 

Ок, предположим, что мы идём к чувакам из ISTQB, кладём их всех на пол и начинаем их судить:

 

— Вы утверждаете, что начинать тестирование надо начинать именно с написания тест-плана и тест-кейсов, а потом конечно, гоу-гоу на выполнение этих тест-кейсов.

 

— Ну, здравый смысл же… Сперва вымой руки, затем садись за стол…

 

— Но ведь всё поменялось! Теперь ведь:

(1) вместо тест-планов есть спринт-рефайнмент,

(2) вместо тест-кейсов — чек-листы и исследовательское тестирование,

(3) вместо ручной регрессии — автоматизированные тесты.

(4) Тест-менеджеров и тех практически не осталось! Пора уже принять современные реалии.

 

И вот здесь я не согласен. Ничего не поменялось. Спринт-рефайнмент что, отменяет тестирование? Исследовательское тестирование что, отрицает тест-кейсы? Автоматизация что, решает проблему регресса? Автоматизация, кстати, чего именно?  Функциональных тестов? Юнит тестов? Аджайл что, отменяет/заменяет установки "традиционной модели" (она же "водопадная", она же Соня Канцельбоген, воровка на доверии и особа, приближённая к императору)?

 

И если ответы будут «Да!», то мне сейчас, глядя на лежащих на полу чуваков из ISTQB, придётся признать, что мой собрат не понимает того, чем он занимается, и несёт в эфир белиберду белиберденьскую, бо его, походу, укусил какой-то дурак с неправильным аджайлом. Придётся извиняться перед этими чуваками.

 

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

 

Понятно ли я говорю?

очевидно что пост номер 7 вверху так и не прочитали:

https://software-tes...khomu/?p=174614

эджайл от водопада между прочим сильно отличается. По водопаду мы получаем софт на тестирование, составляем тест-план и начинаем писать тест-кейсы, тестируем только после того как написали кейсы. Всё в порядке водопада

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

 

 

ISTQB вообще не учит, с чего начинать тестирование.

по факту учит, указывает что надо делать обязательно, представляя "Фундаментальный процесс тестирования"

что это вот именно те шаги которые надо произвести чтобы сделать "правильное тестирование", что вот именно надо "сначала планируем, потом создаём кейсы, потом запускаем их"

 

Почитайте силлабусы для Advanced.

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

ну открыл например Адвансд Техникал Аналист, то же самое что и в фаундейшн:

пункт "1.5.2 Creation of Test Cases"

то есть тот же самый "фундаментальный процесс" и в продвинутых сертификатах

 

 

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

тут даже не про уровень формальности. Для примера: в эджайле можно и нужно начинать тестирование как можно раньше, чтобы дать фидбэк, а по "фундаментальному процессу" надо сначала писать тест-кейсы и только потом начинать тестирование

почитал их сайты и разобрался что к чему:

https://www.rstqb.or...tification.html

вот он, путь сертификации: 

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

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

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

вот и проблема: 

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

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

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

Этот сертификат "Тестирование в гибких методологиях" по факту должен быть объединён с "Сертифицированный тестировщик" и быть одним входным сертификатом

 

 

https://www.youtube....h?v=DvMh4_ak6r4

ну и к чему тут троллинг?

 

Мы прожили без тест кейсов и без планирования тестирования 6 месяцев в следствии реорганизации команды и компании в целом. В результате я месяц разгребаю, описываю и систематизирую новый функционал, перерабатывая в будни и по выходным периодически. И конца и края этому не видно. А всё потому что тест кейсы не делались на функционал который был не приоритетный, а потом он неожиданно стал приоритетный. И оказалось что там миллиард багов, а новые разработчики вообще не понимают, как что работает. Как по мне, да же если у нас аджайл, и что иногда нам нужно например:

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

1. Может наступить момент, когда тебе понадобятся тест кейсы, потому что спустя пол года ты уже мог забыть как тестировать и где узкие места того или иного функционала, который не трогали всё это время. 

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

3. Человеческий фактор никто не отменял. Я давеча проводя "исследовательское" тестирование, после двух недель переработок пропустил на прод абсолютно банальный баг с неправильным суммированием в столбце "итого". Просто не заметил/забыл посмотреть/хз что ещё..и всё. При тестировании расчетов верить нельзя да же самому себе. 

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

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

 

 

"завтра выкатываем, забей на регресс"

надо выкатывать, авто-тесты должны обеспечить приемлемый уровень качества

 

 

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

ну и кто будет платить за создание и поддержку этой "документации по тестированию" которой будут редко пользоваться, то есть отдача маленькая?

 

 

1. Может наступить момент, когда тебе понадобятся тест кейсы, потому что спустя пол года ты уже мог забыть как тестировать и где узкие места того или иного функционала, который не трогали всё это время. 

можно всегда почитать документацию по продукту, плюс можно код открыть

 

 

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

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

 

 

3. Человеческий фактор никто не отменял. Я давеча проводя "исследовательское" тестирование, после двух недель переработок пропустил на прод абсолютно банальный баг с неправильным суммированием в столбце "итого". Просто не заметил/забыл посмотреть/хз что ещё..и всё. При тестировании расчетов верить нельзя да же самому себе. 

тут вопрос - наверное кто-то не создал автоматический тест на то поле суммирования? эта проблема должна решаться автоматикой, а не людьми

 

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

наоборот не надо, зачем тратить деньги на создание документации которую выбросят в мусорку? эти деньги можно потратить на автоматизацию тестирования