среда, 30 сентября 2015 г.

Скоро SQA Days, айда учиться

27-28 ноября в Москве пройдет Восемнадцатая международная конференция в области обеспечения качества ПО «Software Quality Assurance Days». Это куча полезных докладов, новой информации и приятного общения в кулуарах!

В кулуарах конференции...

Если живете в Москве — срочно регистрируйтесь! Если не в Москве — все равно регистрируйтесь и приезжайте к нам, тут клево (smile)

Если вам не подходит формат докладов, то приходите на день раньше на тренинги, которые устраивает компания SQAlab. Уверена — будет интересно! Там есть тренинги даже от спикеров с мировым именем, например, от Gerrard Paul. Захотите сходить к нему потом — придется тратить больше денег на билеты, чем на сам тренинг =)

Приятный бонус всем читающим замечательный портал Software Testing — скидка 10% по промокоду. Подробнее см здесь.

Учиться, учиться и еще раз учиться ©
Выбирайте подходящие форматы и увидимся в Москве! (smile)

Коварный Zabbix, локализация падения сервера

Любопытный случай из жизни. (smile)

У Заказчика развернут сервер с нашим приложением, назовем его App.
Вчера Заказчик пожаловался — «App ушел из процессов, пришлось ребутать». Посмотрели по логам, ничего не увидели. Почему он перестал отвечать на запросы? Мистика!

Подкрутили console.log сервера, ждем... Сегодня опять падает. Коллега порасследовал это дело и вот результат:

В логе App killed (pid 1122). Последнее сообщение в логе soap-stats от 09:05 (статистика выводится раз в полчаса). в логе /var/log/messages в 09:31 «zabbix_agentd invoked oom-killer» ... «Kill process 1122».

Вчера App умер примерно в то же время, в логе messages в 09:09 аналогичное сообщение от zabbix

Собственно, ответ такой: zabbix решает, что на машине всё плохо со свободной памятью, вызывает чистильщика (oom-killer), тот выбирает App, как самого большого потребителя памяти, и убивает его.

Соответственно, вам надо донастроить zabbix, чтобы он не трогал java-процессы app.

Zabbix VS ваше ПО

Злобный, злобный oom-killer! (smile)
Как локализовать такую проблему?

Наши логи отловили killed, без времени и обоснования.
Дальше гугл и системные логи.

Так что помните: логи — наше все для локализации багов! И гугл, да да! Wink ;)
А еще, если ваше ПО жрет много памяти и по странным причинам внезапно умирает, посмотрите, не убивает ли его кто-то типа заббкса или даже самой винды (коллеги рассказали, что бывало и такое!)

PS — добавила пост в общую копилку багов.

Gmail Checker и поехавшая верстка письма

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

Но, казалось бы, когда пишешь все такое из себя красивое письмо, думать о верстке много не надо — открывать будут в браузере жеж. А вот и нет!

Когда делаете «красиво», помните о таких вещах, как Checker Plus for Gmail, например (smile)
Я обычно там просматриваю почту, чтобы решить, стоит открывать письмо в браузере или нет. Оттуда же удаляю рекламный спам.

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

Вот тебе и красивая верстка...

Возможно, это и не баг. Тот же Багред на телефоне тоже стремно выглядит, но он для этого и не предусмотрен. Редко кто заводит задачи в баг-трекер с телефона. А Багред нужен именно в этот момент. Поэтому пока «не работает и ладно».

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

Хорошая рассылка стоит дорого, об этом уже писал Ильяхов. Текст, картинки — это время и деньги.

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

PS — добавила пост в общую копилку багов.

понедельник, 28 сентября 2015 г.

Отдаю книги-3 (Москва)

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

Чтобы забрать книжку, напишите комментарий к блог-посту или мне на почту — ok.molechka@gmail.com, договоримся о времени. Приехать забрать надо будет в офис ХФЛабс, это около метро на кольце. Ориентировочно с 9 до 6.

Вместе с книгами в этот раз есть еще и парочка настолок Smile :)
Приезжайте, забирайте!

Книги


1. Блестящие совещания. Ди Келси, Пэм Пламб (отдано)

воскресенье, 20 сентября 2015 г.

Блестящие совещания. Ди Келси, Пэм Пламб



Ссылка на OZON.

Книга для фасилитатора. Фасилитатор — человек, который управляет совещанием. Он (обычно) не принимает участия в самом обсуждении, только помогает группе досчить общего решения.

