Бесплатный вебинар: Intro to TestComplete and Basics of JScript

Вебинар пройдет 11 Мая 2012, по Киеву 18:00 — 20:00 (GMT+3), по Москве 19:00 — 21:00 (GMT+4). Ссылка для подключения уже выслана всем зарегистрированным. Для тех, кто регистрируется в данный момент — я высылаю ссылку по вечерам.

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

Цель данного вебинара – познакомить Вас с инструментом для автоматизированного тестирования TestComplete и языком JScript. После прослушивания данного вебинара вы уже сможете написать простой keyword-driven скрипт и будете знакомы с языком Jscript.

 

Тайминг вебинара

1.      40 минут – Демонстрация возможностей TestComplete на примере keyword теста, который Дима Марков напишет в онлайне с краткими пояснениями. Также будет краткая демонстрация теста, построенного по принципу функциональной декомпозиции (без детализации).

2.      50 минут – Основы языка Jscript. Дима Махно расскажет о синтаксисе языка Jscript и приведет примеры основных конструкций и элементов (переменные, ветвления, циклы, функции, массивы, объекты, классы). И все это на примере фермы со свинками!

3.      30 минут – Ответы на вопросы, которые Вы задали во время вебинара.

Технические требования

  • наушники/колонки
  • интернет
  • Дополнительные требования можно посмотреть здесь (раздел «System Requirements & Purchasing», ответ на вопрос «What are the system requirements for running GoToMeeting, GoToWebinar or GoToTraining?»)

 

P.S. Также хотим напомнить, что 4 июня стартует основной тренинг «TestComplete: от record/play до фреймворка»!

В рамках основного тренинга «TestComplete: от record/play до фреймворка» каждый модуль инструмента будет рассмотрен в деталях на живых примерах. На примере тестирования десктоп и веб приложений мы научимся писать хорошо структурированные тесты, которые легко поддерживать и расширять, научимся создавать и поддерживать фреймворк, а также познакомимся с некоторыми хитростями и advanced техниками автоматизации с использованием инструмента TestComplete.

Посмотреть программу и зарегистрироваться на основной тренинг можно здесь.

Читать полностью »

Открыта запись на тренинг по Test Complete

Коллеги,

Наконец-то открыта запись на тренинг «Test Complete: от Record-Play до фреймворка«!

Тренинг стартует в начале июня 2012. Ведем вместе с Димой Махно.

Детальная программа и структура тренинга описана здесь.

Зарегистрироваться на тренинг можно здесь.

Записаться на бесплатный вебинар 11 мая можно здесь.

Если есть вопросы по тренингу — пишите в скайп dmitro.markov

Кто еще на курсе Design and analysis of algorithms?

С удивлением для себя обнаружил, что несмотря на то, что почти во всех чатах пробегала информация о стендфордском курсе «Design and analysis of algorithms» от Tim Roughgarden, реально его проходят единицы.

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

Может кто-то еще проходит данный курс? Сейчас в курсе пошел самый треш: сложновато и иногда не хватает математики… Давайте группироваться :)

Стучите в скайп или пишите в комменты — вместе будет веселее :)

QAClub Conf 1.1: по горячим следам

Решил порассуждать о своем докладе на QAClub Conf 1.1: Automation&Tools. Доклад был по паттернам построения фреймворка в автотестировании.

Сам доклад:

Если честно, я долго думал, прежде чем назвать это паттернами. И, как оказалось, не зря: Андрей Дзыня задал этот вопрос сразу после доклада: «Это на самом деле не дизайн паттерны из программирования. Это подходы».

Я согласен с тем, что те вещи, о которых я рассказывал, не входят в число описанных дизайн паттернов из разработки. Но как еще назвать то, что имеет четкие характеристики и повторяется от проекта к проекту? Шаблон? Скелет? Каркас? — Это ведь и есть по сути паттерн.

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

Получается, что сам инструмент, язык программирования, веб/десктоп — все это не важно, если рассматривать задачу с точки зрения построения тестового фреймворка. Суть не меняется.

Фреймворк может немного изменяться в рамках подходов (DDT, ODT, KDT, FD etc.), но я бы не сказал, что значительно. Просто каждому из этих подходов соответствует свой «рисунок» фреймворка, его структура. Это я и назвал паттернами, пусть это и не является классикой проектирования. Это я и попытался донести в рамках своего доклада.

Вместо вывода

Ребята, не изобретайте велосипед там, где это не нужно :)

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

Конференция по автоматизированному тестированию в Харькове

17 марта в Харькове состоится вторая конференция по автоматизированному тестированию.

Приходите, будет весело :)

Я буду рассказывать про паттерны построения фреймворков в автоматизированном тестировании. Тема сложная и длинная, постараюсь кратко и по сути.

Детали здесь

Backstage со мной

Подкаст «Тестирование: Backstage», в это раз со мной в главной роли.

Организаторы подкаста: Вика Мусияченко и Глеб Рыбалко.

