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

Тест, который мы вам предложим, основан на тесте швейцарского психолога Германа Роршаха . В его основе лежали 10 аморфных пятен-клякс, которые предлагалось рассмотреть испытуемым. Вариации этого визуального теста широко известны. И сегодня подобные задания используют в самых разных целях, начиная от диагностики депрессии и заканчивая проверкой на силу воображения.

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

Картинка-основа нашего теста выглядит так.

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

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

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

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

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

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

Головы. Головы диких животных, горгулий, бычья голова — все это довольно угрожающие символы. К этой же категории можно отнести маску. Подобное деление на части может быть вызвано внутренним разладом.

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

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

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

12.10.2016 03:32

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

Терминология Quality assurance

В этой статье мы будем рассматривать QA (Quality Assurance) в разработке программного обеспечения. Все это относиться к тестированию программного обеспечения, но в этой статье мы не будем изучать тонкости, а лишь разберемся с терминологией. Терминология в QA очень важна, без неё не возможно будет провести тестирования продукта. Как уже могли догадаться, QA расшифровывается как Quality Assurance что в переводе - обеспечение качества (контроль качества). Перейдём непосредственно к терминологии:

Позитивное тестирование (positive testing)

Это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. Основной целью “позитивного” тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.

Негативное тестирование (negative testing)

Это тестирование на данных или сценариях, которые соответствуют нештатному поведению. Основной целью “негативного” тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных.

Функциональное тестирование (functional testing)

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

Функциональные тестирование включают в себя:

• Функциональная пригодность (suitability)
• Точность (accuracy)
• Способность к взаимодействию (interoperability)
• Соответствие стандартам и правилам (compliance)
• Защищённость (security)

Тестирование производительности (performance testing)

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

Тестирование производительности включают в себя:

• Нагрузочное тестирование (load testing)
• Стресс-тестирование (stress testing)
• Тестирование стабильности (stability / endurance / soak testing)

Тестирование удобства использования (usability testing)

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

Тестирование пользовательского интерфейса (UI testing)

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

Тестирование безопасности (security testing)

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

Тестирование локализации (localization testing)

Это процесс тестирования локализованной версии программного продукта. Проверка правильности перевода элементов интерфейса пользователя, проверка правильности перевода системных сообщений и ошибок, проверка перевода раздела “Помощь”/“Справка” и сопроводительной документации.

Тестирование совместимости (compatibility testing)

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

Окружение может включать в себя следующие элементы:

• Аппаратная платформа;
• Сетевые устройства;
• Периферия (принтеры, CD/DVD-приводы, веб-камеры и и.т.д);
• Операционная система (Unix, Windows, MacOS, …)
• Базы данных (Oracle, MS SQL, MySQL, …)
• Системное программное обеспечение (веб-сервер, файрвол, антивирус, …)
• Браузеры (Internet Explorer, Firefox, Opera, Chrome, Safari)

Тестирование чёрного ящика (black box)

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

Тестирование белого ящика (white box)

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

Тестирование серого ящика (grey box)

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

Ручное тестирование (manual testing)

Это процесс поиска дефектов в работе программы, когда происходит тестирования работоспособность всех компонентов программы, как если бы он был пользователем.

Автоматизированное тестирование (automated testing)

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

Модульное тестирование (component/unit testing)

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

Интеграционное тестирование (integration testing)

Тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.

Системное тестирование (system/end-to-end testing)

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

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

Похожие статьи:

Решение проблем Adobe Flash на примере YouTube - Читать

1. pidval сделал(а) реблог этого от
2. alexruzhyk понравилось это
3. anko-777 сделал(а) реблог этого от
4. понравилось это
5. maryarti понравилось это
6. dfdor44f понравилось это
7. eridi сделал(а) реблог этого от
8. seonoptik понравилось это

Ииииииии... Это последняя запись из цикла! Она самая короткая, самая простая и практически целиком состоит из реальных историй. По возможности — глупо-смешных. Даже есть видео, снятое специально для записи вот прямо в момент написания. Свежачок-с. К сожалению, я не догадался снять скриншот с сообщением о падении Youtube клиента, он бы подошёл. Упал прямо при заливке того ролика, который вставлен в статью. Ладно, пусть будет мой экран блокировки.

