Notepad++, небольшие регэкспы

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

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

Итак, есть схема создания некой таблички

CREATE TABLE test (
  field_01 NUMBER,
  field_02 DATE,
  field_03 VARCHAR2(50 byte),
  field_04 NUMBER,
  field_05 VARCHAR2(100 byte),
  field_06 VARCHAR2(100 byte),
  field_07 CHAR(100 byte),
  field_08 VARCHAR2(100 byte),
  field_09 VARCHAR2(100 byte)
);

Нам надо взять все эти поля и переложить в табличку test_data.
Ищем и заменяем:

Примеры написаны в стиле

• Find - то, что ищем
• Replace - то, на что заменяем

Поехали, большинство замен шли в режиме регулярных выражений:

• VARCHAR2\(.* byte\),
• ,

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

Также убираем CHAR и NUMBER, последнюю строку вручную, ну или убрать потом из find запятую. Дата:

• \sDATE
• пусто

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

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

SELECT (

  field_01 ,
  field_02 ,
  field_03 ,
  field_04 ,
  field_05 ,
  field_06 ,
  field_07 ,
  field_08 ,
  field_09  
)...;

А теперь мы хотим сметчить эти поля в test_data и test. И получить что-то типа

WHEN MATCHED THEN

  UPDATE

  SET b.field = ab.field

Только для всех полей. Ок, сначала удаляем все пробелы

• \s
• пусто

Потом пишем

• (.*),
• b.\1 = ab.\1,

Тут, опять же, важно помнить, что в поле replace мы для подстановки группы из регулярного выражения должны писать "\", а не "$".

Ну и наконец, простейший пример 

Нам надо взять названия наших филдов

  field_01 ,
  field_02 ,
  field_03 ,
  field_04 ,
  field_05 ,
  field_06 ,
  field_07 ,
  field_08 ,
  field_09

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

• $
• пусто

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

•  \r\n
• пусто

Такие вот небольшие примеры из жизни тестировщика, подготавливающего тестовые данные 

ORACLE. Размножение чисел добавлением к ним 10

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

Итак - у нас есть табличка, в ней числовые данные, но тип у них VARCHAR2.
Надо их переложить в другую таблицу, а потом еще раз переложить, но добавив к значениям 10 (20, 30 - не важно), чтобы не дублировать значения.

Проверяем на маленьком объеме (модульное тестирование).

Создаем таблички

create table test (id number, data VARCHAR2(60 byte));
create table test_data (id number, data VARCHAR2(60 byte));

insert into test values (1, 1);
insert into test values (2, 2);
insert into test values (3, 3);
commit;

Проверяем, что получилось:

select * from test;
select * from test_data;

Заполняем таблицу test_data значениями таблицы test

insert into test_data (data) 

select data from test;

commit;

А теперь нам надо добавить к ним какое-то число.

Для этого мы берем строку, конвертируем ее в число, добавляем 10, а потом конвертируем обратно в строку.

insert into test_data (data) 

(select to_char(to_number(data)+10) from test);

commit;

Вот и все 

Светлана Иванова. Мотивация на 100%

Ссылка на книгу (издательство "Альпина Паблишер")

Прочитала книжку по рекомендации Натальи Руколь. Очень любопытная!

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

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

Но я, например, не тест-менеджер. Более того, проходя сейчас школу успешных тест-менеджеров и читая всякие такие интересные книжки, я понимаю, что мне просто нельзя руководить людьми. В силу присутствия у меня некоторых талантов ))

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

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

Кстати, у меня пока не получается посидеть и помедитировать над данным упражнением, но я придумала скрестить его с книжкой "Сначала нарушьте все правила" и поискать таланты, начав с себя. Так что начало положено! Посмотрим, что мне это все принесет, но я вас уверяю - это как минимум интересный опыт. Всем рекомендую

PS - Добавила книгу в общий список прочитанных мною книг.

Как применять свои таланты в тестировании?

Читаю сейчас книжку "Сначала нарушьте все правила", интересные вещи узнаю, о себе в частности.

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

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

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

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

