Что пишут в блогах

Подписаться

Онлайн-тренинги

Разделы портала

Про инструменты

Лучшие вакансии

.
Плохие требования – кошмар тестировщика
13.06.2017 09:59

Оригинал статьи: http://www.testingexcellence.com/bad-requirements-software-testers-nightmare/

Автор: Намита Коли Арора (Namita Kohli Arora)

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


Реальный мир никогда не бывает переполнен розовыми пони, и то же самое справедливо для наших рабочих задач. Я множество раз сталкивалась с тест-проектами, которые были крайне далеки от идеала: в них отсутствовала даже самая базовая документация, и не было никакого намека на централизованное управление тестированием. Худшее, с чем я встречалась – это проекты, в которых или вообще не было требований, или эти требования были записаны абы как. Работа над такими проектами сводит меня с ума и стоит мне многих бессонных ночей (я не преувеличиваю – попытки разобраться в разрозненных информационных потоках заставляют мозг работать 24/7). Но нравится мне это или нет, такие проекты – наша реальность, и у нас нет выбора: с ними приходится иметь дело.

"Плохие требования" – довольно широкое понятие. К примеру, это могут быть:

Подробнее...
 
Супергерой в Альфа-Лабораторию
09.06.2017 12:04

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

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

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

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

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

Резюме присылайте по адресу: TMatskevich@alfabank.ru

Подробнее...
 
Почему важно выделить достаточно времени на проведение тестов?
07.06.2017 18:39

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

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

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

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

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

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

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

Подробнее...
 
COMAQA Spring 2017_Подборка об улучшении процессов тестирования
08.06.2017 08:13

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

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


Подробнее...
 
Карьера тестировщика, плюсы и минусы автоматизации, с чего начать специализироваться в тестировании: новости тестирования за вторую половину мая
06.06.2017 16:00

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

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

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

 
Качество кода автотестов
06.06.2017 07:32

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

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

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

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

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

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

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

Подробнее...
 
Психология тестирования (конечно же, не исчерпывающая). Личный перевод из книги «Искусство тестирования» Г. Майерса
05.06.2017 08:08

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

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

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

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

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

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

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

Подробнее...
 
Контроль качества в играх с сервисной моделью
02.06.2017 09:08

Оригинальная публикация: 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_Подборка об организации работы в команде
01.06.2017 08:33

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

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

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

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

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

Подробнее...
 
Тестирование: простая дорожка в IT или серьезная затея?
31.05.2017 08:15

Автор: Руслан Ахметзянов

Оригинальная публикацияhttps://habrahabr.ru/company/jugru/blog/327362/

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


— Расскажите, пожалуйста, немного о себе и своей работе. Как вы связаны с тестированием?

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

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

Еще спустя год (с апреля 2016 года) я стал руководить всем тестированием в «Одноклассниках», сохранив за собой и предыдущие позиции. В итоге сфера моих обязанностей довольно широка — чаще всего я могу назвать себя психоаналитиком в IT.

Подробнее...
 
Нужна ли специализация тестировщиков внутри одной команды?
29.05.2017 16:16

Автор: Юлия Миронова, ведущий специалист по тестированию компании "Лаборатория качества"

Оригинальная публикацияhttp://quality-lab.ru/do-you-need-specialized-testers-in-your-team/

Предыстория вопроса

 Давным-давно, когда деревья были большими, солнце светило ярче, а телефоны не работали без проводов, программисты делали все сами. Сами выясняли, что хочет заказчик, сами писали программу, сами ее тестировали. Прошли годы, отрасль расширилась, и появились первые специализации. Аналитик стал выяснять и описывать требования, дизайнер – продумывать внешний вид, разработчик – писать код, тестировщик – проверять, правильно ли все работает. В наше время тенденция увеличения численности команд тестирования поставила перед руководителями новый вопрос, который пока еще не имеет однозначного ответа: нужна ли специализация тестировщиков внутри одной команды?

Специализация: когда она работает на нас, а когда – против?

Для начала отметим некие общие принципы, которые нужно учесть.

Итак, специализация явно нужна в следующих случаях:

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