На старте тестирования, вне зависимости от того, новый это проект или такой, что его стоило бы уже похоронить, в целом всегда ясно, с чего начинать. Если, конечно, к момент старта тестирования ни одно из звеньев цепи не слажало. Обычно тестировщики вычитывают требования и прочие документы с нерусскими названиями, типа «БиЭрКью», «ЭсАрки» и «Юзер стори» и прикидывают, как написать тест кейс, чтобы он проверил выполенения всех этих документов. Это всё понятно, на поверхности и нет смысла на этом задерживаться. Но есть ещё поведение самого Android, о котором иногда не знают не то что аналитики, но даже архитекторы и некоторые разработчики. А помня, что , только с кастомами, таких особенностей всплывает довольно много. И я говорю не о стрессовых сценариях, когда памяти нет или батарейку внезапно вынули (как-то встречал негодование человека на терминал GNU/Linux, что тот не показывает пароль при вводе, а у него глючная клавиатура и он не понимает, вводит пароль или же это клавиатура снова не работает), а о штатном поведении кастомизации Android и даже поведении, заложенном в AOSP. То есть штатные поведения системы, которые могут отрицательно сказаться на тестируемом продукте. Так называемые, негативные сценарии.

Я кратко опишу некоторые негативные сценарии и попытаюсь дать конкретные примеры.

• Проблемы связи. Самый просто пример — Fly Mode. К примеру, приложение для заметок Google Keep либо не тестировали в режиме полёта, либо найденные баги не повлияли на релиз. Воспроизвести проблему очень просто:
• Включаем режим полёта
• Тапаем на строку Take a note…
• На появившемся экране выполняем действие Delete
• Наслаждаемся покадровой анимацией движения сохранённых ранее заметок

• Нет доступа к магазину приложений . К примеру, чтобы протестировать покупки внутри приложений, нужно, чтобы сборка была выложена в магазин в специальный раздел. Если её там нет, либо там лежит не та же самая версия (речь про version code — внутреннюю версию), то покупки вы не протестируете. Если пользователь улетел в отпуск в Китай, где с подключением к Google Play всё очень печально, у него не должна отваливаться лицензия, за которую он заплатил деньги.
• Работа приложения при ограничении разрешений , если Target API Level ниже 23, то есть меньше Android 6, и когда версия API 23 и выше. В первом случае приложение является легаси, но разрешения отобрать всё равно можно. Во втором случае оно ещё начнёт получать новые исключения, которых не знавало раньше.
• Режим экономии заряда батареи . Реализация как Doze и App Standby, так и альтернативные реализации альтернативно одарённых производителей типа Samsung (да и STAMINA от Sony в первой версии), когда всё реализовано ужасно неправильно, но с этим придётся жить. Приложению допустимо не выполнять проверки в срок, не отправлять статистики, не обновлять данные. Но не допустимо падать, зависать, никогда не выполнять запланированные задачи.
• Изменение даты, времени, часового пояса . Люди могут летать в отпуски и командировки в другие страны, где другой часовой пояс. Если самолёт пересечёт 180-ый меридиан, то пользователь вполне может попасть «во вчера» с точки зрения приложения.

  Реальная история провала. Родительский контроль в KIS для Windows появился в версии 7.0 в 2006 году. В то же время в продукте существовал встроенный новостной агент, вовсе не такой, как сейчас. Предполагалось, что через него будут рассылаться разные новости об угрозах, всякие «что нового» и подобное. В релизной версии, которая уже была установлена у пользователей, был баг. Если перевести время в Windows назад, до начала действия лицензии, то защита отключалась. Строго говоря, не администраторы не могут переводить время, но 10 лет назад в фирмах особо не следили за правами пользователей и там каждый бухгалтер был локальным администратором. Один из наших клиентов в своём маленьком офисе настроил родительский контроль так, чтобы пользователи не могли шариться по Интернету, кроме как в дозволенные сайты. Драконовски настроил и паролем защитил настройки. Всё работало нормально до тех пор, пока во встроенный новостной агент не прислали новость, что пора обновиться на новую версию 7.0.1 где, помимо прочего, исправлена ошибка, из-за которой отключается защита при переводе времени в обратную сторону до начала старта лицензии. Пользователь прочёл новость, обрадовался и вырубил защиту предложенным методом. Через несколько дней эта история от него попала на тогда ещё популярный bash.org.ru. С тех пор новости подобного рода больше не приходили пользователям.

  И не думайте, что подобные ошибки не допускает. Вспомните историю с iOS, которая произошла в этом году, хотя прошло то всего 3 месяца с начала года (Примечание: да, это достаточно старая лекция, я давно хотел её выложить ). Телефоны вырубались, если перевести время ближе к началу исчисления unix time. И как Apple исправил эту ошибку? Они запретили переводить время дальше, чем критичная дата, что НЕ являлось исправлением проблемы. Злоумышленники стали поднимать свои Wi-Fi точки с названиями, которые обычно есть во всяких МакДоналдсах и через них передавать поддельное время. Устройства подключались к таким точкам автоматически и обнаруживали NTP серверы, у которых запрашивали время. Apple банально не позаботилась о том, чтобы iOS не использовала поддельные NTP серверы. Таким образом iOS вновь окирпичивались.

