Архив рубрики: Тестирование ПО

О том, как тестировать мобильный контент

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

Отдельно есть презентация от этого вебинара:

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

Исходный пост можно найти в блоге компании.

Преподавание тестирования в вузе

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

Я преподаю курс «Тестирование программного обеспечения» в Поволжском Государственном Технологическом университете бакалаврам и магистрам. Это не основная работа, а скорее помощь родному вузу и местному IT-сообществу. Моя основная работа – старший инженер по тестированию в коммерческой компании. Также я веду двухдневные интенсивные курсы по тестированию в коммерческом обучающем центре.

Вуз я закончил в 2008, преподаю с 2012-го. У меня этого предмета не было, тестированию была посвящена пара лекций в рамках другого курса, но с внедрением очередного обновления ФГОС-ов и переходом на бакалавриат предмет «Тестирование ПО» стал фактически обязательным на специальности 231000 Программная инженерия (см. стр. 15 ФГОСа). Так что тестированию, на самом деле, должны обучать довольно в большом количестве вузов.

Что ждет начинающего преподавателя в вузе

Бюрократия. Это не будет чем-то удивительным для тех, кто уже работал в государственных учреждениях, но меня раздражало обилие документов, справок, заявлений и пр. Еще до начала преподавания вам необходимо написать талмуд на сотню-другую страниц под названием Учебно-методический комплекс. Кроме этого есть отчетность по каждой лекции/практике, ведомости для зачетов и экзаменов. В общем, нельзя просто прийти в вуз и начать преподавать – надо выполнять довольно большое количество внутренних требований вуза.
В состав самого УМК входят расписание лекций и лабораторных, темы каждой лекции, задания для каждой лабораторной работы, критерии оценки, экзаменационные вопросы, краткий конспект лекций, глоссарий, методические указания для студентов и преподавателей, список литературы, список используемого ПО, требования к лекционным и лабораторным аудиториям.
Читать далее

Static Black Box Testing

В ходе подготовки к ISTQB возник у нас с коллегами вопрос:
Насколько корректно называть рецензирование, скажем, требований, статическим тестированием черного ящика?
То, что оно статическое, — понятно.
Но вот применима ли к этому виду тестирования характеристика «черного ящика»?
Взаимодействия с кодом в данном тестировании нет, да и вообще его еще может не быть на данном этапе (требования уже написали, а кодить еще не начали).
В общем, как наиболее правильно охарактеризовать этот тип тестирования? :)
И может ли в принципе существовать статическое тестирование черного ящика?

Разминка для мозгов

Задачки на составление классов эквивалентности и тестов по ним.

1. Длина имени файла в DOS (формат 8.3)

2. Дом до 5 этажей — малоэтажная застройка, от 6 до 10 — среднеэтажная, более 10 — высотная. Высота дома в данной местности ограничена 100 метрами, средняя высота этажа — 3 метра.

3. Цены на билеты: дети до 7 лет проезжают бесплатно, пенсионерам скидка 50%, остальные за полную стоимость.

4. Требование в ТЗ: логин должен быть от 4 до 20 символов, содержать только буквы латинского алфавита.

5. Программа вычисляет площадь диска по заданному радиусу. Если площадь получается более 100 ед., то предупреждение пишется в лог, если площадь получается более 10000 ед., то предупреждение выводится на экран.

6. В требованиях к продукту указано:
Идентификатор должен быть от 1 до 128 символов;
Идентификатор должен начинаться с буквы или подчёркивания;
Идентификатор может содержать буквы латинского алфавита, символ подчёркивания, цифры.

7. Пользователь вводит дату рождения. Программа сообщает знак зодиака.

8. Калькулятор кредита работает следующим образом:
Базовая ставка кредита — 15%.
Если сумма кредита от 10.000 до 100.000 руб., то ставка остаётся базовой.
Если сумма кредита от 100.000 руб. до 500.000 руб., то ставка уменьшается на 1%
Если сумма кредита от 500.000 до 1.000.000 руб., то ставка уменьшается на 2%
Если сумма кредита более 1.000.000 руб., то ставка обговаривается индивидуально с каждым клиентом.
Если срок кредита до 3 лет, то ставка остается базовой.
Если срок кредита — от 3 до 5 лет, то ставка увеличивается на 1%
Если срок кредита — от 5 до 10 лет, то ставка увеличивается на 2%.
Если срок кредита — более 10 лет, то ставка обговаривается индивидуально с каждым клиентом.
Напишите классы эквивалентности и составьте наборы входных данных для проверки расчета процентной ставки. Метод Strong-Robust.

