Так почему же пирамида?

Почему же все-таки пирамида тестирования? Не куб, не цилиндр, не шар, а именно пирамида? Постараюсь просто описать то, как я это вижу.

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

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

“Вводишь в поле слово, нажимаешь на кнопку, и не получая того, что ожидал, заводишь дефект. Пусть разработчики мучаются дальше. В особых случаях, лезешь в лог приложения, находишь конкретную запись об ошибке и прикрепляешь её в баг репорту.”

Вроде бы все хорошо, но не до конца… Именно этими мыслями я и хотел немного поделиться.

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

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

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

Читать далее...

Тестировщик.exit();

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

- На сколько высок порог выхода из тестирования?

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

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

- Стоит ли игра свечь?
- Сможете ли вы бросить все и сменить профессию?
- На сколько просто уйти из тестирования?

Вы спросите:
- К чему все это?
Ответ прост:
- Быть может я готовлюсь к уходу, а может я просто подталкиваю, находящихся не на своем месте тестировщиков, сменить профессию :) Поживем увидим...

Читать далее...

Тестировщики в аджайле, аджайл тестеры - это опасные люди!

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

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

Почему джуниор аджайл тестировщик хуже обезьяны с гранатой?

Джуниор тестироващик по умолчанию подразумевает под собой неопытного, неокрепшего, манкитестера. Для того, чтобы стать тестировщиком с большой буквы этого слова, его надо воспитать, направить и выпустить во взрослую жизнь. Набирая же в аджайл команду джуниор тестироващика, мы делаем тоже самое, когда китайского мальчика воспитывает белая европейская семья, он никогда не будет китайцем, т.к. все что он будет видеть – это европейские традиции и ценности. Таким образом, джуниор аджайл тестировщик – это непредсказуемое порождения аджайл команды: «Я его слепила из того, что было, а потом что было, то и полюбила».

Как стать хорошим аджайл тестировщиком?

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

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

Влияет ли структура команды на тестировщика в аджайл?

Обычно тестировщики в аджайл интегрированы в команду, но я бы назвал это – изолированы в команде. Вы сидите вместе с разработчиками, общаетесь с ними, смеетесь, курите, пьете кофе. Короче отдаляетесь от своего тестировщицкого «Я», при этом незаметно меняя свой менталитет и становясь гибридом тестировщика и «ментального разработчика».

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

Куда расти тестировщикам в аджайл?

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

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

Как сделать хорошо всем?

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

P.S. И хватит читать бесполезные блоги – Работать! Работать! Работать!

Читать далее...

Поживем, увидим...

Все в жизни движется по спирали, и по всей видимости один из первых витков начинает сходиться.

Раньше, в самом начале эры software development программисты сами тестировали свой код и свои продукты. В крайнем случае этим занимались пользователи уже во время эксплуатации, всяких там alpha и beta версий. Многие этого уже и не помнят, но это было. Еще я успел застать это, работая программистом по распределению еще в самом начале 21 века.

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

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

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

Что же будет дальше? А все пойдет опять по кругу… Опять начнут выделять тестировщиков, потом загонять их обратно и так далее и до конца времен…

Читать далее...

Сервис белых ворон…

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

1. Вы можете выполнять работу своих коллег по скрам команде?
2. Вы пишите код?
3. Вы фиксите баги?
4. Вы пишите модульные и интеграционные тесты?

Если все ответы «Да», то эта статья не про вас. Если хоть где-то вы ответили «НЕТ», то вы «Белая Ворона». Вы не такой как все, вы - «слабое звено». По необходимости, вы не можете заменить своего коллегу, чтобы помочь команде.

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

Удачный спринт

• Начало спринта: разработчики пишут код, тестировщик готовится к тестированию.
• Середина спринта: разработчики выдали некоторые готовые фичи, тестировщик начинает тестировать, обкатывая свою стратегию и заводя новые баги.
• Конец спринта: разработчики выдали все и зафиксили все баги, тестировщик заканчивает тестирование и удовлетворенный качеством дает зеленый свет на релиз фич.

Неудачный спринт

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

И тут вспоминается статья Джеймса Баха: «Test Jumpers: One Vision of Agile Testing», которая делает намек на то, что тестировщиков вообще не нужно жестко закреплять за командами. Их как лекарство нужно дозировано вводить в нужное время и в нужное место. Получается что-то на подобии тест сервиса. Нужен тестировщик – вот вам он. Нужно 2 - пожалуйста, если они есть в наличии. Возможно, это будет требовать больше менеджмента, но как по мне это лучше чем, когда кто-то сидит и ничего не делает, пока другие вкалывают за двоих.

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

В следующих статьях постараюсь более подробно описать работу тест сервисной команды.

Читать далее...

Язык меняет человека, особенно язык программирования...

Началось все много лет назад…

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

«Для кого понятно? Для тестировщика? Да он в глаза ваш черный ящик изнутри не видел и боится в него залезть из-за всяких там полиморфизмов и абстракций.»

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

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

«Хотите, чтобы тестировщики писали сами шаги для BDD сценариев, и помогали вам с автотестами – напишите или помогите им написать фреймворк, говорящий на – тестерском языке»

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

«Фреймворки пишут для того, чтобы сделать код более простым, скрывая некоторые низкоуровневые особенности языка, а также для добавления недостающей функциональности.»

И надоело это тестировщикам, и стали они тогда сами, не привлекая разработчиков, фреймворки чинить, и стали они сами разработчиками, т.к. времени на тестирование у них не осталось…

«Язык меняет мировоззрение человека…»

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

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

«Аллилуя, братья, Аллилуя!!!»

Но не закончилась на этом их история, а только началась...

Читать далее...

Месседж дня

Месседж дня: «Прежде чем городить фреймворки и кучу непонятного кода, разберитесь что может делать инструмент»

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

Проведя день, разбирая старые тесты, у меня, честно говоря, поднялось давление и закружилась голова. Файлы с кучей JS функций по 3-4 тысячи строк, неработающая навигация в TestComplete IDE, ни строчки комментариев, а механизм добавления новых элементов, в так называемый самописный Object Repository, просто вверг меня в ступор.

На второй день, я решил попробовать написать свой простой тест, и так у меня не было до этого опыта работы с TestComplete, я решил воспользоваться учебником: (что и вам рекомендую). Каково было мое удивление, когда я за 2 часа написал тест и при этом нашел способ избавиться от половины кода написанного старой командой, только благодаря тому, что начал использовать разные встроенные функции TestComplete: Tested Application, Name Mapping (Aliases), Keyword & Data driven Testing, Stores, Events и т.д.

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

Как результат, я получил +5 Knowledge по TestComplete и +5 Respect points от коллег.

Поэтому повторю еще раз месседж: «Прежде чем городить фреймворки и кучу непонятного кода, разберитесь что может делать инструмент»

Читать далее...