пятница, 27 декабря 2013 г.

TEST IT. Почему учиться полезно даже людям с опытом?

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


И сегодня с вами снова я, сменная ведущая Киселева Ольга. Как и обещалось, раз в месяц мы выходим на связь!

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

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

И куда дальше расти? Зачем читать книги, если и так знаешь все, что там написано? Какой смысл идти на курсы, если и так вроде как умеешь использовать тот же тест-дизайн, а по selenium можно гордо использовать гугл?

Ребята! Если вы все еще думаете, что все знаете, забудьте про это! Я через это проходила, но это значит только одно - вы уперлись в потолок на своей работе. Вам просто не нужны новые знания и опыт на текущем проекте. Иногда... А иногда бывает и так, что вроде знания есть, книжки читались, но не применялось, не применялось, да так и забылось...

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

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

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

И вот сегодня я хочу с гордостью представить вам отзыв Елены Тихомировой о курсе Алексея Баранцева Практикум по тест-дизайну.

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

Про техники тестирования на проекте

В данный момент я занимаюсь тестированием Интернет-Банка для ***.

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

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

Расскажу небольшую историю про то, как я делала это задание. Я делаю все задания на работе в любую освободившуюся минуту. И это задание было не исключением. Один из моих коллег увидел, как я заполняю параметры для комплектации, увидел какое их количество. И говорит, что у тебя будет порядка 1000 тестов. Я ему объяснила, что тестов должно быть намного меньше. Я, конечно, думала, что количество тестов должно быть небольшим, но не думала, что на столько (для такого огромного количества параметров). И, о чудо, тестов нагенерилось всего 35.

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


Но, после применения данного метода, количество тестов сократилось до 40, что является несомненным и приятным плюсом.

Вы все еще сомневаетесь? Тогда мы идем к вам! Smile :)

Вы только посмотрите, какие эмоции в Ленином отчете! Сколько чувств, сколько восхищения простым методикам! Несмотря на всю их простоту они выглядят как чудо! Задумайтесь об этом...

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

И у вас это обязательно получится, я уверена! Поэтому, отвечая на письма в TEST IT - учиться никогда не поздно! Ребята, учитесь! Учитесь, учитесь и еще раз учитесь! А потом - применяйте все, что узнали. Иначе не стоило и начинать...

За сим откланиваюсь. До встречи, ребята!
Мы ждем ваших писем - пишите на sprosi.testera@gmail.com, задавайте вопросы, рассказывайте истории, грустные и не очень, делитесь опытом - мы рады всем!

Пока, увидимся в Новом году!!!

среда, 25 декабря 2013 г.

Добрый и злой полицеский при управлении процессом




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

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

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

Не могу сказать, что я любила злого полицейского Smile :)
Однако сейчас... Я сама им стала!

У нас в компании бюрократии особой нет и официальной иерархии тоже.
Я отвечаю за установку релизов Заказчикам.

А еще у нас есть один гениальный разработчик (они у нас все гениальные, конечно, но сейчас не об этом). Назовем его Рома, раз он Разработчик.

Когда он пришел, он был одним из трех на нашем проекте. Сейчас, потихонечку, стал главным. Добрый, веселый парень! В свое время его попросили проводить всякие собрания, ретроспективы, стендапы... Так он получил гордое звание нашего scrum-мастера.

Но у меня то шило в..., я тоже активная. Поэтому иногда помогаю собрать тот же стендап, бегаю всех и пушу )) А уж когда время релиза подходит! Очень сочувствую страдающим коллегам, "но задачку сегодня закрой" (с)

Помню, недавно что-то такое было... Релиз скоро, а у нас еще branch не создан. Я прибегаю к Роме, бегаю вокруг его стола в волнении:

- Рома, Рома! Где branch?! Ну пойди, пни А. (ответственного), пусть сделает, релиз же на носу! Ты же scrum-мастер, ты должен заботиться о его благополучном выпуске!!!

А Рома так откинулся в кресле, рассмеялся и сказал:

- Неееее, Оля, сама иди пинай. Этим у нас ты занимаешься! А я добрый полицейский! У нас с тобой такая пара, хороший и злой. Так что сама иди пинай ))))

Я сначала ходила возмущалась, что я белая и пушистая Big Grin :D
Но, стоит признать, что я своего все равно добьюсь)))

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

Мне в этом плане повезло, я пришла в уже "гибкий" коллектив и особо ничего не меняю, поэтому "это я еще добрый!". А был бы велосипед... Эх!

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

