В ожидании чудес

Канун Нового Года — время чудес. В преддверии нового года мы все вспоминаем год уходящий и строим планы на следующий. И надеемся, что все проблемы останутся в прошлом, а в новом году случится чудо, и мы заживём по-новому.

Какой же Java разработчик не мечтает о чуде, которое осенит его и позволит стать Самым Крутым На Свете Java Программистом.

Хорошие новости: я хочу рассказать как раз о таком чуде.

Имя ему — автоматические тесты!

Часть 2

Продолжение статьи о написании UI тестов на Cucumber с помощью Selenide. В первой части был разобран простейший пример smoke-теста для riskmarket.ru. В этой части апгрейдим тест до полноценного проекта с отчетами, поговорим о скриншотах, кастомных Condition, проаннотируем элементы, введем PageObject.

Получившийся проект вполне можно использовать как фундамент для ваших UI тестов.

Проект на гитхабе

Видео исполнения теста на youtube

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

В данной статье мы рассмотрим один из самых популярных фреймворков для автоматизации тестирования с использованием BDD-подхода – Cucumber. Также посмотрим, как он работает и какие средства предоставляет.

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

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

На протяжении 4-х лет у нас выработался следующий формат команды разработки:

• 1 Project Manager, он же Product Manager, он же Delivery Manager.
• 4-5 программистов
• 1 Team lead
• 3-4 QA
• 1 Аналитик
• 1 Техпис (иногда он же и аналитик в одном лице).

В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

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

Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.

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

Работая над статьей о роли требований в процессе разработки программного обеспечения я обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).

Хочу поделиться с читателями habrahabr данной классификацией.

Введение

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

Ниже приведена шкала уровней зрелости процесса управления требованиями, построенная по аналогии с моделью CMMI. Эти модели никак не связаны между собой, но имеют некоторое пересечение. Так, достижение уровня 5 (Интеграция требований) зрелости процесса управления требованиями позволит получить как минимум уровень 3 (Процессы определены на уровне всей организации) по модели CMMI. Однако это не является прямым следствием, так как достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом.

В тестировании ПО очень важна организация процесса: кто чем занят? Кто, что, когда тестировал? На какой сборке впервые появилась та или иная ошибка? Кто это тестировал? Какой у нас статус требований?

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

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

TestLink


TestRail


Sitechco


Получаем в результате: Triple Threat Match. Кто кого — увидим в честном бою.

Для начала, мы в команде определили критерии отбора:

• Стоимость лицензии: желательно бесплатно, или хотя бы, недорого;
• Поддерживаемые окружения: в команде используются Google Chrome, Mozilla Firefox, Safari — отказываться или менять браузеры никто не готов;
• Функционал управления тестами: здесь нам важнее всего было удобное создание тестовых наборов, ведение статистики прохождения и наглядной отчётности;
• Наличие элементов тест-менеджмента: очень хочется от инструмента возможностей планирования своих задач, контроля за планами и сроками;
• Юзабилити: если кому-то в команде что-то не понравится, то тратить своё время и “вникать” вряд ли будем. Всё должно быть понятно сразу.

По этим критериям и разберём каждого из кандидатов.

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

Я был немало удивлён, обнаружив, что на Хабре практически нет информации о модели CMMI, если не считать пары упоминаний здесь и здесь.
На западе уже давно крупные заказы по разработке ПО доверяются только компаниям, прошедшим сертификацию на соответствие какому-либо международному стандарту, зачастую им становится модель CMMI. Хотя сами авторы этой модели неоднократно повторяют, что это не стандарт, а всего лишь сборник рекомендаций по улучшению процессов внутри организации.

Что такое CMMI?

Википедия даёт следующее определение:

Capability Maturity Model Integration (CMMI) – Комплексная модель производительности и зрелости – набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.

Однажды менеджеры Лайв Тайпинг подумали: «Как хорошо было бы иметь инструкцию-чеклист, чтобы ничего не забыть перед публикацией приложения в стор. С ней можно перестать носить всё в голове и не объяснять вновь пришедшим менеджерам, что к чему, а просто скинуть гуглдок». Подумали и написали — для себя. Но потом поняли, что нехорошо скрывать полезную информацию от общественности. Поэтому мы надеемся, что инструкция поможет менеджерам всех остальных студий так же, как помогает нам.

