Для начинающего тестировщика, возможно будет полезно.

Ожидал, что в конце статьи будет описан подход автора, но увы. =(

 

 

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

^{Надеюсь, те кто будут читать статью, не будут слепо следовать такому совету.}

^{Здесь не указан немаловажный фактор, как популярность устройства.} 

^{Так же при попытке определить схожесть устройства по общим параметрам, нужно обязательно учитывать "железо" деваса.}

^{Приведу пример.}

^{На проекте используется технология WebGL.(да, это сайт, но дочитайте до конца, пожалуйста)}

^{Есть 2 девайса на тестирование: samsung S3 и S4.}

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

^{Если проигнорировать, как мне предлагали менеджеры проекта: "Да чего ты паришься, оба одной фирмы. Да проверь на последнем(S4) и все".}

^{Но тут самое интересное.}

^{GPU на S3 Mali-400 MP. Как выяснилось в процессе тестирования, его драйвер имеет проблемы при работе с WEbGL(он просто блочит WebGL).}

^{К сожалению ссылку которую нашел прошлым летом не могу найти, думаю многие догадаются почему =)}

^{Но если погуглить, то можно найти тому не один апрув.}

^{Так что, если выкидываете девайс из списка тестов, хорошо подумайте.}

P.S. этот gpu установлен на многих девайсах.

Спасибо, полезная статья.

 

Основная идея: мы оба оказывались в офисе с утра. Тишина, покой, располагающая к работе атмосфера. Я ставил музыку и приступал к тестированию последних изменений, внесенных в сборку предыдущей ночью. Разработчик спрашивал, есть ли у меня минутка. Минутка всегда находилась, и закладывала фундамент доверия. Я перемещался за его стол и просил показать, что делает новая функция, делал простые заметки (например, о кнопке, которую можно было бы переместить, или об отсутствующей метке), а затем мы переходили к делу.

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

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

Был подобный случай.

Результат такого подхода был следующим:

- Изменение отношения разработчика к тебе(тестировщику) в лучшую сторону. Так как ты не просто "пылесос багов", как зачастую тебя воспринимают, а как человек который заинтересован в качестве проекта.

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

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

- Приходит к тебе(тестировщику) понимание того, что разработчик не будет действовать по принципу: "И так сойдет".

- Зачастую такие проекты гораздо качественне.

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

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

P.S. Да, звучит как утопия. Если кто был в такой ситуации - поймет. 

P.P.S С одним из таких разработчиков дружим семьями 

Добрый день. 

Все везде не протестируешь. 

1. Определите топ 5 актуальных разрешений.

2. Обычно проверяю на последних версиях браузеров, но если время позволяет то и промежуточные просматриваю.

3. На основе первых двух пунктов закрепляем за каждым браузером определенное разрешение.

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

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

На вскидку могу сказать только несколько:

- смещение позиционирования элементов 

- не применяются стили к некоторым элементам

- горизонтальный скролл(это как тревожный сигнал для первых двух пунктов)

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

- Использование разрабами библиотеки WebGL(актуально для тестирования сайтов на мобилках с граф процессом Mali, так как в драйвере граф процессора Mali есть баг)

- Могут не работать некоторые части или вообще отваливается JS