После нашей второй темы пыталась применять Pairwise  при помощи инструмента Allpairs. (Спасибо Ольге Киселевой - заставила разобраться с PICT-oм). (с)

Вот вроде и приятно, научила чему-то. Но ведь не "показала, научила, вдохновила", а именно "заставила"...

Пора, похоже, быть добрее Smile :)
Хотя, судя по комментариям в открытке на ДР, пока еще любят)) Или терпят...

четверг, 19 декабря 2013 г.

Авиационный тест, вы пользователь или разработчик?

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

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


Чтобы подчеркнуть различие между видами, я применяю забавную лакмусовую бумажку — «Авиационный тест». Чтобы пройти тест, достаточно представить, что вы идете по посадочному коридору авиалайнера. Вступив на борт, вы должны выбрать — пойти налево в кабину или же направо в салон.

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

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

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

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

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

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

вторник, 17 декабря 2013 г.

I help bob keep his job. Radomir Djenadic


Книжку I help bob keep his job я в свое время купила на Амазоне не в последнюю очередь из-за ее цены. Но потом она так и висела в моем kindle-ридере, а руки все не доходили...

Теперь дошли Smile :)
Мои выдержки из книги - ISTQB? BaNAna!!!

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

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

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

Честно говоря, меня эта история позабавила, но не впечатлила. Однако книгу я решила дочитать, она мне просто внезапно попалась под руки, когда я дочитала бумажную и под рукой, кроме ipad, на котором после обновления стерлось все, что было честно закачано, а не честно куплено. Вариантов особо не было, а там уже и втянулась. За один день прочитала 400 страниц! На английском! Без переводчика! Классно же!

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

Я, например, не знала перевода "нанимать на работу" (hire), но по тексту было понятно. А потом в твиттере прочитала то же самое. Или смотрю, автотест называется obsolete, уточнила, не absolute ли, нет, это именно устаревший. И тут же вечером в книжке натыкаюсь на это слово! Так что очень интересный опыт Smile :)

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

воскресенье, 15 декабря 2013 г.

Летняя школа 2013

Я уже давно ее анонсировала, кучу постов оттуда понаписала, но вывода так и не сделала. Исправляюсь! Smile :)


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

Мои "вести с полей":
Что можно сказать о школе? О, это потрясающее времяпрепровождение!

Если вы вдруг еще не знаете, что это такое:

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

А еще Алексей позволяет ребятам рассказывать свои истории, печальные и не очень. Делиться опытом! И классу хорошо - интерактив, здорово! И Алексею - добавляет опыт ребят в свою копилку знаний. А еще с Алексеем можно даже поспорить, он не будет злиться, а просто возьмет и объяснит, почему он прав Smile :)


А вечером, вечером! На сцену выходит еще один классный тренер - Наталья Руколь!

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


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

Ну а в остальное время - море, воздух, настолки, ребята, купаться... Работать, читать, пиcать блог-посты! Smile :)


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

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

Что бы мы без них делали, даже не представляю!

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

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

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

С нетерпением жду следующего лета и очередной школы. Увидимся в Крыму!

вторник, 10 декабря 2013 г.

Тестировщик - адвокат Заказчика. Так не опозорьтесь же!

Продолжу практику выписывания интересных советов из книжки Lesson Learned in Software Testing (№ 153), в вольном переводе (глядишь, заинтересуетесь и прочтете их все уже в оригинале):


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

1. Описывайте багу четко. Шаг за шагом, выкинув все ненужные телодвижения. Кратко, но понятно. Описывайте симптомы аккуратно. Сделайте так, чтобы ваш баг-репорт был просто для восприятия и воспроизведения. Ваша работа будет иметь ценность благодаря тому, что вы покажите тем самым уважение к времени разработчика.

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

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

4. Доставляйте плохие новости напрямую. Не идите в обход людей, с которыми еще хотите нормально работать. Скажите им, что эскалируете проблему выше, прежде чем сделать это.

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

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

7. Если вы честны, можете развивать свою компетентность. Если вы не честны, ваша компетентность никого не волнует.

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

Всегда помните о правиле 20 минут! Сначала поизучайте проблему сами, а только потом просите о помощи, цените время своих коллег!

суббота, 7 декабря 2013 г.

Летняя школа 2013 - Екатерина Михеева.


Чукча - не писатель, чукча фотограф! (с)

