Обычно рекомендуется выбирать положительные проверки + наиболее вероятные сценарии использования. И еще их не должно быть много.

Скорее всего у Вас больше шансов попасть в небольшую студию (человек 10-25) которые штампуют интернет магазины и не сложные бизнес решения заказчиков. Вы там будете либо один или возможно двое/трое(что для Вас плюс) "в помощь" ПМ-у. Будете заниматься тестированием верстки, ну и когда все это дело натянут на систему управлением сайта перейдете к тесту функционала. Остальное все позже и по мере поступления изучите. 
 

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

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

а вы работали в таких компаниях?

А вы на собеседование сходите с зарплатой примерно вдвое больше, чем у вас сейчас, и сразу поймете, куда расти :)

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

 

Замечание про 1 час означает, что вам надо сделать самые важные проверки, потому что, как пишет тот же Савин, проверить вообще все невозможно.

И расставлять по приоритету, на мой взгляд, нужно не тестируемые элементы (ваши разные кнопки), а сами проверки. Т.е. в условиях ограниченного времени есть смысл проверить, что каждая кнопка выполняет свою функцию, что файлы редактора сохраняются и открываются, а, скажем, то, что кнопки правильно отображаются под Windows 98 (или в Internet Explorer 7) - этой проверкой в условиях ограниченного времени можно пренебречь.

Уважаемые редакторы, вас в этом переводе ничего не смущает? Наверное, случайно выложили черновик.

 

Возможно, Вам не нужно знать о тестировании Web-безопасности, если…

.....
 

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

 

А вы в аналитики не хотите? С таким бэкграундом у вас веселей пойдет, и, вроде, направление перспективное. Сама бы пошла да старовата уже

Если время и силы есть, а денег нет, то подойдет еще это, наверное. Не вместо, а вместе. Как чисто практическое пособие. Бесплатная. https://svyatoslav.b...e_testing_book/

Любопытно хоть один юзкейс с Канвой увидеть О_о

-- Не буду. Злой я сегодня ---

Прошу извинить за нескромный вопрос и отклонение от темы, а когда вы добрый?

Т.е. беда в том, что медленно продвигается написание автотестов, а не тестирование фич, как я понимаю.

Взялись - делайте, он же и спрашивает, как сделать. Правда, я ничегошеньки не понимаю, что именно у автора не получается :)

Вы имеете в виду, что у вас медленно идет процесс автоматизации? Или вы не отдаете фичу в релиз, пока не напишете для нее автотесты? )

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

Cпасибо большое. Обязательно пройдусь по кейсам, которые вы описали. 

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

 

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

Процесс инсталяции не забудьте проверить, если это входит в задание или сборку 

Специфически для приложений с голосовой функцией проверяют распознавание, работу в шумном месте, работу при слабом сигнале интернета, очень короткие и очень длинные слова (или фразы), длинные может обрывать, а короткие не ловить. Омографы (зАмок - castle, замОк - lock, conflIct - глагол, cOnflict - существительное, made a bow - сделал лук или поклонился в зависимости от боу или бау), перевод с учетом контекста (can - могу или банка).

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

Дальше разделите слона на части (например : интерфейс, распознавание, перевод), эти части на еще более мелкие, пишите тестовую документацию и тестируйте. как-то так.

(но вообще, конечно, поведение ваших руководителей вызывает некоторые вопросы, если, конечно, это не тестовое задание).

https://fullstory.com/ может попробуйте. Записывает видео - что пользователь видит / делает на сайте. Сервис платный, цена зависит от требуемого количества видео в месяц (т.е. допустим заплатили за 100, он за первые 3 дня месяца записал 100 и все, до начала следующего не пишет). Не знаю, правда, скринит ли платежные данные, если нет, то у вас есть риск иметь некрасивый вид.

наверное на зоне и в разработке софта разные качества ценятся

 

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

 

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

Эх, если бы еще в разработке не было всяких дерзких, как вы говорите :)

Ценности будущего - 3К: коммуникация, креативность, критическое мышление. У нас пока наблюдаю 3Г: не верь, не бойся, не проси.

у джуниоров конкуренция огромная, у нас по крайней мере (Беларусь), слышала в России то же самое.

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

https://www.guru99.c...h-selenium.html

я не поняла, где вы его редактируете - в разметке или в тесте или в консоли? возможно, после взаимодействия со страницей ее структура меняется и появляется еще один див (что-то становится жирным или в фокусе или еще че-нить).

Но при этом неплохо иногда сделать тест-тур с использованием популярных адблокеров и пассворд-менеджеров (тех, которые сами логгируют вас). Это довольно популярные инструменты, а баги могут быть огого.

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

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

ИЗ того что вы не упомянули, желателен еще английский хоть в каком-нибудь виде, особенно если вы в СНГ.

Если мне память не изменяет, мы эту свзяку настраивали вот так

https://dontpaniclab...ation-teamcity/

вот прям как там напиано (правда это было в прошлом году и с тех пор интерфейс ТС малость обновился, но думаю особых проблем у вас не будет)

там и запись видео можно организовать с помощью ТС (например через ffmpeg) и вот это https://www.tightvnc.com/

так - а репортер вы же поставили? какой-нибудь https://www.npmjs.co...smine-reporters ?

Настройки там аналогичные. Просто пропустите раздел Getting started with Teststack и сразу переходите к созданию билд-агента. Указываете там УРЛ вашего тестового окружения (если их несколько, можно этот параметр вынести в конфиг), создаете пользователя, который будет всегда залогинен, и погнали дальше :)

Если у вас что-то конкретное не получится, пишите попробуем разобраться

 

 

Да, такое бывает.
Это возможно, хоть и непросто.

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

 

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

 

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

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

Или там джун тестирует и ему легче дополнять эти документы, чем писать с нуля.

(целесообразность такого подхода - другой вопрос, конечно).

Да, такое бывает.
Это возможно, хоть и непросто.

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

Вопрос совершенно теоретический, заинтересовал по результатам спора с коллегами. Допустим, вы работаете в аутсорсе или там фрилансите, и вам падает задание: написать исчерпывающие чек-листы/тест-кейсы/тест-план для какого-либо проекта, а тестировать по этому добру будут потом совсем другие люди. Бывает ли такое? И возможно ли вообще - в смысле, возможно ли сделать подобную работу именно качественно/исчерпывающе?

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

 

Иногда можно просто написать список ошибок, которые допустят программисты когда будут писать код. Список будет сильно неполный, но тем не менее.

Неполный? Тогда это несложно - надо просто взять предполагаемую технологию и погуглить ее, прибавив слова top 10 mistakes :))