А я это на собеседовании делала, только слегка по-другому выглядело, наверное обновилось с тех пор. В нервах забыла, как написать SQL-иньекцию :) Сейчас нашла сходу 14 (Upd: 15 :))

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

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

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

Нашла три бага (но, признаться, на третий случайно наступила)

Кстати кейс сумма 2 сторон треугольника равна третьей - это вырожденный треугольник :)

Можно поинтересоваться с целью повышения образованности (я не особо специалист по автоматизации) - а знать селениум, но не уметь программировать, - это как? О_о

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

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

 

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

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

Что за слово такое - колдунщик? Это на каком языке?

Тест-кейс №1. Появление колдунщика по запросу.

Шаги:

1. Открыть браузер.

2. В поисковой строке ввести "переводчик онлайн".

Результат: 

Отобразится колдунщик онлайн переводчика.

 

вы уверены, что это не тест поисковой системы ))

Есть ли какие-то проверки, специфичные для страниц на сабже?
Какие-то особенные иньекции, проверки для GUI и прочее, отличающиеся от "обычных" веб-страниц.

 

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

 

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

 

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

 

Как бы было бы здорово, если бы так было всегда :)) Нету белого экрана - значит, все правильно работает! (ну, как минимум, сама страница :)) Но  такого не видела пока. Если ошибки в джс - то они просто в консоли, и все. 

в хром девтулс добавили вкладку React, можете попробовать

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

 

 

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

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

 

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

Очевидно, работают в каких-то других организациях

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

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

Мои извинения автору.

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

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

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

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

Это у вас тест знания гит или тест навыков тестирования? :)

http://prntscr.com/lapicv

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

Просто если этих id нет, тогда и приходят на помощь xpath и css

Just for my education, а что, можно, к примеру, в данном форуме добавить заранее известные айдишники элементам, которые содержат ссылку на профиль комментатора в теме? (скажем, мой ник в этом сообщении)?

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

а у xpath вот да, яркое преимущество, что можно искать внутри чего-то (".//div...") Если этого не надо, то css быстрее, вроде. Так считается )

А точно проблема ТС именно в большом количестве дубликатов? Если да, то новичка как раз очень полезно посадить разгребать баклог - и систему подучит, и заодно проверит, может быть, какие-то баги уже пофиксились indirectly и их можно закрыть. И примерно выучит, что там уже есть.

У нас пробовали внедрить практику: программист сделал таск по проекту - возьми починить один баг из баклога. Какое-то время работало.

Но вообще мы где-то раз в полгода просто берем и закрываем как Won't fix миноры, которые за эти полгода так и не пофиксили. Понятно, что до них руки вообще никогда не дойдут.

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

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

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

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

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

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

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

 

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

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

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

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

Эстимирование времени - формулы оценки на основе времени разработки (про 30% это, кстати, имхо цифра с потолка), на мой взгляд, не слишком полезны по следующим причинам:

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

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

3) реальное время может отличаться в зависимости от того, сколько багов нашлось, т.к. их локализация и заведение тоже занимает время. На одном моем проекте требовалось приложить к багу комплект минимум из 4 серверных логов + скриншоты с UI, а иногда из 8 или 12, а для их получения каждый раз требовалось воспроизводить баг. Каждый баг - минут 10-15, 4-6 багов - лишний час.

На мой взгляд ответ, близкий к верному, скорее будет таким: для оценки времени нужно иметь наборы тестов, разбитые по функциональным областям системы (это не то же самое, что страницы! Допустим, этот форум. Будут примерные области: регистрация, логин, написание сообщения, создание темы, поиск... ). По результатам обсуждения фичи на планировании, когда разработчики уже примерно знают, как это будет разрабатываться, мы будем примерно знать области, которые нужно будет перетестировать, а стало быть, и затраты (в тест-трекинговых системах, как правило, сохранется время прогона тестов). Плюс добавить время на написание и прогон новых тестов, переписку старых, если нужно (это можно прикинуть по затронутому функционалу + предыдущему опыту).

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

Как-то так.

5 вопрос - не поняла его смысла. Можно или нужно? О_о Нужно - в зависимости от требований заказчика. Если поддерживаем мобильные браузеры/планшеты, то тестируем. Если нет - то нет. Можно - кто ж запрещает? Или можно - в смысле вместо десктопных?

Может этот вопрос в каком-то контексте был?