Тема этой заметки — публикация приложения в App Store. Чуть позже мы опишем порядок действий для публикации в Google Play.

Что же нужно сделать PM`y в ходе публикации:

1. создать аккаунт в App Store для заказчика, если у заказчика его нет, или предложить
2. опубликовать приложение с нашего аккаунта;
3. подготовить маркетинговые материалы (иконка, скриншоты, текст, видео для предпросмотра приложения);
4. приложить к сборке сертификат цифровой подписи;
5. настроить оплату за пользование приложения;
6. Отправить сборку в App Store.

Идём под кат и разбираем по порядку.

Я аналитик, который пишет непонятные ТЗ. Т.е. я пытаюсь писать очень понятные ТЗ. В целом, я слушаю клиентов, потом я слушаю разработчиков, потом голоса в своей голове. Зачем я говорю с ними? В общем, получается то, что получается. Ну вы поняли.



Написать идеальное ТЗ проще простого:

1. Договорился о минимальном этапе (на 2-4 недели).
2. Описал юзер-стори по шагам.
3. Составил список экранов будущей системы.
4. Прописал названия методов API и форматы данных.
5. Запросил тестовый контент и составил таблицы с тестовыми данными.
6. Сформулировал из всего этого цели и задачи.
7. Согласовал план работ и выставил задачи в таск-менеджер.

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

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

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

SpecFlow позволяет использовать встроенные таблицы для Data Driven сценариев. В своей практике я столкнулся с двумя проблемами при таком подходе:

1. Иногда хочется, наоборот, получить авто-документацию из теста (например, тестирование API)
2. Когда количество данных велико, лучше хранить их где-то отдельно (часто для Acceptance Test Case'ов используют Excel)

Покопавшись в Gesigner Generated коде я смог решить обе проблемы.

Привет, Хабр!

В конце прошлой недели вышел долгожданный «мажорный» релиз инновационного баг-трекера YouTrack 4.0 с возможностью управления Agile-процессами. Об этом функционале мы и хотим вам рассказать немного подробнее.

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

В YouTrack 4.0 добавлен совершенно новый, независимый модуль для управления Agile-процессами, который без проблем подстроится под особенности реализации Scrum методологии или Kanban-процесса в вашей команде. Если же вы еще только осваиваете Agile-процессы, данный модуль станет прекрасным подспорьем в ознакомлении с ними, а также позволит комбинировать наиболее удобные для вас элементы каждого процесса.

Предисловие

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

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

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

P.S.: И последнее — данный текст бы никогда не сформировался, если бы не полезные лекции Алексея Баранцева и Натальи Руколь, а также пропасть информации, написанная добрыми людьми за последние годы по данной теме.

Вот теперь всё, вы предупреждены — можно начинать рассказ.

Доброго времени суток!

Предисловие

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

Введение

У меня за спиной огромный опыт работы с PHP, но сейчас я работаю Rails разработчиком. Огромную сложность для большинства людей, которые пытаются освоить что-то новое — это сам процесс обучения. Когда вы владеете каким-либо языком или фреймворком и знаете его вдоль и поперёк, переход на что-то новое не представляется необходимым.

Однако, изучение Ruby on Rails является достаточно простым занятием. Это невероятно мощный фреймворк, который имеет огромное сообщество, продвигающее его вперёд. Итак, у нас возникает вопрос: какой способ изучить Rails является лучшим? Вот он — план занятий.

В мире тестирования программного обеспечения набирает обороты совсем молодое направление — автоматизация тестирования мобильных приложений. И ожидаемо, что как грибы после дождя стали появляться соответствующие инструменты: Calabash, iOS Driver, Robotium, Selendroid, Appium. И именно про наши эксперименты с последним в мобильном тестировании я и хочу рассказать.

В последнее время Appium часто упоминают на конференциях и тут, на Хабре, было уже несколько постов о нем. Это фреймворк с открытыми исходным кодом, написанный на JavaScript и предназначенный для автоматизации тестирования мобильных приложений. По сути, это Selenium WebDriver, но для мобильных приложений. Appium позволяет управлять Safari и Chrome на соответствующих устройствах, а значит, и тестировать под ними веб-сайты, но обзор этих возможностей и нюансов, связанных с ними, — отдельная тема.

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