SQL для тестировщиков

Хочу высказать огромную благодарность Татьяне Зинченко за такой прекрасный курс!

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

Удержать внимание аудитории - большой труд. Не говоря уже о такой придирчивой аудитории, как онлайн. И Тане это удавалось! Вообще ее манера объяснять сложные вещи простым языком широко известна еще с выступления на SQA Days 10.

Я записалась на данный курс, еще ничего не зная про SQL, зато зная про ораторские способности тренера. Однако к моменту начала курса (а записалась я месяца за 3) я уже выучила основы основ. Но что поделать? Деньги уплочены, вдруг что-то новое узнаю?

И вы знаете? Узнала! Особенно меня порадовала последняя лекция, про SQL-инъекции. Вот уж что-то, а этого я не знала. Было безумно интересно и полезно. И сразу же возникло желание потыкать свое приложение, что вообще очень важно на тренингах - желание применить знания!

Вот казалось бы, да? Первые несколько ДЗ я решала вообще без запуска командной строки. На win 7, да еще и 64-разрядной вообще случаются казусы с установкой... В общем, я не заморачивалась, а просто открывала код создания БД и, читая его, отвечала на вопросы.

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

Поэтому, ребята! Хотите знать больше? Побалуйте себя! Сходите к Тане, она вас многому научит. Даже если вы считаете, что и так знаете достаточно :)

Wink - делаем из скриншотов видео!

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

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

Как это сделать?

1. Запускаем программу

2. File - New project

3. В открывшемся окошке ставим галку "Hide Wink Window"

4. Далее выбираем в выпадающем списке "Window", если нам не надо записывать весь экран, допустим, мы хотим сделать запись Notepad ++.

5. При выборе "Window" разблокировалась кнопка "Choose".

Этот ворклог не нужен тебе... Джедаи-тестировщики

В продолжение темы о том, чтобы пустить Заказчиков в джиру.

Задачу в helpdesc поставили, админ сделал свой magic и появилась у Заказчиков возможность писать нам в общий доступ, так сказать. Чтобы каждый вопрос видела вся команда, а не только ее часть, подписанная на customer@support.

В итоге мы начали активно использовать галочку "Restriction to Workers", дабы попрятать комменты, не имеющие смысла для Заказчика. И даже скрыли от него закладку "Журнал работ" (где ты пишешь, сколько времени потратил и на что, и было ли это интересно), зачем ему смотреть наши ворклоги?

Однако я ходила и думала... Вот, скрыли мы свои комменты "Ага! А я говорил - потестить внимательно!!", "Да тестила я!!!". В джире их не видно будет... А вдруг email нотификации придут? о_О

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

- Давай Никите доступ.

Прихожу к Никите:

- Поздравляю, ты - Заказчик! Ставь мне таск.
- Ок, не вопрос, под кем логиниться?

Создали таску, я пошла ее покомментила, что-то простым комментарием, что-то "спрятанным". Ну и ворклоги заполнила. Посмотрели на пришедшую почту - уф, с комментариями все хорошо. А ворклоги приходят! Кхе кхе кхе. "1 час, нейтрально, пыталась воспроизвести проблему". Ну бывает же такое, когда не воспроизводится? А представьте, такое сообщение Заказчику уйдет?

Таааак, бегом к админу! Снова magic, снова я химичу с тестовой задачкой и иду к нашему "Заказчику", который коллега.

- Ну, что пришло?
- А что, должно было что-то?
- Ага.

Смотрим. Пришло только "этот коммент будет виден" и "этот тоже".

- Ура, закрываем!
- А что, ты что-то еще писала?
- А ты под собой зайти и посмотри Activity Stream :)

Зашел... Похихикал :))
Читается оно снизу вверх, если что...

Мораль сей басни такова - не доверяй сторонним программам! Их тоже надо тестить...

В летней школе очень круто! С вами был Паша, Воронеж.

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

Отзыв Павла Волкова! Встречаем:

Летняя школа тест-дизайна - отличный способ получить новые знания от двух, одних из самых авторитетных, людей связанных с тестированием: Алексеем Баранцевым и Натальей Руколь. Так я думал, когда подтверждал свое участие в мае.

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

Процесс обучения проходил легко и непринужденно. Утром и вечером.

Утром, Алексей рассказывал про методы создания тестов и отвечал на наши вопросы.

               

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

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

В целом, все прошло очень хорошо. Я получил ответы на все свои вопросы и +200 опыта.

Дэвид Аллен. Как привести дела в порядок

Ссылка на OZON.

И вот он - первый отрицательный отзыв.

Ну не смогла я, не смогла (с)
Начала читать... Остановилась на 37 странице. Не могу. Не нравится. Вообще, от слова "совсем".

Вступление какое-то... Такое... Знаете... Как будто меня в секту приглашают. "С помощью этой книги вы сумеете" и бла-бла-бла... Я честно пыталась. Тем более, что на обложке этой книги нарисована схема, про которую недавно Андрей Дзыня рассказывал. Про то, где в итоге "отложи или делегируй все, что занимает больше 2 минут". Может, он поделится своим впечатлением от книги))) Может, она все-таки интересная? Где-нибудь там... потом...

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

В общем, возможно, когда-нибудь... Я к ней вернусь. Мне, в конце концов, и Глеб Архангелький не понравился, когда я его в магазине полистала. А начала читать - и прониклась. А тут ни полистать не интересно, ни начать читать... Эх. Смотрю на надпись "мировой бестселлер" и мне кажется, что я чего-то не понимаю просто...

Может, кто-то выскажет противоположное мнение и я вернусь к ней раньше, чем планировала?)

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

Саша Карепина. Искусство делового письма