9. Базовый тариф ОСАГО — 1980 руб.
Коэффициенты для мощности автомобиля:
До 50 л.с. включительно — 0,6
от 51 до 70 включительно — 1,0
от 71 до 100 включительно — 1,1
от 101 до 120 включительно — 1,2
от 121 до 150 включительно — 1,4
от 151 — 1,6
коэффициенты для возраста:
Возраст водителя до 22 лет включительно, стаж до 3 лет включительно, тогда берется коэффициент 1,8
Возраст до 22 лет включительно, стаж свыше 3 лет – коэффициент 1,6
Возраст старше 22 лет стаж до 3 лет включительно – коэффициент 1,7
Возраст старше 22 лет стаж свыше 3 лет – коэффициент 1,0
Напишите классы эквивалентности и составьте наборы входных данных для проверки расчета коэффициентов. Метод Strong-Robust.

10. Программа для перевода градусов Цельсия в градусы Фаренгейта и обратно. Составьте классы эквиваленности для проверки корректности перевода.

Проверка сайта на доступность с помощью Python

В таск-трекере приходит мне задача: «Разработать автоматизированные тесты для проверки важных ссылок на сайте».
«Отлично! Сейчас возьму selenium и наделаю тестов!», — подумал я.
Потом подумал еще.
Спросил программистов.
Скрипт будет запускаться на linux-сервере как по cron, так и, при особой необходимости, руками.
А надо ли тогда мне заморачиваться с этим селениумом, а потом программистам устанавливать его на сервере, если всего-то навсего нужно проверить статус страницы — или 200, или 301. Больше ничего и не требовалось.
За неделю до этого один из коллег-программистов нахваливал мне Python.

«Все это неслучайно! Сначала мне рекомендуют Питон, а теперь нужно написать скрипт. Google в руки — и вперёд!»

Быстрый гуглёж подсказал две полезные ссылки — собственно проверку url-а и доку в стиле «изучаем основы python за день».

Из этого получился вот такой скрипт из нескольких строк:

Читать далее

Тестерский матан

Борис Бейзер. Тестирование черного ящика
Начинал ее читать раза три или четыре. В результате так до конца и не осилил.
На мой взгляд, книга слишком академична. Начинающим и продолжающим тестировщикам, ИМХО, будет не очень полезна.
Борис Бейзер. Тестирование черного ящика

Еще одна книга с «академическим» уклоном — это «Основы тестирования программного обеспечения» от Котлярова и Коликовой. Много математических выкладок с обоснованием ценности/применимости того или иного метода в некоторых условиях. В «производственной практике» такое количество расчетов и графов вряд ли встретится, но, тем не менее, все уровни тестирования в книге описаны хорошо. Можно один раз помучаться и прочитать, особенно студентам старших курсов :)
Котляров, Коликова. Основы тестирования программного обеспечения

Советы по тестированию flash-приложений

Эта заметка — набор пунктов, на которые стоит обращать внимание при проверке flash-приложений.

1. Версии Flash-плеера
На момент написания статьи последней версией является 11.1.102.63. Информацию о том, какая версия сейчас самая актуальная, можно получить по ссылке https://www.adobe.com/go/flash-player-updates.
Статистика использования плагина показывает, что большинство людей все-таки нажимают на кнопку «Update», и у них одна из самых последних версий (ссылка на обновляющуюся статистику):

Статистика использования flash-плеера

Статистика использования flash-плеера


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

2. Сколько разных версий может быть на одной системе?
На одной системе может быть до 4 разных flash-плееров, и каждый со своими ограничениями и багами:
1) ActiveX для Internet Explorer
2) Plugin для Opera, Firefox и прочих
3) Chrome version — в Chrome свой механизм встраивания flash-плеера, он обновляется автоматически вместе с браузером. При регулярном автоматическом обновлении в Хроме всегда самая последняя версия флэша.
4) Standalone player
При этом настройки для каждого их них могут различаться, так что если у вас флэшка не работает в одном браузере, а работает в другом — ищите отличия в конфигурациях.

3. 32bit/64bit
Проблемы могут возникнуть, если ваше 32-битное приложение работает в 64-битной Windows: ActiveX-компонент в системе есть, но не той разрядности.

Вообще 2 и 3 пункты — это то, где часто «спотыкаются» и приложения, и клиенты.
«У меня есть Flash Player! Почему ваша программа говорит, что мне его надо установить?!»
«У меня есть Flash Player 11! Почему ваша программа говорит, что у меня версия 8, и мне надо обновиться?!»
«У меня есть Flash Player 11! У меня IE! Почему ваша программа говорит, что у меня его нет?!»
Как правило, это значит, что у клиента стоит какой-нибудь FlashPlayer 9 ActiveX 32-bit, FlashPlayer 11 ActiveX 10.3 64-bit и FlashPlayer 11.1 в Chrome. С его стороны все хорошо, а вот ваша программа использовать другие компоненты не может.

4. Настройки
1). Storage
Storage
Flash-файлы могут хранить информацию на компе пользователя, используя технологию Local Shared Objects, они же flash cookies. Они могут быть как разрешены, так и запрещены. Разрешены, конечно, чаще :) Самая распространенная проблема с ними — кончается место, выделенное под эти самые куки, и фича, которая вот-только-что-работала, вдруг ведет себя не так, как надо:
Local Storage

2). Trusted location settings
Trusted Location Settings
По умолчанию flash-файлы, расположенные на локальном диске, не могут взаимодействовать с онлайн-ресурсами, т.е. гиперссылки не работает, http-запросы не проходят. Когда файл оказывается онлайн, то все начинает работать в обычном порядке.
Для нормального взаимодействия локальных флэшек с web-ресурсами необходимо добавить папки, в которых лежат флэшки, в список trusted locations. Универсальное решение выглядит примерно так: :)
Disk С

5. Debug Flash-player
Дебаггеры есть для всех основных ОС — Windows, Linux, MacOS, всех видов — ActiveX, Plugin, Projector и даже для двух версий — 11.1 и 10.3. Скачать их можно здесь. Кстати, ссылки на эти дебаггеры проще найти через гугл, чем поиском на сайте Adobe :)
При воспроизведении флэшки в этом дебаггере все сообщения об ошибках появляются в отдельном окне.
Например, если открыть http://blog-medvedev.livejournal.com/, то повалятся Security sandbox violation. Похоже, что плеер видео на официальном сайте не очень-то заточен под вставку на другие ресурсы :)

Security Sandbox Violation

Security Sandbox Violation

Тестировщики и техподдержка

Во многих компаниях тестировщики являются своебразоной «второй линией» техподдержки: помогают техсаппорту с решением особо сложных проблем клиентов.
Какие плюсы есть у подобной организации деятельности?

(пост — мое сообщение на форуме software-testing.ru)

Зачем вообще надо тестировщикам лезть к клиентам?
Во-первых, сообщения об ошибках. Они будут всегда, потому что продукта без багов нет. Задача тестировщика — из клиентского запроса вида «ваш продукт не работает!» сделать качественное сообщение об ошибке, а может даже и не одной. Плюс к этому нужно предложить вариант решения проблемы в данных обстоятельствах.
Во-вторых, жалобы на нестабильную (частый error 503, к примеру) или медленную работу, особенно важно это для веб-продуктов и серверных решений. Это не функциональные ошибки, но еле-еле шевелящийся сервер будет раздражать сильнее, чем неработающая фича, так как касается 100% клиентов.
В-третьих, это вопросы клиентов «А как сделать вот это и вот это?». Тут стоит подумать об оптимизации интерфейса — если клиенты не знают, как пользоваться вашим продуктом, то что-то в интерфейсе не так.
Если в продукте обнаружился баг, который мешает пользователю выполнить задачу, то тестировщику придется включить смекалку и проявить знание всех скрытых возможностей своего софта: клиенту надо предложить workaround, с помощью которого пользователь все же сможет делать то, что ему нужно, причем максимально удобно в данных обстоятельствах.
И конечно, клиенты придумывают сотни и тысячи нестандартных вариантов использования вашего продукта :) Такие use case-ы также могут указать не недостаточно протестированные участки.