появилась необходимость проверить написание и отправку сообщений, команда type отпадает сразу, т.к. форма не input . гугл в решении проблемы пока не помог =(

http://i6.5cm.ru/i/0vXv.png

 

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

Чтобы проверить такой ли текст у нас в нужном поле можно примерно так

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

2. В локатор передаем переменную с текстом, который нужно найти.

String text="Тут ваш текст";
driver.findElement(By.xpath("//*[@class='cTalksInput']//*[contains(text(),'+ text + ')));

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

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

 

Приветствую!

На сей раз у меня возникла проблема с написанием теста для проверки регистрации и восстановлением пароля.

Для регистрации использую сервис одноразовой почты dropmail.me

Реализовано:

1. Заходим, забираем почтовый ящик

2. Открываем новую вкладку, переходим на целевой сайт

3. Регистрируемся 

4. Разлогиниваемся и "забываем пароль"

 

Не реализовано:

3.1 Добавить проверку, что регистрация прошла успешно

5. Переключаемся на почту, находим письмо.В высланном письме есть:

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

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

6. Залогиниться с новым паролем

7. Проверить, залогинился ли

 

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

 

PS: может посоветуете сервис одноразовой почты поприветливее интерфейсом, чтобы письма без задержек приходили (mail temp сначала нормально присылал, потом стал с задержкой в 1+ час)

 

1. Откажитесь от использования сторонних сервисов, того же почтового ящика.

Можно выдергивать данные прямо из бд.

2. Проверка того что пользователь зарегистрирован, можно тоже через бд. Там может стоять флаг и запись в таблице users

3. Ссылку на подтверждение тоже можно "дернуть" из бд

4. Проверка залогинен или нет может быть тот же аватар или ссылка на личный кабинет, в зависимости от логики.

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

Затем автоматизируйте их.

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

Набор тест-кейсов я уже предоставила, начальство попросило сделать другое. 

Я думала разбить сайт на смысловые модули и по ним описать их функционал (что там делается). Так можно делать? И как это примерно оформлять?

Это уже декомпозиция функциональных частей продукта.

Смысловые модули можно сделать так:

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

К примеру:

Логический блок авторизация пользователя

1. Вводим логин и пароль

2. Жмем Submit

3. Проверяем что пользователь залогинен( доступны переходы в личный кабинет/профиль/корзину)

Пример абстрактный, но является законченной логической цепочкой.

Для справки, вот что такое  тест-план .

То что вы описали это набор тестовых сценариев. 

Описание функциональности модулей - это больше похоже на ФТ.

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

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

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

Автоматизация - это прежде всего инструмент, а не панацея.

Здравствуйте.

Постарайтесь как можно меньше запихивать логики в тесты.

Разбейте просто на 2 теста

1. вводит верное значение, проверка к нему , что кнопка появилась

2. вводит неверное значение, проверка к нему, что отобразилось сообщение об ошибке.

Добрый день, для этого элемента правильный xpath локатор такой 

"//*[@class='js-add-kit'])[3]"

Сам проверял, работает.

я создаю такие баги.

Создавать баги это круто 

Попробуйте прописать клик по лейблу чекбокса.

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

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

driver.findElement(By.xpath("//button[1]")).clear();

Может тут должен быть "click()", а не "clear()" раз это кнопка

Коллеги, здравствуйте. 

 

У меня вопрос следующего характера.

 

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

 

Нужен ли вообще для такой узкой задачи мастер тест план? Я в этом не увидел необходимости

 

Заранее спасибо за Ваше экспертное мнение.

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

Задача поставлена весьма странно. И если честно, то  никогда не видел таких задач на проекте.

На текущий момент наблюдаю применение kpi на  разработчиках.

Выглядит это весьма плачевно, так как далеко не всегда можно оценить эффективность, потому, что:

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

- бывают случаи неправильно поставленного времени на задачу

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

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

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

К чему были приведены эти пункты?

Да к тому, что если в такие ситуации попадает разработчик, то перед ним 2 выхода:

- работать за бесплатно

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

В первом случае это обидно разработчику. Во втором -  страдает качество проекта.

В результате мы имеем такую ситуацию:

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

И когда такое "чудо" попадает в руки тестировщика, то зачастую(личный опыт) это просто ужас.

И первой мыслью бывает: "А не втащить разрабу промеж глаз?"

Но если поразмыслить, то он не виноват, что его загнали в рамки метрики.

Те кто задаются вопросом оценки эффективности тестировщиков, задумайтесь:

"Вы действительно хотите попробовать этот хаос на себе?"

ИМХО kpi может быть полезен, исключительно как второстепенный/вспомогательный инструмент.

P.S. Все выше приведенные аргументы основаны исключительно на наблюдении.

Удаленной возможности сертификации не предусмотрено?

Есть весьма хорошая книга про "узкие звенья" в процессах.

"Элияху Голдратт Цель - непрерывное совершенствование"

Бывают. Это в характере людей воспринимать указание на их ошибки "в штыки". Тут ничего не поделаешь.

Разруливать подобные вещи я пытаюсь через объяснение и взгляд третьей стороны. Призвать начальника - это сильно)

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

А бывает и другое, начальник скажет: "Мы не в детском саду чтобы разжевывать задачи.

Узнавай сам"(были случаи)

Здравствуйте.

На текущий момент у меня подобная ситуация.

Решений есть 2.

1. Если человек умеет адекватно воспринимать конструктивную критику, то можно отойти с ним в переговорку / покурить или на кухню и побеседовать.

Разговор в духе: "Давай описывать подобные ситуации вот так и так, потому что нам(тестировщикам) с этими данными работать в такой форме гораздо удобнее

и быстрее, что позитивно скажется на весь процесс тестирования."

2. Если человек не понял/ не захотел понимать важность беседы, то тут уже поступать можно таким образом:

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

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

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

Второй вариант менее приятен так как это существенно замедляет процесс. 

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

Если же нет то просто танцуем на граблях.

Это исключительно личное мнение и не является единственным правильным решением.

Пошел на почту получать   IT-календарь 2016: типы багов

Принес распечатку с багом 

Вставлю и свои 5 копеек.

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

    Случай 1:

После разговора с фронтенд разработчиком, мне был дан ясный ответ:

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

    Случай 2: 

После общения с бэкенд разработчиком, ответ был немного иначе:

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

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

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

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

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

Ну да, больше(сарказм)

 

 

вообще у нас был опыт работы с подобными текстовыми областями(CodeMirror)

А в чём была проблема и как решили?

 

проблема была в поиске элемента, куда вставляется текст , а вставляется он там в div, но div появлятся только при наведении курсора мыши на текстовую область(так же в виде div'a)

 

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