• Изменение локали системы, языка интерфейса . Пользователь вправе менять язык системы по сто раз на день и никто не может ему этого запретить. Задача тестировщика — убедиться, что продукт во-первых правильно реагирует на это (меняет язык на нужный автоматически), во-вторых вообще не падает. Кроме локали пользователь вправе менять гарнитуры и кегли, подбирая такие, которые ему комфортно читать. Приложение не должно расползаться, если пользователь вносит разумные изменения.
• Tapjaking . Я упомянал об этой штке в самой первой лекции. Напомню, это перехват тапов, которые принимает активити приложения А, тогда как пользователь пытался добраться до приложения Б. Просто активити приложения А прозрачное. Это выглядит как не безопасное решение Google, но так работают приложения по управлению яркостью и цветовой температурой на устройствах. Пользователям удобны такие приложения и раз Android позволяет им работать без наличия root, это нужно учитывать. К примеру, если у вас приложение, которое для авторизации использует код или, скажем, рисунок, вы обязаны использовать защиту от тапджекинга, например выставить filterTouchesWhenObscured в true.
• Прямой вызов Activity . Я уже говорил об этом, но повторим. Активити — это одна из точек входа в приложение. Вполне допустимо иметь несколько разных активити, которые могут вызывать внешние приложения, мало ли зачем. Это будут exported активити. Но может быть так, что для вызова некоторого активити нужно ему передать параметры. А стороннее приложение не передаст их. В лучшем случае пользователь увидит какой-то кривой экран, в худшем — ваше приложение упадёт. Так что не стоит, так сказать, светить голой жопой наружу без необходимости. По умолчанию флаг exported выставлен в true и, если вы уверены, что внешние приложения не должны вызывать их, стоит выставить false. Ну а тестировщик должен проверить, как будет вести себя приложение, если вызывать его активити из других приложений.
• Системный киллер . Вообще он называется OOM Killer — Out Of Memory Killer. Система начинает УБИВАТЬ, если приложению, с которым взаимодействует пользователь в данный конкретный момент, не хватает памяти для работы. Конечно, киллер не тупой, подчиняется опредлённым алгоритмам, выбирая цели (к примеру, система легко убьёт background service, но до последнего будет спасать foreground service; форэгранд сервис это, обычно, тот самы, который рисует свою иконку в области уведомлений, например — плеер), но суть такова. Как правило, на современных устройствах OOM Killer сильно не лютует. Сейчас памяти ставят от одного гигабайта и выше. Но это не касается игр. Игры настолько тяжёлые, так много отжирают памяти, что сколько не отсыпь — всё равно будет мало. И вообще, чем больше оперативной памяти будут засовывать в аппараты, тем жирнее будут приложения, а игры будут самыми жирными. При этом они останутся всё такими же унылыми и ненужными.

  Итог таков, что ваш продукт гарантированно попадёт под ООМ Киллер. Ваша задача состоит в том, чтобы убедиться, что ни к чему плохому это не приводит и продукт поднимется, как только приложение-жиробасина будет схлопнута системой (если это требуется от продукта, конечно). А система сделает это при первой возможности, жить в фоне такой жиробасине она не даст.
  Ещё один вывод — ваше приложение также не должно быть жиробасиной. Любые утечки должны обнаруживаться разработчиком ещё до того, как он напишет реальный код. Ваши тесты производительности обязательно должны иметь сценарии проверки, когда monkey генерирует тонну событий. Если код написан качественно, то сборщик мусора освободит память и система не убьёт процесс приложения. Если всё плохо и приложение течёт из всех щелей, система его пристрелит. Конечно, оно взлетит после этого вновь и память есть уже не будет, потому что после убийства процесса сборщик мусора подчищает всё, но если манки показал, что приложение течёт в его тесте за 15 минут, то у пользователя эти течи хоть и позже, но всё равно проявят себя.

