А я это на собеседовании делала, только слегка по-другому выглядело, наверное обновилось с тех пор. В нервах забыла, как написать SQL-иньекцию :) Сейчас нашла сходу 14 (Upd: 15 :))
- Форум тестировщиков
- → Публикации MissLeman
106 публикаций создано MissLeman (учитываются публикации только с 24 сентября 2023)
Отправлено автор: MissLeman 26 сентября 2018 - 10:06 в Свободное общение
А я это на собеседовании делала, только слегка по-другому выглядело, наверное обновилось с тех пор. В нервах забыла, как написать SQL-иньекцию :) Сейчас нашла сходу 14 (Upd: 15 :))
Отправлено автор: MissLeman 06 декабря 2018 - 11:48 в Автоматизированное тестирование
у вас не локатор, а ужас летящий на крыльях ночи, напишите нормальный (используйте классы, другие атрибуты и еще что-нибудь).
https://www.guru99.c...h-selenium.html
я не поняла, где вы его редактируете - в разметке или в тесте или в консоли? возможно, после взаимодействия со страницей ее структура меняется и появляется еще один див (что-то становится жирным или в фокусе или еще че-нить).
Отправлено автор: MissLeman 28 июня 2019 - 14:45 в Тест-дизайн и ручное тестирование
Нашла три бага (но, признаться, на третий случайно наступила)
Кстати кейс сумма 2 сторон треугольника равна третьей - это вырожденный треугольник :)
Отправлено автор: MissLeman 29 января 2019 - 12:41 в Личный рост, карьера, развитие
Можно поинтересоваться с целью повышения образованности (я не особо специалист по автоматизации) - а знать селениум, но не уметь программировать, - это как? О_о
Ну, допустим, клики-открытия страниц-ожидания - ок, они селениум (ну или фреймворк). Но ведь кроме этого, в тестах еще целая куча разной логики.
Отправлено автор: MissLeman 31 октября 2018 - 06:22 в Тест-дизайн и ручное тестирование
И главное, глядя на эти кнопки нельзя однозначно сказать что какая - то из них важнее или используется чаще других. Они равноправны и одинаково важны. Это как если бы у меня был графический редактор, который умел вращать, увеличивать и отражать фигуры.
Замечание про 1 час означает, что вам надо сделать самые важные проверки, потому что, как пишет тот же Савин, проверить вообще все невозможно.
И расставлять по приоритету, на мой взгляд, нужно не тестируемые элементы (ваши разные кнопки), а сами проверки. Т.е. в условиях ограниченного времени есть смысл проверить, что каждая кнопка выполняет свою функцию, что файлы редактора сохраняются и открываются, а, скажем, то, что кнопки правильно отображаются под Windows 98 (или в Internet Explorer 7) - этой проверкой в условиях ограниченного времени можно пренебречь.
Отправлено автор: MissLeman 24 августа 2018 - 12:28 в Начинающему тестировщику
Что за слово такое - колдунщик? Это на каком языке?
Тест-кейс №1. Появление колдунщика по запросу.Шаги:1. Открыть браузер.2. В поисковой строке ввести "переводчик онлайн".Результат:Отобразится колдунщик онлайн переводчика.
вы уверены, что это не тест поисковой системы ))
Отправлено автор: MissLeman 05 декабря 2018 - 13:10 в Тест-дизайн и ручное тестирование
Есть ли какие-то проверки, специфичные для страниц на сабже?
Какие-то особенные иньекции, проверки для GUI и прочее, отличающиеся от "обычных" веб-страниц.
Отправлено автор: MissLeman 05 декабря 2018 - 15:40 в Тест-дизайн и ручное тестирование
У реакт-приложений я видел поведение, которое не характерно для других веб-приложений, из-за одной ошибки, фронт нафиг падает. То есть, например нажал кнопку или там другой элемент забагованный и всё.
да, это правда, случается постоянно - выпадает просто в белый экран с джаваскрипт ошибками в консоли. даже если просто ошибка в джаваскрипте при загрузке страницы
иногда даже бэкенд ответит неправильно, например с нулл - и фронт падает
Как бы было бы здорово, если бы так было всегда :)) Нету белого экрана - значит, все правильно работает! (ну, как минимум, сама страница :)) Но такого не видела пока. Если ошибки в джс - то они просто в консоли, и все.
в хром девтулс добавили вкладку React, можете попробовать
Это же экстеншн, вроде?
А как именно его можно полезно использовать? (вариант тестировать и смотреть в консольку на предмет ошибок - понятно :))
Отправлено автор: MissLeman 11 июля 2018 - 07:45 в Про тестирование обо всём подряд
Да, был. Приложение огромное, логика - разная. Есть требования к некоторому модулю, и тест-кейсы пишутся по частям, для каждого модуля, одним тестировщиком, а выполняет их другой тестировщик. Но в данном случае оба человека систему знали достаточно хорошо.
Интересно, а у вас был такой опыт? Если не секрет, сколько времени заняло, большое ли было приложение? Надеюсь не слишком любопытна, но это для меня в какой-то степени крышеснос )Да, такое бывает.
Это возможно, хоть и непросто.
Это немного разные вещи. Пишут кейсы и тестируют на одном проекте разные люди - это, насколько я знаю, довольно распространенная практика, у нас тоже так было одно время. А я говорю именно о сложности для постороннего человека вникнуть в проект - и быстро - чтобы написать действительно качественную документацию.
Если предположить, что нанимают его, как верно заметили выше, не с целью попилить бюджет, а для того, чтобы потом вообще без тестировщика обходиться, а просто любой свободный член команды берет и по этому документу тестирует.
Или там джун тестирует и ему легче дополнять эти документы, чем писать с нуля.
(целесообразность такого подхода - другой вопрос, конечно).
Отправлено автор: MissLeman 10 июля 2018 - 16:10 в Про тестирование обо всём подряд
Да, такое бывает.
Это возможно, хоть и непросто.
Интересно, а у вас был такой опыт? Если не секрет, сколько времени заняло, большое ли было приложение? Надеюсь не слишком любопытна, но это для меня в какой-то степени крышеснос )
Отправлено автор: MissLeman 10 июля 2018 - 16:12 в Про тестирование обо всём подряд
Иногда можно просто написать список ошибок, которые допустят программисты когда будут писать код. Список будет сильно неполный, но тем не менее.
Неполный? Тогда это несложно - надо просто взять предполагаемую технологию и погуглить ее, прибавив слова top 10 mistakes :))
Отправлено автор: MissLeman 10 июля 2018 - 13:52 в Про тестирование обо всём подряд
Вопрос совершенно теоретический, заинтересовал по результатам спора с коллегами. Допустим, вы работаете в аутсорсе или там фрилансите, и вам падает задание: написать исчерпывающие чек-листы/тест-кейсы/тест-план для какого-либо проекта, а тестировать по этому добру будут потом совсем другие люди. Бывает ли такое? И возможно ли вообще - в смысле, возможно ли сделать подобную работу именно качественно/исчерпывающе?
Понятно, что для какого-нибудь типичного интернет-магазина, наверное, да, но если это достаточно сложный (пусть и небольшой) сервис с небанальной бизнес-логикой?
Отправлено автор: MissLeman 24 мая 2019 - 14:58 в Личный рост, карьера, развитие
Если вы все это не просто прочитали, а как следует поняли и проработали, то пишите уже резюме и устраивайтесь.
Тут кстати на форуме в этом разделе вроде было обсуждение про резюме (там чел писал, что рассылает, но на собеседования не зовут), и там советовали как писать. Если актуально.
ИЗ того что вы не упомянули, желателен еще английский хоть в каком-нибудь виде, особенно если вы в СНГ.
Отправлено автор: MissLeman 14 июля 2018 - 16:38 в Тест-дизайн и ручное тестирование
Я имею ввиду те вузы, где учат в первую очередь Инженеров). Имени какого там не знаю кого, не рассматриваю, все мимо, всегда. Ни одного из бауманки, куда они деваются, хз, жаль(
Очевидно, работают в каких-то других организациях
Отправлено автор: MissLeman 07 августа 2018 - 14:14 в Личный рост, карьера, развитие
Автору я бы рекомендовала подтянуть русский язык. Между прочим, важный навык для тестировщика, хотя бы потому, что орфографические и грамматические ошибки в интерфейсе приложения - тоже баги.
Если интересна безопасность, то уже можно браться вот за этот любимый мной списочек, ну или вот это для начала что да как.
Отправлено автор: MissLeman 07 августа 2018 - 14:44 в Личный рост, карьера, развитие
Мои извинения автору.
Отправлено автор: MissLeman 05 ноября 2018 - 11:23 в Начинающему тестировщику
Скорее всего у Вас больше шансов попасть в небольшую студию (человек 10-25) которые штампуют интернет магазины и не сложные бизнес решения заказчиков. Вы там будете либо один или возможно двое/трое(что для Вас плюс) "в помощь" ПМ-у. Будете заниматься тестированием верстки, ну и когда все это дело натянут на систему управлением сайта перейдете к тесту функционала. Остальное все позже и по мере поступления изучите.
на такого рода работу, насколько я знаю, обычно стажеров берут, т.е. работать за опыт, без оплаты. по крайней мере, так было на проектах, которые у нас отдавали на аутсорс + коллеги с той стороны рассказывали.
я ради интереса погуглила работу во флориде, чет не попалось мне вакансий без опыта.
а вы работали в таких компаниях?
Отправлено автор: MissLeman 26 октября 2018 - 11:10 в Инструменты и технологии
Отправлено автор: MissLeman 07 сентября 2018 - 14:22 в Selenium - Functional Testing
Это надо как-то разработчиков фронта трестируемой системы заставить id элементам лепить, с которыми может взаимодействовать пользователь.
Просто если этих id нет, тогда и приходят на помощь xpath и css
Just for my education, а что, можно, к примеру, в данном форуме добавить заранее известные айдишники элементам, которые содержат ссылку на профиль комментатора в теме? (скажем, мой ник в этом сообщении)?
Отправлено автор: MissLeman 08 сентября 2018 - 15:55 в Selenium - Functional Testing
кстате протрактор например свои локаторы имеет: по модели и биндингу. правда, они помогут лишь в том случае, если протрактор юзается строго по назначению ))
а у xpath вот да, яркое преимущество, что можно искать внутри чего-то (".//div...") Если этого не надо, то css быстрее, вроде. Так считается )
Отправлено автор: MissLeman 03 мая 2019 - 08:44 в Свободное общение
А точно проблема ТС именно в большом количестве дубликатов? Если да, то новичка как раз очень полезно посадить разгребать баклог - и систему подучит, и заодно проверит, может быть, какие-то баги уже пофиксились indirectly и их можно закрыть. И примерно выучит, что там уже есть.
У нас пробовали внедрить практику: программист сделал таск по проекту - возьми починить один баг из баклога. Какое-то время работало.
Но вообще мы где-то раз в полгода просто берем и закрываем как Won't fix миноры, которые за эти полгода так и не пофиксили. Понятно, что до них руки вообще никогда не дойдут.
Я их иногда выкапываю и подкидываю программистам, если они что-то разрабатывают "рядышком": посмотри, мол, может заодно вот это поправишь.
Отправлено автор: MissLeman 11 декабря 2018 - 09:36 в Тест-дизайн и ручное тестирование
Специфически для приложений с голосовой функцией проверяют распознавание, работу в шумном месте, работу при слабом сигнале интернета, очень короткие и очень длинные слова (или фразы), длинные может обрывать, а короткие не ловить. Омографы (зАмок - castle, замОк - lock, conflIct - глагол, cOnflict - существительное, made a bow - сделал лук или поклонился в зависимости от боу или бау), перевод с учетом контекста (can - могу или банка).
Еще, кстати, важно выяснить, использует ли приложение какие-то внешние части, например, если "ваша" часть - только распознавание, а перевод происходит с помощью какого-нибудь Google Translate или еще чего-то, то тонкости перевода тестировать не надо.
Дальше разделите слона на части (например : интерфейс, распознавание, перевод), эти части на еще более мелкие, пишите тестовую документацию и тестируйте. как-то так.
(но вообще, конечно, поведение ваших руководителей вызывает некоторые вопросы, если, конечно, это не тестовое задание).
Отправлено автор: MissLeman 11 декабря 2018 - 10:26 в Тест-дизайн и ручное тестирование
Cпасибо большое. Обязательно пройдусь по кейсам, которые вы описали.
Увы, но я работаю в одной из отсуорсинговых белорусских компаний (название не могу скать)
:)) После этой информации догадаться не сложно. То есть это тестовое задание на окончание испыта / повышение левела? В тех компаниях, про которые я думаю, вроде не принято полных новичков сразу в бой выпихивать, обычно как минимум опытный менеджер есть. Но, впрочем, дело ваше.
Процесс инсталяции не забудьте проверить, если это входит в задание или сборку
Отправлено автор: MissLeman 13 ноября 2018 - 09:30 в Начинающему тестировщику
Если время и силы есть, а денег нет, то подойдет еще это, наверное. Не вместо, а вместе. Как чисто практическое пособие. Бесплатная. https://svyatoslav.b...e_testing_book/
Отправлено автор: MissLeman 05 ноября 2018 - 09:59 в Начинающему тестировщику
По-моему, вы гораздо быстрее найдете ответы в гугле. Большинство - простые и однозначные определения. Ничего особенно сложного в определении DOM или чек-листа нет.
Эстимирование времени - формулы оценки на основе времени разработки (про 30% это, кстати, имхо цифра с потолка), на мой взгляд, не слишком полезны по следующим причинам:
1) нередко надо оценить время на тесты еще до начала спринта, т.е. еще до начала разработки, и вы опираетесь не на фактическое время разработки, а на эстимейт разрабов, точно так же вилами по воде написанный.
2) реальная зависимость может быть очень разной. Может быть - намного меньше времени разработки, и намного больше (разработчик поменял две строки фронтенда, а тестировщикам пришлось перетестировать все приложение в четырех разных браузерах).
3) реальное время может отличаться в зависимости от того, сколько багов нашлось, т.к. их локализация и заведение тоже занимает время. На одном моем проекте требовалось приложить к багу комплект минимум из 4 серверных логов + скриншоты с UI, а иногда из 8 или 12, а для их получения каждый раз требовалось воспроизводить баг. Каждый баг - минут 10-15, 4-6 багов - лишний час.
На мой взгляд ответ, близкий к верному, скорее будет таким: для оценки времени нужно иметь наборы тестов, разбитые по функциональным областям системы (это не то же самое, что страницы! Допустим, этот форум. Будут примерные области: регистрация, логин, написание сообщения, создание темы, поиск... ). По результатам обсуждения фичи на планировании, когда разработчики уже примерно знают, как это будет разрабатываться, мы будем примерно знать области, которые нужно будет перетестировать, а стало быть, и затраты (в тест-трекинговых системах, как правило, сохранется время прогона тестов). Плюс добавить время на написание и прогон новых тестов, переписку старых, если нужно (это можно прикинуть по затронутому функционалу + предыдущему опыту).
Плюс еще, в зависимости от конкретного проекта, где-то в обязанности тестировщиков входит поддержание спеки, где-то требуется обязательное написание "официальной" тестовой документации - отчеты или тест-план для заказчика, где-то автотесты дописывать придется.
Как-то так.
5 вопрос - не поняла его смысла. Можно или нужно? О_о Нужно - в зависимости от требований заказчика. Если поддерживаем мобильные браузеры/планшеты, то тестируем. Если нет - то нет. Можно - кто ж запрещает? Или можно - в смысле вместо десктопных?
Может этот вопрос в каком-то контексте был?
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru