Перейти к содержимому

Аудит и оптимизация QA-процессов
онлайн, начало 4 декабря
Практикум по тест-дизайну 2.0
онлайн, начало 4 декабря
Школа Тест-Аналитика
онлайн, начало 9 декабря
Школа тест-менеджеров v. 2.0
онлайн, начало 9 декабря

Tishka

Регистрация: 10 сен 2014
Offline Активность: 06 окт 2019 18:17
*****

Мои сообщения

В теме: Тестирование мобильных приложений: устройства - это еще не все

01 марта 2016 - 09:20

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

 

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

 

 

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

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

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

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

 

 

Приведу пример.

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

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

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

 

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

 

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

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

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

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

 

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

 

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


В теме: Четыре секрета управления тестированием

26 февраля 2016 - 14:12

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

 

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


В теме: Картинки с багами :)

27 января 2016 - 09:30

FAAbrqEhtdY.jpg


В теме: Как грамотно организовать кроссбраузерное тестирование

11 января 2016 - 10:30

Добрый день. 

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

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

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

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

 

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


В теме: кроссбраузерность сайта

26 ноября 2015 - 15:32

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

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

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

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

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

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

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

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


Яндекс.Метрика
Реклама на портале