Зачем тестировщики нужны команде техподдержки?
Тут можно вспомнить про правило 20/80 :)
Большинство писем однотипны, и для их ответа можно пользоваться даже готовыми шаблонами. Зато оставшиеся 20% писем пожирают 80% времени техподдержки и все время тестировщика, выделенное на поддержку техподдержки :)
Техсаппорт хорошо разбирается в продукте на уровне пользователя, знает все фичи-кнопки-чекбоксы-API, но есть случаи, когда знаний сотрудников техподдержки может не хватать. Это, например, проблемы, описываемые впервые — тестировщик по роду своей деятельности постоянно сталкивается с проблемами в продукте, поэтому он быстрее и точнее определит причину и сможет подсказать решение. Если проблема в продукте — то заводится баг, если проблема в окружении и в нашем продукте это никак не решить — то решение во всех подробностях объясняется техподдержке, и создается новый шаблон :)
Еще частый вопрос, с которым обращается техподдержка — а будет ли работать наш продукт вот с таким нестандартным окружением, взаимодействовать через этот протокол, дружить с параноидальным файрволом, а можно ли результаты работы вашего продукта загрузить на сайт, заембеддить в Flex application, распространять на DVD, загрузить на ютуб... Потребности (и фантазии людей в части совмещения несовместимого) крайне разнообразны, и весь этот «compatibility» testing также хорошо знаком тестировщикам.

«Ключевые процессы тестирования»

Сегодня получил книгу Рекса Блэка «Ключевые процессы тестирования». Заказ именно этой книги был обусловлен в том числе и списком чтения от Сергея Мартыненко.
Роман Савин есть в электронном варианте.
Луизу Тамре уже читал.
Канер, Фолк, Нгуен — книги пока нет, и не знаю, надо ли ее покупать, так как информация в ней, похоже, устарела.
Калбертсон — на очереди.

И. Винниченко «Автоматизация процессов тестирования» — книга ни о чем и на один вечер. Состоит из примеров кода — полезность ее по сравнению с гуглом... гм... ну, невелика.

Борис Бейзер — в процессе чтения. Пока нравится.

А остальные книги из списка — когда-нибудь, при необходимости :)

Тестирование карандаша

Игорь Любин опубликовал Mind-map для тестирования карандаша. Пару лет назад я проходил подобное тестовое задание. Вот что получилось у меня:

Примечания:
Так как дополнительной информации нет, условимся, что:

  • Карандаш деревянный с графитовым грифелем
  • Карандаш новый, им до тестирования не пользовались
  • На одном конце карандаша находится несъемная резинка
  • Второй конец карандаша заточен производителем, и карандаш готов к использованию

Тестирование

Материал и комплектация. Осмотрите карандаш

  • Карандаш сделан из дерева
  • На одном из концов должна присутствовать резинка
  • Второй конец должен быть равномерно заточен таким образом, чтобы карандаш мог писать

Маркировка. Осмотрите карандаш

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

Удобство. Возьмите карандаш «для письма» (большой, указательный и средний пальцы ближе к заточенному концу, другой конец лежит между большим и указательным).

  • Длина и диаметр карандаша должны быть такими, чтобы его удобно было держать в руке.
  • Стержень карандаша не должен иметь острых выступов, заусенец.
  • Стержень не должен самопроизвольно скользить в руке

Использование: письмо. Возьмите лист бумаги и напишите с помощью карандаша текст

  • Текст должен появиться на бумаге.
  • Цвет текста – серый (Насыщенность зависит от твердости: чем выше твердость, тем цвет бледнее).
  • Линия равномерна: при одинаковом нажиме и положении грифеля толщина и насыщенность линии не меняется.
  • В процессе письма грифель карандаша не должен ломаться

Использование: стирание. Сотрите только что написанный текст с помощью резинки.

  • Текст должен полностью исчезнуть с листа.
  • В процессе стирания резинка не должна ломаться, крошиться или отсоединяться от карандаша.

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

  • Карандаш заточен: грифель выступает примерно на 3-7 мм с «рабочей стороны», длина среза деревянной части – около 15-20 мм.
  • Конец грифеля острый.
  • В процессе заточки карандаш не нарушил свою целостность.
  • В заточенном карандаше грифель не сломан, не выпадает.

Надежность.

  • Потрите карандаш ногтем или не очень острым предметом. Краска не должна слазить.
  • Потяните за выступающий конец грифеля. Грифель не должен выходить из желоба. Также грифель не должен ломаться при падении с небольшой высоты.
  • Потяните за резинку – она не должна отсоединяться от крепления или рваться. Потяните за крепление резинки – оно не должно отсоединяться от карандаша.

Тесты, которые надо бы провести, но одни «одноразовые» для каждого карандаша :)

Производительность.

  • Одного карандаша хватает на закрашивание N листов бумаги A4.
  • Резинки хватает на стирание M закрашенных листов из п. 1
  • Грифель доходит до конца карандаша. (Для того чтобы определить это, можно, конечно, снять резинку и посмотреть, но тогда данный экземпляр уже не будет иметь первоначального качества).