• Большие данные . Если ваше приложение работает с пользовательскими данными, будьте готовы к тому, что пользователь скормит что-то очень большое безо всякой задней мысли. Например, я, как пользователь, вполне ожидаю, что клиент Youtube загрузит мой ролик, каким бы тяжёлым этот ролик не был. Я ожидаю, что архиватор влезет на любую глубину архива, который весит в 5 раз больше, чем вся доступная оперативная память устройства. Это — нормально. Если кто-то вам говорит, что «никто никогда не будет скармливать такие большие файлы», то, скорее всего, говорящий просто не очень хороший разработчик.
• Самым глупой и от того смешной ситуацией, вызывающей неправильную работу приложения, вплоть до падения, является простой поворот экрана . Сколько подобных падений было выявлено на этапе тестирования! Особенно если появляется какой-нибудь попап. На попапах опытный тестировщик сразу начинает переворачивать телефон! Бывало и такое, что вся команда тестировала продукт на одних только телефонах, где поворот экрана для приложения был заблокирован. А потом, когда завезли планшетов, оказалось, что на планшетах приложения падает чуть ли не в каждом экране. А потому что фрагменты. На экране и на телефоне были разные интерфейсы и неправильное использование фрагментов приводило к печальному итогу.
• Двойные, тройные тапы . Почему-то некоторые считают, что никто не делает множественные тапы по элементам интерфейса. Но нет! Я делаю! И не потому что тестирую, а потому что у меня в руках может быть старый телефон на Android 4.0, который и так еле ворочается, так ещё и экран у него не очень отзывчивый. Может быть не понятно, было нажатие или нет и получаются двойные тапы. Не потому что они «дабл» (в смысле не те, которые делаются с интервалом менее секунды), а потому что их получилось два и больше, пока приложение «думало». Например, пока формировало список из множества элементов.
• Одна из удобных фич Android 6 при недостаточном тестировании приводит к ужасным результатам. Вплоть до того, что её использование явно запрещается в приложении, что, пока, допускается со стороны Google. Эта фича — бэкап и восстановление из бекапа . Она, кстати, не нова, бэкап появился ещё в Android 2.2, но я не знаю ни одного приложения, которое бы использовало эту плюшку.
  Сами по себе создание резервной копии и её восстановление не страшны. Проблемы начинаются, если в продукте используется привязка к идентификатору устройства и идентификатору инсталляции. Даже в пределах одного устройства это может приводить к проблемам, а ведь восстановление из бекапа допускается самим Android на любое устройство с Android 6 на борту: система бекапит приложения с устройства А, а пользователь покупает устройство Б и восстанавливает их все на нём. И работают эти приложения одновременно на двух устройствах, хотя идентификаторы у них разные. Если это клиент-сервереное приложение, где всё общение делается на токенах, здесь возникают куча проблем.

  Боевым примером могу назвать классное приложение Talon for Twitter. Я не делал сброс устройства уже очень давно и потому не знаю, исправил ли автор эту ошибку. Когда я сообщил ему о ней, он мне ответил, почему ошибка возникла (хотя я и так знаю, почему!), но не сказал, будет ли он исправлять поведение. В общем, в этом приложении есть своеобразный мастер установки, который рассказывает о возможностях этого Twitter клиента, по пути запрашивая нужные пермишены. Всё чётко по гайдлайнам Google, прямо по нотам. Когда мастер настройки пройден и нужные пермишены получены, взводился флаг об этом, чтобы повторно не проходить настройку каждый раз. И приложение бэкапилось вместе с этим флагом. Вместе с ним оно и восстанавливалось. Хотя по умолчанию для всех приложений нового типа (т.е. targetApi level >= 23) разрешения отключены. Запускаешь приложение, а оно не может нормально работать. Потому что нет проверки на доступность пермишенов, все проверки остались в мастере первоначальной настройки, который не запускался, потому что флаг был выставлен в значение «мастер уже пройден». Кроме того, после запуска клиент не загружал твиты, давая отлуп от самого Twitter. Потому что прикопанный токен был не валиден на новой инсталляции и нужно было запрашивать новый, а этот запрос также делался в мастере установки на первом же шаге!