Это все хорошо, но как быть с работой? Я вот, почитав книжку, внезапно задумалась и поняла, что я пытаюсь это и в работе внедрить. Например, есть принцип "5 почему?", о котором очень здорово рассказала Наташа Руколь на конференции SQA Days 10. Но у меня не получается просто сидеть и медитировать - ага, вот бага нашлась, а почему она нашлась сейчас? Почему мы пропустили ее раньше? Врядли я к чему-нибудь приду, таким образом размышляя. Нет, бывает. конечно, но редко.

Тогда я поступила иначе - найденные проблемы я стала выписывать. Придумала для себя шаблон с заголовками "Когда нашлась? Где? Какие меры были приняты для устранения?" и пошла его заполнять. Конечно, что-то получилось дублирование информации, потому что достаточно было скопипастить из джиры комментарий к задаче. Но где-то я с удивлением обнаружила возможности улучшения. Они не были приняты раньше, так как тогда это было и не нужно. Но теперь, обладая новой информацией, я поняла, что надо принимать меры.

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

Ох уж мне эта карма тестировщика!

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

Все бы хорошо, если бы не карма

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

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

На мое счастье, после нескольких миганий там таки отрисовались часики "подождите, банкомат думает". Но, как пользователь, честно вам скажу - эту отрисовку надо тестировать тщательно! А то ведь до инфаркта можно довести особо впечатлительных )))

При оформлении бага критикуйте проблему, не людей!

Как оформлять баг-репорт?

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

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

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

Эмоциональные ребята сразу поднимут крик "Ай-яй-яй! Ты что! Так нельзя, посмотри, какую багу ты тут сделал!! Позор тебе и порицание!"

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

А если коллега настаивает? Внутри появляется явное неодобрение этого самого коллеги. И работать бок о бок будет уже тяжело. У Вас остается в голове некий эмоциональный "якорь" - ага, вон Петя, он только ломать и может, а сейчас еще и оправдываться начнет, фи.

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

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

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

Поверьте, от этого всем только лучше станет.

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

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

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

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

А здесь разве тот случай? Ой сильно врядли... Интересной была реакция на feedback от группы разработки ("так и задумано"):

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

Читая такой комментарий, поневоле поражаешься, он настолько странно звучит!
Я уверена, что и сам автор комментария, увидя его спустя время, поймет, о чем идет речь.

Нельзя быть эмоциональным, когда пишешь комментарий к баге.
Это сложно осознать, когда ты увидел проблему, а тебе ее еще и завернули со статусом Won`t fix, хотя ты то уверен, что это ошибка, причем серьезная ошибка!!!

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

А в комментарии уже пишем сухо, только факты. Знаю, что сложно, но сразу вспоминается собственный опыт.

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

И вот представьте, открываешь ты задачу в баг-трекере, читаешь комментарии, чтобы понять, что там неправильно было и видишь эмоциональный комментарий в духе "Да как так можно!!! Кошмар и ужас!". И это кажется таким неестественным. Ведь это тогда ты был на эмоциях и так и писал. А сейчас уже столько времени прошло и тебе нужна именно информация, никак не эмоции.

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

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

Так что позитив оставляем (но редко!! Баг-трекер не чатик, флудить постоянно там нельзя), негатив убираем. И все будут довольны, и отношения хорошие!

PS - комментарий студента приведен с согласия автора

 

TEST IT. Как же стать тестировщиком, с чего начать и где учиться?

Коллеги, всем привет!! На связи TEST IT! 

И сегодня с Вами снова я, сменная ведущая Киселева Ольга.

Сегодня мы с вами снова вернемся к теме "А как вообще стать тестировщиком?" и ответим на вопрос Татьяны:

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

    Меня зовут Татьяна, совсем недавно я заинтересовалась тестированием. Читаю тематическую и околотематическую литературу, форумы, блоги;), подписки. Информации просто море, и, знаете, я начала понимать, что ещё немного, и -- утону.

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

    Итак, вот, что меня интересует:

1. Какие знания/навыки вузовского (технического) образования могут оказаться полезными в работе? (вопрос может показаться глупым, но, правда, начиталась, что некоторые и после гуманитарного вуза справляются с работой, кого-то и после технического пришлось переучивать...)