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 остановки как-то сомнительно, так что взяли такси. Таксист поразвлекал нас разговорами, показал несколько достопримечательностей и указал на то, что здание, куда мы едем, все такое красивое, на нем выложены варианты костюмов к балету Стравинского "Петрушка", которые рисовал Бенуа. И правда, очень красивое здание!