Но летняя школа мне так понравилась, что я просто не могу промолчать! Я попала в эту замечательную школу еще в 2012 году, мне там так понравилось, что я решила вернуться снова! Это удивительное место! Где еще можно отдыхать и получать знания одновременно? Где еще можно поваляться с тренером на пляже, обсудить тесхники тестирования, а потом уехать в город гулять по вечернему Крыму?

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

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

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

Единственное, что не очень понравилось - самые жаркие часы, с 12 до 16 - часы перерыва, давайте, идите на жару! Жарьтесь, купайтесь, обгорайте! А самое классное время вечером, когда классно по закату погулять - это время было занято занятиями... При этом такими интересными, что никак нельзя пропустить! Мне кажется, что было бы прикольно учиться как раз в жарень, а с утра отсыпаться, вечером гулять! Хотя, конечно, да, может получиться как на конференциях, много-много знаний и ты сильно устаешь. Но хотелось бы хотя бы иногда делать так, чтобы занятия были днем, а вечером гулять. Не всегда, конечно!!! Буквально пару дней. Для разнообразия Smile :)

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

четверг, 5 декабря 2013 г.

ISTQB? BaNAna!!!


В книжке I help bob keep his job автор очень забавно описывает свое отношение к сертификатам. Приведу вольный перевод.

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

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

To demonstrate what i feel about any kind of certification, i will now declare myself Orderly Anonymous Global Iltimate Testing Authority Nominee, or OrAnGUTAN in short, and will start issuing Basic Native Analogical testing certification, or BaNAna testing certificate in short.
 
So OrAnGUTAN  will be issuins a lot of BaNAna testing certificates. Sound cathly, doesn`t it? So each person that reads this paragraph is allowed to put a BaNAna in his or her CV.
 
To prevent any kind of economic scam from my side, i allow everyone who bought this book to pass it to their friends, so they can read this paragraph  and get themselves BaNAna -certified, even if they have nothing to do with testing. I also empower all BaNAna certified people to certify oyher people, members of their families and their pets in the same way. Hell, let`s certify some pot plants also!

Если и тут сделать вольный перевод - чтобы продемонстрировать свое отношение к сертификации, автор нарекает себя Orderly Anonymous Global Iltimate Testing Authority Nominee, или, если коротко, то OrAnGUTAN. И начинает выдавать сертификат под кодовым названием BaNAna.

И всякий, кто прочитал этот параграф, может гордо положить сертификат BaNAna к себе на полочку, предварительно его распечатав (ну а что. стандартная форма, заполняем название того, кто выдает и название сертификата = профит Smile :)).

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

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

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

PS - я честно купила эту книжку, так что все вы, прочитавшие данный пост, нарекаетесь сдавшими BaNAna. Мои поздравления!

вторник, 3 декабря 2013 г.

Мутационное тестирование

Что такое мутационное тестирование? Если вкратце, то это когда мы меняем в коде "равно" на "не равно" и смотрим, какие тесты отвалятся. То есть проверяют ли они то, что и должны.


Я, кстати, это определение услышала на #yatest (Конференция Яндекса Тестовая Среда). Хотя что-то знакомое, я его явно слышала и раньше, просто успела забыть, что же это такое.

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

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

Есть у нас в системе некие правила, которые говорят "если А сработало, ничего не делай", то есть оставь систему в исходном состоянии. Ну. как если на кнопку "Отмена" нажать (турецкий маркет — это простой маркет! Только на турецком... (с) Тестовая среда).

Есть автотесты, которые написаны по этому правилу и честно проверяют, что состояние системы не изменилось. В начальном состоянии базы мы указываем поле n_1, зная по конфигу, что n_1  это артикул товара, например.

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

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

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

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

Вот и сделали проверку: если параметра нет в конфиге, значит, автотест подозрительный, вряд ли он что-то проверяет. Столько тестов попадало сразу! Вот так результат. В процентном соотношении, конечно, не много, но нашлись такие и в других модулях.

Это заставило задуматься о том. что:
  1. Настройка слишком сложная, раз в ней так легко ошибиться, надо упрощать.
  2. Мутационное тестирование — это мега-полезно! Главное, применять по чуть-чуть, чтобы сразу увидеть результаты.
Нет, конечно, до конференции яндекса я не знала (или не помнила?) этого умного названия "мутационное тестирование". Но вот что-то гложет, гложет. И теперь я понимаю, что.

Ребята! Посмотрите внимательно на свои тесты! Если система большая, их уже накопилось довольно много. И, возможно, часть из них устарела, а вы даже и не в курсе. Посидите, подумайте, можно ли где-то включить инверсию и посмотреть, что получится. Упадут ли те тесты, которые вы ожидаете? Результаты могут вас удивить! Тесты могут остаться "зелеными". А вот это уже сигнал — что-то тут не так.

И я считаю, что "мутационное тестирование" — это как свежий взгляд на систему. Как знаете, нанимаешь нового сотрудника и смотришь, как он реагирует на продукт, что удобно, а что нет. Ведь ты уже привык, что это работает именно так и можешь даже не замечать, насколько это сложно и неудобно. Также и с тестами. Сам же писал! Значит, хорошие Smile :) Но иногда и для них нужен свежий взгляд, очень помогает...

понедельник, 2 декабря 2013 г.

Яндекс. Тестовая среда 2013

В эти выходные ездила в Питер, на конференцию Яндекса под названием "Тестовая среда". Раньше Яндекс устраивал более общие конференции, выделяя тестированию одну секцию, а тут, бац, — и полностью для тестировщиков, круто же Smile :)



Правда, мест было мало, и пригласили туда далеко не всех. Но вот мне повезло, меня пригласили! Так что подъем в 5 утра и здравствуй, Сапсан!

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




А еще в нем есть банкомат Альфа-банка, что нас с коллегой очень обрадовало в связи с закрытием Мастер-банка, — не пришлось голову ломать, где теперь обналичивать...

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

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


А потом начались сами доклады!

1. Прочная основа для автоматизации тестирования
Артем Кошелев, Яндекс


Артем рассказывал о работающей у них связке для автоматизации - Maven, Git, Jenkins.
Что будет, если мы собираем все через ant? Знаете, как там настраивать зависимости? Все складываем в некую папочку /lib, которая в итоге становится одной большой помойкой.

Решили перейти к maven. Он в этом плане удачнее, так как является, помимо всего прочего, еще и репозиторием артефактов. У тебя есть артефакты на локальной машинке, есть некое Community твоей фирмы и есть еще одно большое общее хранилище. Так что, если чего-то нет у тебя, идет обращение выше, а если нет и там, то еще выше.

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

Теперь посмотрим на систему версионирования. Кто знает про svn? Ага, в зале есть сочувствующие Smile :) Как создавать бранч в svn?

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

А git - он просто провоцирует хорошие практики, потому что придерживаться их в нем очень просто и удобно!

Ну и, наконец, сама настройка CI с помощью Jenkins. Наколбасил у себя на компе, отправляешь pull-request. Твой код начинает анализировать Sonar:
  • На сложность кода (чем проще код, тем сложнее в нем ошибиться!).
  • На соответствие правилам кодирования.
  • На дублирование кода.
И если все ок, то запускаются тесты, все прогоняется и дальше уже или все ок, или нотификации заинтересованным лицам.

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

2. Как найти общий язык с результатами тестов
Второй докладчик поднял тему понимания результатов автотестов. Конечно, хорошо, когда их умеет читать только тот, кто писал тесты, но все же как-то не очень. И вот ребята придумали сделать свой продукт с блекджеком и преферансом. Open-source, так что you are welcome в помощь! Главная цель продукта — чтобы результаты читал не составить тестов, а другой человек.

Фактически их продукт, Allure являет расширением стандартного xUnit, к которому они прикрутили шаги и аттачменты.
  1. Аттачменты — возможность вставлять аттачи: json, txt, png и тому подобные.
  2. Шаги — тут важна возможность вложенности. Потому что бывает шаг "регистрация", который имеет подшаги "зайти туда, кликнуть сюда", но нам бы хотелось понимать в целом, на чем упал автотест, шаг верхнего уровня. Теперь это возможно!
Ну и прочие технические подробности можно послушать в докладе Smile :)

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

3. Анализ данных для поиска ошибок

Илья — начальник в исследовательском отделе. Он считает, что всю нудную работу должен делать робот, а человек просто получать свою зарплату тестировщика Smile :)

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

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

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

Модель — это набор правил, например:
  1. Блок А есть всегда.
  2. Если есть блок Б, есть и блок В.
Конечно, не без ошибок и ложных срабатываний. Но это все решается скармливанием роботу дополнительных примеров. А так все просто! Вот, например, тестировали турецкий маркет. А это простой маркет. Просто турецкий...

А еще такой робот находит ошибки, которые человек мог бы и не заметить. Вот например...


Забавно, что пример был на книге "Лечение водкой и самогоном" Smile :)

Вообще хочется отметить, что первые три докладчика были просто шикарны. И по стилю презентации, и по стилю ее подачи. Так ярко, задорно! Я прямо даже прониклась и поняла, почему к ним люди работать приходят. Слушаешь ребят, у которых глаза горят, которые с шутками-прибаутками рассказывают о чем-то сложном и думаешь: "Вау, классно, наверное, с ними работать!". Так что конференция еще и пиар-ход компании)))

Кстати, на заметку программному комитету SQA Days, видите эти фамилии в списке участников, знайте, надо брать!

4. Матчеры: маленький шаг для вас и огромный для ваших автотестов

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

Матчер = описание + логика.

Есть библиотечка hamcrest — в связке java + maven подключается в 5 строк. И сильно упрощает читабельность вашего кода! Ну а коллеги из Яндекса ее дополнили и сделали свою клевую версию))

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



Своя кухня в каждом крыле, душ в туалете, эх... Но вернемся к докладам!

5. Генерация тестовых данных. Библиотека ObjectBuilders

Денис поднял интересную тему. То, что вы нафигачили автотестов — еще полбеды. Но ведь вам их потом придется поддерживать! А это уже посложнее будет...

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

Правда, в тему независимости Денис высказал пример, который наглядно показал, что речь идет о GUI тестах, хнык. У нас не GUI...

Но продолжение меня заинтересовало. Вместо набора связанных объектов делаем граф. И в тестах мы описываем свойства графа! А не объектов. Делаем один дефолтный граф и в тесте его частично перекрываем...

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

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

6. Автоматизация в мобильном тестировании

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

Ох, смотрите, ребята из Яндекса, не прозевайте свой шанс Smile :)

7. Графики и Яндекс.Танк

8. Автоматизация нагрузочного тестирования
Я объединила эти доклады в один, потому что рассказчики сами так планировали, сначала Алексей рассказывает концепцию, потом передает слово Григорию. Правда, организаторы уговорили его ответить на вопросы ))

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

Графики строятся с помощью инструмента Graphite, а метрики сервера собираются для графита демоном diamond.

9. Игровые механики в тестировании

Закрывал конференцию Олесь с рассказом о том, какие фишечки они внедрили для игры внутри работы. Они сделали личные страницы сотрудников и там уже...
  • Главная страница — зал славы. Попадают все, кто хоть как-то когда-то стрелял из танков. Один раз пострелял — и уже навсегда в зале славы! Есть, конечно, проблема, что страница уже большая, но зато прикольно))
  • Рядом с людьми нарисованы звездочки — это звания. Капитан, адмирал и пр.
  • Спасибки!!! О, я уже не в первый раз слышу про эту технику, и она мне очень нравится Smile :) Тыкаешь на любого человека и тебе предлагают отправить ему сообщение: "Я хочу сказать тебе спасибо за что, что...". А человек получает в личку такую спасибку и тихо радуется. Это всякие там "спасибо, что ты у нас есть, спасибо за помощь" итд. А грустными зимними вечерами можно открыть свои спасибки и получить заряд позитива. Классная тема!!
  • Командир танка — как в Foursquare, там можно стать мэром, а тут — командиром танка.
  • "Красивые номерки" — номер запуска тестов. Тут есть печалька — красивые номерки часто уходят роботам Sad :(
  • Личная "стата".
  • Бейджики — ачивки, ачивки!!! Всего около 20 штук самых разных.
Рассказал Олесь и о проблемах, связанных с таким подходом. Главное, чтобы это была просто игра! Если от этого зависит зарплата, то все, пиши пропало, люди будут работать ради ачивки, а не ради работы как таковой. Так что нет, у них нельзя поискать по некому фильтру, кто умеет то, кто се. Это просто игра.

И да, прежде чем внедрять геймификацию, подумайте, а правда ли она вам нужна. Это тоже затраты на разработку и поддержку... Может, в маленьком компании оно и нафиг не сдалось, только потеря времени. И об этом не стоит забывать, просто кидаясь внедрять "прикольную новинку"!!!

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

Я с конференции унесла несколько светлых идей, встретила знакомых людей, москвичей, с которыми видимся только на конференциях в других городах, питерцев, которых знаю только по скайпу, ну и прочая. Так что и позитив и знания. Здорово! Спасибо ребятам, будем через годик ждать продолжения!! Надо же хоть где-то видеться с коллегами Smile :)