• В Android, начиная с версии (если мне не изменяет память) 2.2.1, появилась возможность штатно перемещать часть данных приложения на карту памяти . Потихоньку эту возможность стали зарезать, пока в Android 6 Google не дал ей вторую жизнь, значительно улучшив. Если производитель устройства в своём кастоме не сломал поведение AOSP в этой ситуации, то, как только Android обнаруживает карту памяти, он предлагает сделать выбор, будет ли пользователь её иногда вытаскивать или нет. Если пользователь говорит, что не планирует её отключать, то Android форматирует карту в свою файловую систему и подключает как часть основной памяти, позволяя устанавливать туда приложения. И здесь несколько подводных камней:
• Если приложение использует захардкоженные пути, то всё пропало. Но это настолько плохой тон, что, надеюсь, никто так не делает.
• Если приложение запросило у системы пути при первом запуске и прикопало их навсегда, то будет ровно тоже самое, что и с захардкоженными

• По мере обновления приложений, пользователи будут получать новые версии из магазина приложений и ставить их поверх существующей. Потому проверка обновления приложения на новую версию — обязательный сценарий. В обычной ситуации всё должно быть нормально, но когда приходится поддерживать множество специфичных устройств своим специфичным поведением, формат настроек может меняться. Почти никогда это не приводит к падениям, если код написан более менее качественно, обрабатывает различные исключения. Но просто потеря части настроек — это уже плохо. К примеру у нас была ситуация, когда пользователи месяцами формировали список антиспама, блокируя номера такси, банков, коллекторских служб, а затем, после обновления на новую версию, все списки терялись. Именно потому что сменился формат настроек и именно здесь, именно в этом месте, настройки не читались новой версией продукта.
• Кроме обновления продукта на новую версию, бывает более редкий, но гораздо более хардкорный вариант — обновление самой прошивки на новую версию, да при работающем продукте. Я приведу в пример два случая, один из которых уже рассказывал.
• Обычный Security Update для Android 5.1, который взял и отключил работающие всю жизнь фишки ОС, которым пользовалось приложение
• После обновления Android 4.4 на Android 5.0, менялись пути установленных приложений. Раньше установленные приложения хранились по одному привычному пути (/data/app/com.package.name.apk). В одном из наших продуктов для внутренних целей, связанных с безопасностью, есть проверка на то, по какому пути защищаемое приложение доступно и не менялся ли он. Прилетело обновление до 5.0 и абсолютные пути изменились для уже установленных приложений (data/app/com.package.name/base.apk). Продукт бил тревогу, что приложение скомпрометировано. Поправили, конечно.

Мы (не такой уж это и секрет) очень переживаем за качество своих продуктов и с трепетом наблюдаем за обваливанием системы. Это оправдывает существование тестировщиков в мире. Это заставляет нас чувствовать себя героями: пришёл великий Тестер и спас своих пользователей от ужасных критических багов!

И наши тестировщики никогда не забывают про негативное тестирование, хотя не всех прогеров это радует. Но такие проверки не прихоть «злых тестеров», они вызваны необходимостью закрыть уязвимости и обезопаситься от проникновения в систему хакеров и ботов, Dos/DDos атак.

Конечно, ведь в чём состоит призвание тест-специалистов? Нужно найти проблемы. Проблемы, о которых никто чаще всего не успевает подумать, не хочет их видеть и иметь с ними дело. А уж если проверяется не только правильная работа системы, но и её ненормальное поведение, то напряжённости в команде добавляется.

Понимаете, программисты-то пишут софт, нацеливаясь на результат, на запланированный релиз, летят на крыльях вдохновения! А тут наступает этап проверки и многочисленных исправлений и правок «идеального» кода. И всё, прячься кто куда, система на тестировании.