О чем говорили в подкасте:

  • Как пришел в тестирование?
  • 1-й первый опыт в тестировании
  • О тестировании мобильных приложений
  • Aсcelerated Life tests
  • Построение отдела тестирования с нуля. Анализ ошибок
  • Задачи, которые приходится решать при менеджменте команды тестировщиков
  • Adhoc тестирование vs. процессно-ориентированный подход
  • Структура тестовой документации.
  • Как пришёл в автоматизацию тестирования
  • Настоящая и ненастоящая автоматизация
  • Стоит ли использовать инструменты тестирования для автоматизации?
  • Что нужно сделать для успешного старта автоматизации тестирования на проекте
  • Тех. поддержка AutomatedQA
  • Ошибки начинающих автоматизаторов
  • С какого языка программирования стоит начать, чтобы стать тестировщиком-автоматизатором
  • Собеседования тестировщиков-автоматизаторов

Если будут вопросы — с удовольствием отвечу в комментариях.

О собеседовании

Прислали забавный ролик о собеседованиях. Скорее всего, боян, но я не видел. Делюсь :)

Интересно порассуждать, какие из приемов, используемых в этом ролике, вы считаете хорошими/плохими и почему? Готов обсудить в комментах :)

Как развиваться?

Часто сталкиваюсь с ситуацией, когда люди не знают, как и куда развиваться. Давно зрела мысль написать свои имхи по этому поводу. Дошли руки :)

Поделюсь своим опытом и мыслями. Может, придам кому-то этим постом нужное ускорение :)

Зачем развиваться? — У каждого свои мотивы:

  • кто-то хочет больше денег
  • кто-то хочет признания
  • у кого-то просто шило в попе, и невозможно его удержать

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

  • отсутствие зарплатного роста в течение длительного времени (пока ваш уровень не догонит вашу зарплату. As soon as never, в общем, поскольку развития нет)
  • далеко не факт, что работа будет интересной. Если вас взяли на неадекватную вашим знаниям зарплату, то, вероятно, будут считать, что сделали вам одолжение, и будут требовать вдвойне. Соответственно, будете делать не то, что вам нравится, а то, что скажут. И права голоса особо не будет — тут же напомнят, что ваши коллеги получают намного меньше.
  • плохая репутация. И в резюме, и по жизни. IT город (будь-то Харьков, Киев, Днепропетровск) — небольшая деревня, где все друг друга знают, либо напрямую, либо через знакомых. Рекомендации найти можно практически на любого человека уровня мидл и выше. Если человек ушел один раз только ради зарплаты, при этом не попробовав сделать что-то, за что ему были готовы повысить зарплату на текущем месте работы, то к нему относятся крайне настороженно

А теперь давайте подумаем: оно того стоит?

В краткосрочной перспективе такой переход на +Х даст прибыль. Но в долгосрочной — это плохой вариант. Слишком много минусов можно получить взамен на эти +Х.

Что же делать? «Сидеть на попе ровно» (С) на одном месте? Уходить? Или оставаться?

Уходить с текущего места работы можно и нужно, если:

  • развитие опережает занимаемую должность и получаемую зарплату (на вас забили, грубо говоря. Причем давно и надолго)
  • вы понимаете, что занимаетесь не тем, чем хотите (например, шли на автоматизатора, а задачи вдруг превратились в написание sql-запросов для тестирования баз данных и другой работы нет)
  • невозможность роста вследствие орг-структуры компании (дослужились, например, до синьйора, а выше в компании никого нет и не будет — такая политика компании)
  • недовольны своим менеджером, пробовали решить, но он оказался полным неадекватом (вспоминаем известную фразу «приходят в компанию, а уходят от менеджера»). Заметьте, ключевое здесь — «пробовали решить»

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

Теперь переходим к вопросу «как развиваться?».