Ссылка на OZON.

Что я могу сказать об этой книжке?

Читала я ее весьма скептически настроенная. Первый пример, разбор письма Ваньки из чеховского рассказа меня не особенно впечатлил. Однако стиль повествования у автора легкий (внезапно, да?), поэтому дочитала я книжечку с удовольствием. Она, кстати, довольно тоненькая, на "3,5 часа" по оценке издательства. Эту оценку я комментировать не буду, так как быстро читать не умею.

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

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

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

Я считаю, что книжку надо обязательно прочитать всем, кто ведет переписку с Заказчиком. Ну и всем остальным - мало ли, привалит счастье. А вы уже знаете, где подсказки искать :)

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

Support Request - "Прежде всего сядь и ПОДУМАЙ!"

Как обычно происходит support, или поддержка пользователей?

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

Кто же общается с Заказчиком?

1. Аналитики

Ну, казалось бы, а кто еще? Аналитики пишут ТЗ, согласовывают его с Заказчиком, рассказывают разработчикам, что им надо сделать... Дают ответы на бесконечные вопросы тестировщиков, утрясают проблемы со сроками и многое, многое другое...

Но бывают и другие варианты...

2. Тестировщики

Ну а кто еще так знает продукт, как тестировщик? :) Логика опять налицо. Тестировщик - последняя стадия продукта, его последний этап. Он знал его на этапе требований, а теперь он докапывается до сути реализации. Ну кому еще отвечать на вопросы "а какие параметры можно отправлять через soap-запрос в этом методе?"...

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

Чем хорош такой подход?

• Разнообразие - ты не ограничиваешься рамками "сел и потыкал", ты порой сам пишешь и согласовываешь ТЗ (ну а что делать, если оно непонятно написано?). Спектр твоих обязанностей расширяется и разнообразия в работе хватает с головой.
• Быстрый feedback - обратная связь всем нужна, всем важна. Как иначе узнать, понятное у вас описание в википедии или не очень? У Заказчика нет Аналитиков/разработчиков под рукой, ему похуже будет...
• Рука на пульсе - ты всегда знаешь, какие баги есть на предпродукционной платформе, удачно ли прошел релиз? Ведь кто "яйца на бочку" кладет ((c)Андрей Мясников), подтверждая, что ошибок в релизе нет, он - готов? Тестировщик! Кому, как не ему, первому узнать о проблемах пользователя?
• Быстрый ответ - Заказчик тоже хочет быстрой обратной связи. И если у него есть проблема, он хочет знать, откуда она и когда ее поправят. Уверена, что тестировщик тоже очень хочет это знать, тут их интересы совпадают.
• Соответствие ожиданиям - вы сталкивались с ситуацией "сломанного телефона"? Когда реализовали одно, а выяснилось, что нужно было совсем другое? Ситуация была очень ярко показана в ролевой игре в летней школе тестировщиков. А, чтобы такой ситуации не было, тестировщику надо знать, что нужно Заказчику. Какие у него возникают вопросы и пожелания. Как он пользуется системой...

В общем, сплошные плюсы. Назначаем тестировщика ответственным за customer@support и радуемся жизни. У менеджеров появляется время на более важные дела, а тестировщики держат руку на пульсе.

Казалось бы, все хорошо? НО! Подумайте сами о минусах такой почты...

1. Как обрабатывается заявка? Чтобы она не потерялась "где-то в почте у коллег", создается task в баг-трекере. В который аттачатся письма, в котором идет обсуждение, что ответить, что сделать итд.

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

2. А если тестировщик забыл приаатачить письмо? Дел много, главное - ответил, остальное ерунда. По прошествии времени сидит, смотрит на задачу - "блин, что-то же делал,а что?". Лезет в почту, ищет, аттачит... Время - деньги!

3. Тестировщик заболел / ушел в отпуск. Его Заказчика радостно передают другому. У этого другого информации - все, что в джире было. А ведь половины и не было (чтобы не раздувать комменты). Что делать? Куда бежать?

В общем, так подумаешь, подумаешь... И поймешь - надо Заказчиков в баг-трекер переводить!

Создать специальный тип задач - Support Request. И пусть пишут вопросы туда. А ответственные (читай - тестировщики) будут отвечать. Но одно дело - ответить на 2 строчки, а другое дело, переслать письмо, где эти самые две строчки окаймляют "Кто? Кому? Кто в копии? Тема письма", а также подписи.

Всем хорошо! Все плюшки подхода остались, а минусы решились! Добавилась информативность - теперь вы всегда в курсе, что происходит на проекте, даже если не входите в почту его support-a. И легко можете заменить коллегу.

Но! Опять это "но", будь оно неладно.

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

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

Так вот. Все Заказчику видеть явно не надо. Только свой проект и только такие запросы. Но старые запросы ему видеть интересно. А иначе какой смысл? Часть переписки - в джире, а часть - в почте.

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

Ура? Агащаз. Сначала багу открой и почитай комменты.
А что мы пишем в комментах?

"Хихи, наконец-то они поняли, что это неудобно"
"Да вы что? Это нереализуемо! Нафик всех!"
"Ма-а-а-а-аш, посмотри, плиз, тут можно что-то сделать?"
"По-моему, они нас динамят..."
...

Ну и всякие мелочи аля "Закрывающему потестить то-то" или "пофиксил тут-то", которые Заказчику, опять же, не нужны.

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

PS - Начитавшись Демарко, вдохновившись мистером Томпсоном, я решила если не каждый день, то хоть иногда находить умные и/или полезные идеи в течение рабочего дня и записывать их...

PPS - А пряча в джире флуд 6 часов подряд, я не могла промолчать...