Чтобы никого не нервировать, некоторые специалисты могут откладывать негативное тестирование на потом или вообще игнорировать его (ужас!) в угоду сокращения сроков и бюджета. Ну а чего проверять, если прога не делает даже того, что должна, правда? Не-а.

Позитивное и негативное тестирование

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

Позитивное тестирование - это проверка работы системы на соответствие её нормальному (штатному, ожидаемому) поведению, согласно ТЗ и . То есть здесь мы смотрим, делает ли ПО то, чего от него ждут, соответствует ли реализация современным требованиям, поддержаны ли гайдлайны пользовательского интерфейса и т.д.

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

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

Поэтому, по нашему мнению,

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

Поскольку можем ли мы сказать, что система работает как надо, если проверяем её реакцию только на правильных входных данных?

Позитивно-негативное тестирование

При тестировании ой как важны интуиция, чуйка, охотничьи инстинкты – зовите, как хотите. И вот сидит такой наш инженер, проверяет форму регистрации, допустим.

Проверяет всё по ТЗ и тестовым сценариям, смотрит, как данные обрабатываются, которые юзер должен ввести в поля (не факт, что введёт, кстати) и тут вот оно – озарение! Ему кажется, что если ввести вот в это поле для login какой-нибудь «%адынадын/>», а не обычный текст, то что-то точно произойдёт. Что-то тёмное и мрачное неправильное.

И что? Он должен сказать себе: «Нет. Сейчас я должен заниматься позитивным тестированием и ничем другим. Вот у меня назначено негативное на следующей неделе, тогда и настанет время для %адынадын/>. Наверное»?

Мы считаем такой подход к негативному тестированию неэффективным, и вот почему:

1. Если проводить позитивное и негативное тестирование по отдельности, то это будет дольше. Как минимум потому, что это будут уже две итерации тестирования.
2. Тестеры и кодеры живут в условиях дедлайнов. И если время строго ограничено, то откладывание негативного тестирования на потом повышает риск того, что про него вообще в итоге забудут. Ведь чем ближе к моменту Х, тем быстрее летит время, скорее требуется выполнить поставленные задачи, исправить дефекты, применить финальные бизнес требования (которые могут измениться) и доделать ещё кучу дел. Дедлайн – время горячее!
3. Разделение негативного и позитивного тестирования, по нашему мнению, просто противоречит природе тестера! Ведь основная его задача – это проверка системы на все возможные действия конечного юзера. А люди в большинстве своём нелогичны, и могут делать с софтом самые разные непотребства;)

Мы, как тестировщики, очень переживаем, если система содержит ошибки по проверкам из категории негативных. И особенно, если последствия таких ошибок критичны для всей системы. Но репортить их не боимся. Особенно с таким козырем в рукаве – у нас в команде есть девочки-тестировщицы. И кто сможет упорно отстаивать «идеальность» кода, когда они нежными голосками в пух и прах разносят работоспособность проекта? То-то же.

Так какие выводы мы можем сделать?

Не забывайте про негативное тестирование, объедините его с позитивным, соберите в команде опытных специалистов и старайтесь перекладывать задачу репортинга на плечи девочек! Всё, кроме последнего, советуем на 100%, а уж с этим разберётся ваш проект-менеджер.

И, конечно, обязательно проверяйте свой продукт, не думайте, что программисты сразу напишут код чисто и красиво – без багов всё равно не обойдётесь! Не говоря уже о многочисленных уязвимостях, что подтверждают регулярно утекающие в сеть персональные и конфиденциальные данные.

На своих курсах по обучению начинающих тестировщиков я предлагаю им написать позитивные и негативные тесты на:

1. Функцию вычисления корня в калькуляторе.
2. Работу с корзиной (добавление / удаление / редактирование) в интернет-магазине.

И вот что я заметила - с позитивным тестированием все хорошо, ребята придумывают разные виды тестов (потому что задача назвать несколько, а не перечислить все-все-все, поэтому, даже работаю в команде, можно не повторяться). А вот с негативным у многих возникают проблемы, просят пояснить, потому что "ничего кроме ввода символов в числовое значение числа товаров в корзине да вычисления корня из отрицательного числа на ум не приходит".

Поэтому я решила написать поясняющую статью.

Позитивное тестирование

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

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

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

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

Посмотрим на примере:

Основной тест-кейс - проверить, что корень из корректного числа действительно вычисляется.

Разбить можно на следующие классы эквивалентности:

• После вычисления корня остается целое число (корень из 4 = 2)
• После вычисления корня остается дробное число (корень из 3)

Хм, а что, если дробное число у нас будет не только после вычисления корня, но и до ? Можем же мы взять корень из числа 2,2 ? Позитивный тест? Позитивный!

Также можно разделить числа на небольшие, до 100, например. Потом взять интервал от 100 до размера int и третий будет еще больше, сколько влезает в наш калькулятор. 3 класса эквивалентности, проверяем по одному значению из интервала.

Не забудем и про граничные значения, проверим 0. Позитивный тест? А как же! Корень из 0 равен 0, а не ошибке!

Из основного, пожалуй, все.

О, вот где простор для воображения!

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

Думаете, будет работать, если работает по отдельности? Не-е-е-ет, ребята, вы же тестировщики! Никогда не верьте программам "на слово"! Придумали сценарий? Проверьте!

Тем более что такой сценарий вполне может упасть, мы же уже удалили данный товар из корзины, так? Так вот система вполне может не дать нам его снова добавить. Типа "ты уже отказался, але, я все помню!". Корректно такое поведение? Нет!

А сам сценарий позитивный? Да! Хотя уже и с нотками извращения, надо признать

Негативное тестирование

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

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

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

Но, как бы не был такой сайт удобен, если он не в состоянии отработать при влиянии человеческого фактора, пользователь рано или поздно уйдет. "Шаг влево, шаг вправо - расстрел", кому это понравится? Хочется иметь возможность ошибаться и исправлять ошибки, а не получать "по рукам" страшными сообщениями об ошибке на весь экран.

Поэтому мы проводим негативное тестирование. Что такое негативное тестирование? Это ввод заведомо некорректных данных. Вводим и смотрим, как ведет себя программа, понятные ли сообщения об ошибке выдает...

Но как составлять такие тесты? Посмотрим на примерах:

1. Функция вычисления корня в калькуляторе.

Первое, что приходит на ум - а что будет, если вычислить корень из отрицательного числа?

Но что еще тут можно придумать?

• Корень из пустоты - вспоминаем о граничных значениях, мы не можем ввести строку отрицательной длины, но вот граничное значение (строка нулевой длины) можем!
• Корень из символов - надо проверить, что скажет система, если ввести или вкопипастить туда что-то символьное. Причем символы мы делим на русские, английские и спецсимволы!
• Корень из значения "четыре" - также символы можно поделить на абракадабру и "типа число". Кстати, если уж говорить о таких "типа числах"...
• Попробуем ввести строку, которая обозначает число . И взять корень уже из нее.

Видите? На самом деле тестов не так уж и мало! Отдельно хочется высказать на тему "ввести очень большое число, максимально большое". Попробовать можно, почему нет? Но это более негативно скажется на сценарии возведения в квадрат, чем на вычислении корня.

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

2. Работа с корзиной в интернет-магазине.

Тут, опять же, можно найти числовое поле и поиграться с ним, как мы это только что проделали с калькулятором. Поле "количество товара" тут очень подойдет! Но, с другой стороны, скучно же, такие разные приложения и одни и те же тесты?

Запомните всего 2 слова - разные вкладки !

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

• Открыли корзину в 2 вкладках браузера. Сначала нажали "удалить" в одной, потом во второй. То есть попытка удалить то, что ты сам уже удалил из своей же корзины.
• Попытка удалить удаленный админом товар. В 1 вкладке под админом удаляем товар вообще, в принципе, а в другой пытаемся его под пользователем удалить из корзины.

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

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

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

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

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

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

Стали выяснять. И поняли. Пользователю надо было завести сразу много карточек (миграция), вот он и нажимал на "создать" несколько раз, зажав Ctrl (открыть в новой вкладке). И потом уже ходил по вкладкам и создавал.

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

Так что, ребята, дерзайте! Открывайте разные вкладки и вперед, ищите информацию о том, как же, ну как же ведет себя именно ваша программа при противоречивых воздействиях на нее?

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

Заходите к нам на огонек! ツ