Формат книги — почти альбомная, в метро с такой не поездишь. Но оформление красивое. Структура тоже хорошая. Авторы проходят по всем этапам:
  • Подготовка к совещанию.
  • План встречи.
  • Проведение совещания.
  • Способы решения сложных вопросов.
  • Когда вмешиваться в дискуссию?
  • Как решать возникающие конфликты?

Usability-кейс. Ох уж эти баннеры!

Из серии «как делать не надо». Даже если "все так делают". Подумайте сами — когда вы заходите на незнакомый сайт, а вам оттуда НА ТЕБЕ БАННЕР, какие ощущения? От знакомого сайта еще можно вытерпеть, один раз, наругавшись руководству. А с незнакомого слинять поскорее — одна мечта.

1. Плохой пример в играх — Русалочка


Люблю игры «Три в ряд». Среди фаворитов:

Исходно «Русалочка» была как запасная игрушка, если в планете кончились жизни. Первые уровней 100 там слишком простые, поэтому не очень вдохновляла игрушка. Потом стало сложнее = интереснее.

Но, сколько я в нее не играю (несколько месяцев, хоть и не каждый день), каждый день она неизменно «радует» меня ВАУ АКЦИЕЙ, ТОЛЬКО СЕГОДНЯ И ТОЛЬКО СЕЙЧАС.

Значит, загружаем игру

Окно входа в игру, вроде нажмешь
 "Играть" — и играешь...

пятница, 18 сентября 2015 г.

Переговоры без поражений. Фишер, Юри и Паттон

Ссылка на OZON.

Книга называется «Гарвардский метод». Таким переговорам учат в университетах и, разумеется, как у любой практики ведения переговоров, есть очень много позитивных примеров.

Метод упирает на то, что надо концентрироваться на проблеме, а не на людях. Не поддаваться жесткому натиску, но и самому не напирать. Что-то среднее между мягким и жестким методом.

четверг, 17 сентября 2015 г.

Примеры неправильных вопросов от Куликова

Святослав Куликов написал книгу «Тестирование программного обеспечения. Базовый курс», которую раздает абсолютно бесплатно. В главе про вопросы Заказчику он пишет: «посколько начинающие тестировщики допускают уйму ошибок...». ДА! Полностью солидарна  


На моем курсе в «том-самом-ДЗ-которое-нельзя-обсуждать» юные умы должны задать вопросы работодателю, выстающему в роли Заказчика. И ответы на вопросы «А какие хитрые требования не были указаны ранее и я их пропустил?» почему-то вызывают негодование =)


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

========================================================


2.2.6. Техники тестирования требований
Стр: 47/287


Вопросы. Следующей очевидной техникой тестирования и повышения качества требований является (повторное) использование техник выявления требований, а также (как отдельный вид деятельности) — задавание вопросов. Если хоть что-то в требованиях вызывает у вас непонимание или подозрение — задавайте вопросы. Можно спросить представителей заказчика, можно обратиться к справочной информации. По многим вопросам можно обратиться к более опытным коллегам при условии, что у них имеется соответствующая информация, ранее полученная от заказчика. Главное, чтобы ваш вопрос был сформулирован таким образом, чтобы полученный ответ позволил улучшить требования. Поскольку здесь начинающие тестировщики допускают уйму ошибок, рассмотрим подробнее. В таблице 2.2.a приведено несколько плохо сформулирован- ных требований, а также примеров плохих и хороших вопросов. Плохие вопросы провоцируют на бездумные ответы, не содержащие полезной информации.


