Home

"Альфа Лаборатория" —особое подразделение«Альфа-Банка»

В 2013 году мы взяли классический, сильный банк, умеющий хорошо управлять деньгами, добавили к нему digital-команду,построили wow-офис и создали «Альфа-Лабораторию». В Лаборатории мы занимаемся тем, что создаем продукты для коммуникации с нашими клиентами (людьми и компаниями)через digital-каналы. Наши продукты: «Альфа-Клик», «Альфа-Мобайл», «O!pp», «Альфа-диалог», «Альфа Бизнес-Онлайн»и «Альфа Бизнес-Мобайл» и др.

Мы – сообщество отличных людей с общими целямии классными ценностями. Мы люди, одержимые будущим и технологиями. Нам нравится всё новое и интересное, мы с радостью включаем всё примечательное в наши бизнес-процессы.Agile, KANBAN, Design-thinking — для нас не просто модные слова, они - важная часть нашей жизни. Мы любим хорошие идеи и людей, способных эти идеи создавать и воплощать. Мы находимся в постоянном поиске таких людей.
Мы не-просто-ходим на не-просто-работу.

Несмотря на то, что мы - банкиры, наш офис и распорядок жизни в нем ничем не напоминает банковский. Офис «Альфа-Лаборатории» - это особое пространство, где всё устроено так, чтобы нам было в нем просто хорошо. Мы также устраиваем кучу крутых вещей, позволяющих нам развиваться и развивать наши продукты. Мы придумали и делаем Alfa-Camp - долгосрочную программу поиска и развития стартапов, целью которой является реализация продуктов для онлайн-индустрии. Мы проводим Hackathon – событие, на котором наши внутренние команды не просто делают презентацию идеи, а создают работающие приложения, и это не проекты «в стол». Одно из таких приложений прошлого года стало стратегическим проектом «Альфа-Банка» в новом году. А ещё мы запустили программу iChooseAlfa, по которой уже несколько лет стажируются лучшие студенты сильнейших московских вузов. Мы нравимся тебе?

ЕСЛИ ТЫ РАЗРАБОТЧИК (JAVA, JAVASCRIPT, IOS, ANDROID), ДИЗАЙНЕР, PRODUCT OWNER, SCRUM MASTER, АНАЛИТИК ИЛИ ТЕСТИРОВЩИК, ТО МЫ ЖДЕМ ТЕБЯ В СВОЕЙ КОМАНДЕ!

Резюме присылайте по адресу: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript

Автор: Илья Ивасюв

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

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

Что такое «достаточность времени» и как ее рассчитать?

1. Определение
Итак, что подразумевается под «достаточностью времени», и чем «достаточное время» отличается от «номинального»? «Номинальное время» затрачивается на работу в идеальных условиях (без непредвиденных ситуаций). Но бывает ли так на практике?

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

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

Тестирование нуждается в постоянном улучшении, как и любой другой процесс. Возникал ли у вас вопрос “как улучшать”? Можно прибегнуть к конкретной методике, можно использовать отдельные принципы популярных практик... Но, прежде чем приступить к действию, можно прислушаться к специалистам, которые уже внедряют некоторые из них.

Ниже представлены записи докладов с конференции COMAQA Spring на тему улучшения процессов тестирования:

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

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Подписаться на рассылку можно по ссылке.

Оригинал статьи: http://www.ontestautomation.com/monitoring-the-quality-of-your-test-automation-code/

Автор: Баз Дийкстра (Bas Dijkstra)

Перевод: Ольга Алифанова

Если вы работаете в Agile-команде, то периодически вам придется (или "у вас будет возможность", зависит от ваших взглядов) браться за задачи, находящиеся вне вашей "зоны комфорта", или как минимум отличающиеся от ваших обычных дел. В течение нынешнего спринта у меня было свободное время, а в проекте накопился приличный технический долг, относящийся к качеству кода, и команда решила, что неплохо бы с ним частично разделаться. Я никоим образом не разработчик, но кое-что понимаю в коде (я и не шеф-повар, но ужин приготовить могу), поэтому я усмотрел в этом возможность получить дополнительный опыт по чтению, интерпретированию и правке кода. В нашем нынешнем проекте мы используем SonarQube в качестве платформы для управления качеством. Я никогда раньше не работал с этим инструментом, поэтому ничего особенного от него не ожидал, но пока что мне все нравится.

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

Аргумент "за": создание автотестов – это разработка ПО.

Успешное внедрение автоматизации требует к себе отношения, аналогичного отношения к любому другому проекту по разработке ПО: автоматизация требует планирования, внятного дизайна и наличия разработчиков автотестов, которые знают толк в своем деле. Почему бы не отнестись к коду автотестов так же, как и к коду продукта, вплоть до оценки его качества? Как и любой другой код, созданный в течение жизненного цикла ПО, код ваших автотестов должен быть читабелен и легок для поддержки. Под "легким для поддержки" я имею в виду возможность исправлять и дополнять его после того, как создавший автотесты гений перешел на другую должность или покинул компанию. Опять-таки, мы же поступаем так с кодом продукта, почему бы не поступать так с автотестами?

Оригинальная публикация: https://habrahabr.ru/post/329966/

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

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

Эти определения неверны.

Вот вам дедуктивное умозаключение:

Вписываясь в тестирование, мы желаем добавить продукту значимость (ценность) –
Добавление ценности продукту происходит за счет увеличения качества и надежности продукта – 
Добавление надежности продукта происходит путем поиска и удаления ошибок.

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

Оригинальная публикация: https://vc.ru/p/qa-test-game-services

Советы от QA-менеджера Crytek по тестированию игр, которые требуют регулярного обновления.

Чем дольше живёт проект — тем критичнее случайные баги. Внезапно появившиеся ошибки могут оттолкнуть значительную часть аудитории. QA-менеджер Crytek Евгений Скачков поделился на конференции Games Gathering 2016 опытом контроля качества проекта Warface, разработанного киевским филиалом компании.

Издание DTF опубликовало расшифровку выступления.

Про игру

Warface — онлайн free-to-play-шутер. Практически пять лет игра находится на стадии оперирования и больше восьми лет — в разработке. Это самый большой free-to-play-шутер на территории СНГ. Три года назад мы поставили официально зарегистрированный рекорд Гиннесса — 145 тысяч пользователей в онлайне на одном сервере.

Если посчитать по всем территориям, PCU (peak concurrent users) больше — около 200 тысяч человек. Ежедневно в игру заходят около 700 тысяч уникальных пользователей. Каждый год мы выдаём около 12 крупных обновлений.

Как происходит разработка обычного, «коробочного» продукта? Программисты и дизайнеры что-то создают, придумывают креативы, прототипируют и в какой-то момент решают, что игра готова. Её нужно протестировать. Что-то они проверяют своими силами, но этого недостаточно. Собираются QA-команды, и начинается «zerg rush».

Если вы тест-менеджер, на вас ложится ответственность организовать рабочий процесс в своей команде. И в идеале так, чтобы всем сотрудникам было комфортно. Задача не простая. Но спикеры, приглашенные на конференцию COMAQA Spring 2017, попытались с ней разобраться.

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

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

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

Ниже представляем записи докладов, где были озвучены эти и другие интересные тест-менеджеру вопросы: