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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Особо хочу отметить метод pairwaise testing и поделиться впечатлениями от применения этого метода в процессе обучения и на проекте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Никто не любит IE :(

Дожили, блоггер тоже стал возмущаться 

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

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

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

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

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

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

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

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

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

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

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

I help bob keep his job. Radomir Djenadic

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

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

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

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

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

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

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

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

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

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

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

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

Мои "вести с полей":

• А у нас Летняя Школа, а у вас??
• Русские буквы в пути до файла
• Летняя школа - список книг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 к себе на полочку, предварительно его распечатав (ну а что. стандартная форма, заполняем название того, кто выдает и название сертификата = профит ).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это заставило задуматься о том. что:

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

Нет, конечно, до конференции яндекса я не знала (или не помнила?) этого умного названия "мутационное тестирование". Но вот что-то гложет, гложет. И теперь я понимаю, что.

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

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

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

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

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

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

Нет доступа к коду? Проверяй все!

Недавно выступала на Education Day в нашей компании, рассказывала о тест-дизайне на примере треугольника. Какие тесты можно написать? В частности, можно логически прикинуть, что треугольники бывают разные - равнобедренные, равносторонние, разносторонние.

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

Расскажу историю из жизни, подтвердившую эту теорию не далее как сегодня.

Есть у нас, значит, некий калькулятор. Не в смысле виндового калькулятора, а просто есть 8 разных атрибутов (а1, а2, а3... а8), у каждого свой вес и общий должен быть равен 100%.

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

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

Как будем тестировать? В моем случае - автоматизировать.

• Сначала выполняем модульные тесты, дергаем каждый атрибут в отдельности и убеждаемся, что у калькулятор выдает вес данного конкретного атрибута. 
• Потом проверяем, что если вобьем парочку, будет сумма. 
• Потом проверяем, что сумма всех-всех-всех будет 100%. 
• Потом проверяем, что если у нас 2 атрибута а4, то результат его вес учитывается 1 раз.
• Потом проверяем негативные тесты (если нюансы в алгоритме).

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

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

• Только а1
• Только а2
• Только а3

Потом у меня возникает некий вопрос в реализации и я обращаюсь к разработчику:

Ольга Киселева: Привет! Слушай, имеет ли смысл тестировать вот это и это в обоих методах, или они примерно одинаковы, пишем основные тесты в одном месте, а во втором парочку базовых, чтобы не копипастить лишнего? Отличаются ли эти методы?

Разработчик: Помни что формула расчета полностью покрывается юнит-тестами. 

Разработчик: Не сильно, все рассчитывается в одном месте.

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

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

Но интересно жеж! Дай-ка, думаю, посмотрю, что ты там понаписал. Благо, в JIRA есть у нас закладка Mercurial Commits и я могу отследить, что там разработчик накоммитил. Смотрю, ага! CalcTest.java - то, что надо.

Открываю, начинаю читать... И что я там вижу? Каких-то жалких 3 теста!!!

Один на одиночный атрибут а1, второй на сумму а1 + а2 + а3 и полная сумма, 100%.

Разговариваем дальше:

Ольга Киселева: и это ВСЕ? О_О

Ольга Киселева: 3 тестика?!

Ольга Киселева: то есть мне основные тесты в этот класс написать, да?  В API парочку, чтобы на верхнем уровне тоже поймать, да?

Разработчик: ага

Разработчик: много тестов не значит хорошо

Разработчик: эти 3 теста все покрывают))

Ольга Киселева: 3 тестика!!!

Ольга Киселева: ничего они не покрывают) у тебя четкие требования на каждый атрибут 1 число, а ты 1 число проверил и пошел сумму фигачить

Ольга Киселева: сумма тоже важна

Ольга Киселева: но отдельно каждое число

Ольга Киселева: отдельно сумма ]:)

Ольга Киселева: сама напишу)

Разработчик: пиши, но ваще сумма такая весчь, она слагается из кусочков

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

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

Нет, оно, конечно, работает. Но автотесты зачем нужны? Чтобы ты потом внес изменение и у тебя отъехали тесты, показав, что ты задел эту часть, этот модуль.

А ведь мы можем изменить код так, чтобы у нас ничего не упало. Например, перепутать коэффициенты а3 и а2. У нас написан тест на а1 + а2 + а3. И он пройдет, все же хорошо, от перемены мест слагаемых сумма не меняется.

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

Нерадостная перспективка 

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

ТМ. Описание автотестов по помидору

Применение практик тайм-менеджмента в действии!

Я уже писала про интересную книжку про методику работы по помидорке (Штаффан Нётеберг, Тайм-менеджмент по помидору).

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

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

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

Так и у меня сегодня. Прихожу на работу, а тут бац - собеседование. А потом через 15 минут уже на обед уходим (я с 12 на работе). Занялась задачей, которая досталась мне "по наследству", автотесты написаны, надо проревьюить и сделать описание. Но не идет и все тут! До обеда наваяла, там делов то, десяток тестов описать... Что сложного?

Потом вернулись и я обнаружила еще штук 7 в другой папочке, решила их изучать. А сама смотрю на время, много то как! Мы обедаем просто поздно, но это такое странное чувство, вроде как время, скоро нормальные люди домой уйдут, а у тебя еще конь не валялся по задачке. И самое обидное, оцениваешь то, что сделал, ну ведь 1-2 минуты тест описать, куда время уходит?

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

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

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

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

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

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

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

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

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

Используйте the IEEE Standart 829. Не используйте the IEEE Standart 829

В книжке Lesson Learned in Software Testing идут подряд 2 замечательных совета:

• 145. Use the IEEE Standart 829 for test documentation.
• 146. Don`t use the IEEE Standart 829.

Не буду, пожалуй, приводить тут пусть и вольный, но перевод советов.

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

Нельзя просто взять и втупую заполнить стандартный шаблон, все-все-все его поля. Это вам не по-мо-жет! А поможет вам стандартное "СЯДЬ И ПОДУМАЙ!". Подумай, что тебе на самом деле нужно, какой цели ты хочешь достичь и поможет ли тебе в данном случае этот стандарт? А если нет, то зачем он тебе нужен? Начальство требует, так как "стандарт же, это не может быть плохо"? Ну так вперед, развивай навыки коммуникации и убеждения в том, что это все не так, как кажется. Пригодятся еще, с разработчиками сотрудничать

Ron Patton. Software Testing

Мои выдержки из книги:

1. Что же такое - баг?
2. Цель тестировщика
3. Тест дизайн VS дизайн кода
4. Не забудьте про документацию пользователя!
5. Финальной версии спецификации не бывает
6. Чем полезен доступ к коду...
7. Black-box, white-box, static, dynamic...

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

Книжка по основам тестирования, затрагивает все основные моменты, которые вам стоит знать. Имхо, для начинающих она на втором месте после Lee Copeland. Русский аналог Романа Савина. конечно же, крутой. Но у Романа короткая книжка, которая помогает быстро понять основы. А Lee и Ron раскрывают каждую тему подробнее.

Поэтому, конечно же, я считаю, что такие книжки тоже надо прочитать! Мне, кстати, Паттон так понравился, что я купила эту книжку себе в личную коллекцию. И нисколько не жалею!

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

Но даже если вы не новичок, книга помогает:

1. Структурировать информацию.
2. Посмотреть на уже привычные вещи по-новому.

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

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

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

Совет фрилансеру - разделяй рабочее место и место отдыха!

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

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

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

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

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

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

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

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