Таблица 2.2.a — Пример плохих и хороших вопросов к требованиям
Плохое требование
Плохие вопросы
Хорошие вопросы
«Приложение должно быстро запускаться»
«Насколько быстро?» (На это вы рискуете получить ответы в стиле «очень быстро», «макси- мально быстро», «нууу… просто быстро»). «А если не получится быстро?» (Этим вы рискуете просто уди- вить или даже разозлить заказчика.) «Всегда?» («Да, всегда». Хм, а вы ожидали другого ответа?)
«Каково максимально допусти- мое время запуска приложения, на каком оборудовании и при ка- кой загруженности этого обору- дования операционной системой и другими приложениями? На до- стижение каких целей влияет скорость запуска приложения? Допускается ли фоновая загрузка отдельных компонентов приложения? Что является критерием того, что приложение за- кончило запуск?»
«Опционально должен поддерживаться экспорт документов в формат PDF».
«Любых документов?» (Ответы «да, любых» или «нет, только от- крытых» вам всё равно не помогут.) «В PDF какой версии должен производиться экспорт?» (Сам по себе вопрос хорош, но он не даёт понять, что имелось в виду под «опционально».) «Зачем?» («Нужно!» Именно так хочется ответить, если вопрос не раскрыт полностью.)
«Насколько возможность экспорта в PDF важна? Как часто, кем и с какой целью она будет использоваться? Является ли PDF единственным допустимым фор- матом для этих целей или есть альтернативы? Допускается ли использование внешних утилит (например, виртуальных PDF- принтеров) для экспорта документов в PDF?»
«Если дата события не указана, она выбирается автоматически».
«А если указана?» (То она указана. Логично, не так ли?) «А если дату невозможно вы- брать автоматически?» (Сам во- прос интересен, но без пояснения причин невозможности зву- чит как издёвка.) «А если у события нет даты?» (Тут автор вопроса, скорее всего, хотел уточнить, обязательно ли это поле для заполнения. Но из самого требования видно, что обязательно: если оно не заполнено человеком, его должен заполнить компьютер.)
«Возможно, имелось в виду, что дата генерируется автоматически, а не выбирается? Если да, то по какому алгоритму она гене- рируется? Если нет, то из какого набора выбирается дата и как генерируется этот набор? P.S. Воз- можно, стоит использовать текущую дату?»


2.2.7. Пример анализа и тестирования требований
Стр 48/287


Уровень бизнес-требований. Бизнес-требования изначально могут выглядеть так: «Необходим инструмент для ав- томатического приведения кодировок текстовых документов к одной».
Здесь мы можем задать множество вопросов. Для удобства приведём как сами вопросы, так и предполагаемые ответы клиента.


  • В каких форматах представлены текстовые документы (обычный текст, HTML, MD, что-то иное)? (Понятия не имею, я в этом не разбираюсь)  
  • В каких кодировках приходят исходные документы? (В разных)  
  • В какую кодировку нужно преобразовать документы? (В самую удобную и универсальную)  
  • На каких языках написан текст в документах? (Русский и английский)  
  • Откуда и как поступают текстовые документы (по почте, с сайтов, по сети, как-то иначе)? (Это неважно. Поступают отовсюду, но мы их складываем в одну папку на диске, нам так удобно)  
  • Каков максимальный объём документа? (Пара десятков страниц)  
  • Как часто появляются новые документы (например, сколько максимум доку- ментов может поступить за час)? (200–300 в час)
  • С помощью чего сотрудники просматривают документы? (Notepad++)


============================================================


Что мне особенно нравится в примерах ответов Заказчика? Они честные! И готовят к реальному миру.

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

И если вы спросите «Как должно работать приложение», вам ответят «Быстро и удобно», а не так, как вы ожидаете — подробным набором требований, которые хорошо тестируются.

Учитесь задавать вопросы.
Учитесь задавать правильные вопросы. Вопросы в мире клиента.

См также:
Учитесь задавать вопросы! — как задавать вопросы.
Как появилось ДЗ6 в интенсиве? — немного о том, как студенты пробуют общаться с работодателем.

вторник, 15 сентября 2015 г.

Тур предыдущей версии. The Prior Version Tour

Входит в «Туры по историческим районам», Tours Through the Historical District

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

Релиз продукта — накатывание обновления поверх предыдущей версии.

Было бы неплохо при релизе выполнять все сценарии и тест-кейсы, которые были доступны в прошлой версии. Мы должны убедиться, что функциональность, которую пользователи уже используют, продолжит работать в новой версии.

Функционал был — функционал остался. Ну почти...


Если имеющая функциональность изменилась — проверяем все сценарии использования функционала. Не только основные сценарии, но и альтернативные ветки. Все должно работать!

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

Цель тура
Регрессионное тестирование — проверяем, что функциональность, которая работала до новой версии, продолжает работать.

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

Но зато показывает, как может повлиять изменение, казалось бы, незначительного участка…

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

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



PS: студентам моего курса по тестированию во время обучения эта статья не поможет, но вот выпускникам во время реальной работы — очень даже!

PPS: статья сохранена на Testbase, чтобы не потерялась ссылка.