По пунктам. Кратко, жестко, местами обидно, все как в жизни:

  1. книги. Сколько вы прочитали за прошлый год? Если меньше двух — то задумайтесь… И не удивляйтесь, что ваш сосед, который читает 5-6 в год, растет быстрее, даже несмотря на то, что опыт работы у него меньше. Если больше двух, то второй вопрос: что вы из прочитанного применяете на практике? Если ничего — то вы либо читаете что-то не то, либо читаете то, но зря…
  2. план. Есть ли у вас план? Я про развитие, кстати… Если вам все равно, куда идти, значит вы не заблудились. Если плана нет, то не с чем сравнивать. Если не с чем сравнивать, то нет ожидаемого результата. Фактический результат без ожидаемого — это ведь не правильно (мы же тестеры, понимаем…)
  3. чужие ошибки. Если учиться только на своих ошибках, то научитесь вы к старости, когда уже будет поздно строить карьеру. Смотрите по сторонам и учитесь на чужих ошибках. Легко сказать, да?
  4. свои ошибки. Менее эффективный способ обучения, но он и проще. Не ошибается тот, кто ничего не делает. И поверьте, это понимает любой толковый руководитель. Ошибайтесь, не создавайте видимости, что вы ничего не делаете… В хорошем смысле, естественно…
  5. активность/проактивность. Если вы делаете только то, что вам скажут, вам очень повезет, если вы станете синьйором. Чаще это роль мидла, и не выше. От синьйора в числе прочего ждут умения найти задачу, взять ее и довести до конца, при этом понимая риски и беря на себя всю ответственность за ее выполнение.
  6. ответственность. Еще раз об этом отдельно. Если вы думаете, что зарплата будет расти, погоны будут жирнее, а все остальное останется как и было — то вы ошибаетесь. Пока вы не проявите желания брать на себя ответственность и не докажете, что можете с ней справляться, мало кто из нормальных менеджеров вас повысит (ему-то потом за вас все на себе тащить…)
  7. зона комфортности. Вспомните свой последний год. Если вам было всегда комфортно — значит что-то здесь не так… Развитие и рост — это постоянный выход за пределы зоны комфортности. Чтобы учиться, нужно делать не то, что вы умеете и знаете, а что-то новое. А это всегда дискомфорт. Если вы научитесь комфортно находится в зоне дискомфортности при изучении чего-то нового — развитие пойдет быстрее. Не буду расписывать слишком детально. Подумайте…

 

Если посмотреть на развитие с другой стороны, то можно еще это формализовать так:

Чтобы получать больше, нужно

  1. делать больше
  2. делать лучше
  3. делать другие задачи

Делать больше и делать лучше — это работает до каких-то разумных пределов, но сильно подняться это не поможет: в рабочем дне всего 8 часов, и делать больше вы не сможете. Делать лучше тоже не получится — быстро упретесь в потолок.

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

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

Можно быть очень хорошим дворником, но за эти задачи (за эту работу) не готовы платить много.

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

P.S. Если хотите развиваться, но не знаете, как — остановитесь, подумайте, проанализируйте ту роль, на которую вы хотите, формализуйте и распишите ее, составьте список скилов, которые на ней являются критичными и необходимыми, потом подумайте, чего из этого списка не хватает вам. Дальше ищите литературу/тренинги, набирайтесь знаний и пробуйте это все на практике. Если будет получаться и через пару недель вы не опустите руки — имхо, все должно получиться :)

Думаю, если кратко — то это все.

Happy New Year!

Всех с наступающим!
Набросал тут стишок (пардон за кривой английский, если вдруг что) :)

Long live the bugs! We need to thank them
Despite they ruin our soft.
For all the testers they are welcome
For all developers — are not.

This endless war for satisfaction
Will never end and never fail
No doubt, testing is an action,
That’s all a kind of fairy tail.

Let’s wish the tail to be inspiring,
Let’s bless the software issues, lags
We are the testers, we’ll be fighting,
We really make the world, not bugs!

HAPPY NEW YEAR!

Классы эквивалентности: advanced

Напишу некоторые свои мысли по поводу такого базового понятия в тестировании, как классы эквивалентности.

Теория.

Класс эквивалентности — это класс, в рамках которого все тесты являются эквивалентными.

Эквивалентные тесты — это тесты, которые приводят к одному и тому же результату.

То есть, если мы выполним два любых теста из одного класса эквивалентности — то получим один и тот же результат. Тут предполагается не результат «pass», а то, что мы идем по тем же самым шагам, используя другие данные и получаем аналогичный результат (с поправкой результата на эти самые другие данные, конечно).

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

Я бы разделил настоящий класс эквивалентности от предполагаемого. Дальше мои мысли.

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

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

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

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

Учитывая парадоксы 1 и 2, получается, что настоящий класс эквивалентности тестировать на границах нет смысла, а предполагаемый — не надежно. Зачем же тогда вообще нужны эти самые граничные значения? В разделе «практика» опишу свое видение.

Практика.

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

В настоящее время с этим есть проблемы:

  • Многопоточные приложения. Мы можем потратить кучу времени и докопаться до почти настоящего класса эквивалентности, но другой поток с легкостью может внести суматоху в наш тест, и в итоге он окажется не эквивалентным другому. А значит, и не находится в нашем классе эквивалентности.
  • Графика. Сейчас все больше приложений разрабатываются под тач-скрины. Естественно, что поля ввода заменяются на графические элементы, которые можно легко подвигать, переместить и т.п. Для графических элементов, на которых построен функционал, классы эквивалентности найти крайне тяжело. Если это и возможно — то не окупится…
  • Фреймворки. Сейчас приложения настолько активно используют фреймворки, что большинство внутренней логики и базового кода находится именно внутри используемых фреймворков, что в корне ломает все планы по использованию классов эквивалентности (их невозможно найти, не зная реализации функций фреймворка). Тут мы либо доверяем фреймворку и принимаем риск того, что могут быть ошибки, либо не доверяем и тестируем сам фреймворк вместо тестирования приложения, написанного на его основе.

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

Что же делать?

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

Как это работает?

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

 

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