четверг, 11 августа 2016 г.

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

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

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

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

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

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

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

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

четверг, 16 июня 2016 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

пятница, 20 мая 2016 г.

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

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

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

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

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

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

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

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

среда, 20 апреля 2016 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

понедельник, 11 апреля 2016 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

пятница, 11 марта 2016 г.

Месседж дня

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

Наша компания решила возобновить использование 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 от коллег.

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

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

понедельник, 29 февраля 2016 г.

Знакомьтесь - хороший автоматизатор

Кто же такой хороший автоматизатор? Тот кто может все заавтоматизировать?! Отнюдь нет!

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

  1. на создание новых тестов;
  2. на поддержку имеющихся тестов;
  3. на прогон тестов.

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

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

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

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

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

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

Дизайн тестов

Говорят, в тестировании нет интересных задач по программированию. Это не всегда так! Одна из таких задач - «как уместить слона в спичечной коробке?». Тут вам придется прибегнуть к использованию оптимальных алгоритмов, а также разных инструментов и фреймворков. Также, принимая во внимание тот факт, что в будущем вам понадобится распараллеливание тестов, вам придется писать еще и thread safe код, использующий изолированные друг от друга тестовые данные.

Как пример подобной задачи, можно рассмотреть тест на проверку данных в HTML таблице (10 строк, 4 столбца) с требованием, что тест не должен работать дольше 5 секунд.

Вариант 1: можно проверять данные поэлементно - делать запрос к каждой ячейке. В результате, придется сделать как минимум 4х10 запросов от инструмента к странице. Предположим, что каждый запрос к браузеру занимает 0.2 секунды. Итого, минимально, для получения всех данных из таблицы имеем: 4х10х0.2 = 8 сек. Вроде бы мелочь, но это только получение данных из таблицы, не считая времени на шаги предшествующие её открытию, проверки и завершения теста.

Вариант 2: можно взять html код таблицы и разобрать его, используя наиболее шустрый html парсер. Здесь мы имеем только 1 запрос от инструмента к браузеру, и проверку данных в фоне. Поверьте, это будет намного быстрее.

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

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

Существует также один подход, на котором хочется отдельно заострить ваше внимание:

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

Автоматизация только важных тестов

Данную тему необходимо рассматривать с двух сторон: новая и имеющаяся автоматизация.

Вопрос о новых тестах нужно ставить так: «Что именно нужно автоматизировать?». Вы должны четко осознавать приоритеты и соответственно выделять время и ресурсы на автоматизацию. Например: разрабатывая второстепенную (абсолютно не критичную) функцию, нет смысла вкладываться в автоматизацию по полной. И вообще, можно задаться вопросом: «Зачем нужно автоматизировать эти тесты?».

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

Немаловажным будет и то, что:

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

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

Разбиение тестовых наборов на части

Разбивая тесты на части (об этом я уже говорил в статье «Зачем всегда запускать все UI тесты?»), вы всего-навсего оттягиваете неминуемый коллапс. Количество тестов будет неимоверно расти, и вы, как следствие, придете к распараллеливанию.

Распараллеливание тестов

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

Проблемой многопоточного запуска может также стать тестовый стенд (test environment), конфигурация которого очень часто отличается от используемого в реальном продакшине. Обратите ваше внимание, что используя многопоточный режим, вы имеете не просто функциональный, а мини нагрузочный тест. Это может привести к тому, что время отклика приложения увеличиться, не говоря уже о потенциальных дефектах, связанных с функциональностью нагруженного приложения.

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

Заключение

Резюмируя все вышесказанное, хороший автоматизатор – это разработчик:

  1. обладающий пониманием того, какое место автоматизация занимает в процессе тестирования и разработки,
  2. создающий, поддерживающий и обновляющий инстурменты для тестирования,
  3. способный правильно анализировать и приоритезировать задачи, не тратя время по пустякам,
  4. умеющий делать свою работу так, чтобы потом не было мучительно больно писать новые и поддерживать старые тесты, а также менять конфигурации запуска, для сокращения скорости обратной связи при получении статуса о состоянии приложения.

Заметьте, я ни слова не сказал, что хороший автоматизатор должен быть, ко всему прочему, и хорошим тестировщиком. Сделал я это, можно сказать, из идейных соображений. Мне кажется, что автоматизатор это программист – разработчик, примеряющий время от времени «шкуру» тестировщика. Иногда руководству такая универсальность видится очень удобной для проекта, и они поощряют её. Однако эта игра может затянуть автоматизатора, и он начнет забывать, кто он на самом деле. И тогда мы получим «разработчика» свято верящего, что он тестировщик.

Автоматизатор, пора тебе выйти из тени и сказать, что ты есть, кто ты есть и зачем ты здесь.

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

Условия копирования публикаций:

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