How to Break Software Security. James A. Whittaker


Ссылка на Amazon.

Продолжение серии «How to Break...». На этот раз Джеймс рассказывает о тестировании безопасности. Лучше всего читать после прочтения базовой книги, «How to Break Software», а не как я, все наоборот Smile :)

Структура книги: верхнеуровневые классы проверок, например, на уровне кода или GUI, а потом сами атаки. Всего 19 атак.

Каждая атака содержит:

  • Вступление.
  • Когда атаку следует применять.
  • Как это делать.

понедельник, 14 сентября 2015 г.

Технологическая граница в подсказках по ЮЛ

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

Нас часто спрашивают — «Какие баги мы не нашли?». Сегодня я хочу рассказать о баге, который нашелся в подсказках Дадаты, и который хорошо показывает, зачем и как пытаться искать технологические границы.

Для поиска технологической границы надо пихать «Войну и мир» во все доступные для ввода поля. ВО ВСЕ!

Стоит там ограничение или нет → все равно пытаемся пропихнуть.
Взять ту же форму регистрации.

Искать границу надо только там, где нет ограничений?

Поле «Имя» ограничено по вводу, поля пароля — нет. Это не значит, что «Войну и мир» надо вставлять только в пароль. В имя тоже пытаемся. Можно ли ввести больше N символов? А если вкопипастить? А если посмотреть на HTML и снять ограничение по длине?

воскресенье, 13 сентября 2015 г.

Радислав Гандапас. Харизма лидера (книга)


Ссылка на OZON.

Очень люблю книги Гандапаса, про ораторику были моими первыми, а потому оставили самое сильное впечатление. «Камасутра для оратора» — это как Роман Савин для тестировщиков Smile :)  Написано просто, легко и понятно.

четверг, 10 сентября 2015 г.

Oracle. Перенос в другое табличное пространство

Наша система работает с базой данных Oracle. У Заказчика БД размещена на SSD-дисках, чтобы работало шустрее. Столкнулись с проблемой — кончилось место. Докупать SSD слишком дорого, нам выделили простые диски, на которые надо было частично переехать.

По итогам переезда мой коллега написал интересные заметки, которые я сюда и выкладываю Smile :)

При переносе таблицы или матвью в другое табличное пространство все индексы на этой таблице становятся UNUSABLE. Для того, чтобы вернуть их в стан валидных, надо сделать ребилд (см. ниже). Также могут невалидными стать процедуры, функции и пакеты. При необходимости можно им сделать compile.

Таблица или матвью

alter table tbl move tablespace new_tblspc;
alter materialized view mview move tablespace new_tblspc;

Партиционированная таблица

-- указать, где создавать новые партиции
alter table tbl modify default attributes tablespace new_tblspc;
-- перенести существующие партиции - получить набор запросов
select 'alter table '||table_name||' move partition '
||partition name||' tablespace new_tblspc;'
from user_tab_partitions where table_name = upper('tbl'
and tablespace_name = upper('old_tblspc');
Скопировать получившиеся запросы и выполнить. Для контроля выполнить ещё раз второй запрос, он должен вернуть пустой результат.
Для партиционированного матвью всё получилось как-то сложно. Легче оказалось его дропнуть и создать в новом табличном пространстве.

Индексы

-- посмотреть список невалидных индексов
select owner, index_name, status
from dba_indexes
where status not in ('VALID','N/A');
-- перестроение индекса
alter index idx_name rebuild;
-- перестроение индекса с переносом в другое табличное пространство
alter index idx_name rebuild tablespace new_tblspc;

Невалидные объекты

Посмотреть список невалидных объектов
select owner, object_type, object_name
from dba_objects
where status != 'VALID';
 
select 'alter '||object_type||' '||owner||'.'||object_name||' compile;'
from dba_objects
where status != 'VALID';
-- перекомпилировать пакет целиком
alter package pkg_name compile;
alter package pkg_name compile package;
-- только заголовок или только тело (понадобится последнее, скорее всего)
alter package pkg_name compile specification;
alter package pkg_name compile body;
alter package body pkg_name compile;
-- функция и процедура
alter function func_name compile;
alter procedure proc_name compile;
В принципе, oracle должен перекомпилировать это всё при запуске, но лучше сделать заранее. Если перекомпилировать заголовок пакета, то из-за этого могут стать невалидными другие объекты, которые данный пакет используют.