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

Подписаться

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

 Все онлайн-курсы

Конференции

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

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

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

.
Автоматизация мобильных приложений с SeeTest Automation
04.04.2017 08:45

АвторЕкатерина Батеева, Отдел автоматизированного тестирования, Тинькофф Банк

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

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

В нашем банке мы тоже наблюдаем эту тенденцию: мобильное приложение по сравнению с интернет-банком используют на порядок больше пользователей. Поэтому остро встал вопрос автоматизации тестирования мобильного приложения. Несмотря на повсеместное использование мобильных приложений, средства для их автоматизированного тестирования далеко не идеальны. Кроме того, мы предъявляем к ним высокие требования. Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.

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

Подробнее...
 
Характеристики качества
03.04.2017 08:17

Автор: Петтер Мален (Petter Måhlén)

Оригинал статьи: https://labs.spotify.com/2014/04/11/qualities-of-quality/

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

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

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

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

 


Подробнее...
 
Зачем и почему нужна тестовая документация?
30.03.2017 15:59

Автор: Антонина Бжассо

Оригинальная публикация: http://quality-lab.ru/the-purpose-of-test-documentation/

Давным-давно…

Когда-то в юности я начала работать сотрудницей отдела тестирования в одной компании. Тестовая документация там существовала в виде чек-листов в Excel и каких-то требований на 1-2 странички для разработчиков, куда также иногда могли заглянуть и тестировщики. Со временем компания перестала выделять время на написание ЧЛ, но документация для разработчиков все еще оставалась в более или менее достойном виде. Так как компания занималась обычной разработкой программного обеспечения для мобильных устройств, то поддерживать актуальной тестовую документацию и вообще её создавать для тестировщиков оказалось накладно. Спецификация стала редкостью.

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

— Мы закончили делать in-app покупку тем!
— Ad-hoc сборка уже собралась! Через час надо выложить!
— Ещё мы критические баги исправили и вот эту “штуковину” засунули в код.
— Прогоните какой-то смоук, вдруг что-то сломалось!
— и т. д.

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

— Слушайте, а кто-нибудь помнит, что тут было? Кто-то знает, как оно должно работать?
— Не помню уже. Надо спросить у разработчиков…
— Хм… Думаешь, я помню, что я делал три месяца назад? У меня 5 приложений! Я уже не помню, где и что я когда-то писал…
… (время уходит)
— Да не знаю. Ну, пусть так будет.
— У меня твой баг не повторяется. А-а-а… ты э-э-ту кнопку нажимаешь при выходе?.. А я всегда ту нажимаю…
— Слушай, а ты не помнишь, как мы проверяли такие подписки? И вот это каким должно быть? Кажется, оно не должно быть таким… Не помню.

И спросить не у кого. Специалистов, которые бы занимались документацией, нет. Тестировщиками часто проводилось полное тестирование приложения, что отнимало много времени – целые недели, а иногда, и месяцы. И на вопрос: “Когда вы закончите проверять?”, следовал ответ: “Критические баги лезуууут!” Не было четкого понимания, сколько времени необходимо для тестирования программы. А время, как известно, – деньги. В итоге получалось нечто, что начинало жить своей жизнью…

Подробнее...
 
Как приручить автотесты
30.03.2017 10:46

Автор: Дмитрий Мамонов, Департамент разработки, Wrike

Додо сказал:
— Правильность формы несущественна! А потом расставил всех без всякого порядка по кругу. Никто не подавал команды — все побежали, когда захотели.
Л.Кэрролл, «Приключения Алисы в стране чудес»

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

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

Подробнее...
 
Новости тестирования за вторую половину марта
29.03.2017 14:48

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

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

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

 
Тест-менеджер и прожект-менеджер: различия в мотивации и перспективах
29.03.2017 11:09

Автор: Шрини Кулкарни (Shrini Kulkarni)

Оригинал статьи: http://shrinik.blogspot.ru/2016/12/test-manager-vs-project-manager.html

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

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

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

Рядом со мной сидит мой друг и коллега, прожект-менеджер. Он вечно взволнован. Каждый раз, когда кто-то из моей команды просит разъяснений, у менеджера сбивается сердечный ритм, потому что он думает – о боже, нет, они нашли еще один баг! Во время наших встреч, посвященных багам, я гордо говорю, что сегодня мы нашли 40 новых багов, то есть всего за эту неделю – 370, 80 из которых критические! ПМ, придя в себя, отвечает – ок, какие из исправленных багов уже прошли ретест? Какие области приложения относительно стабильны? Что хорошего мы можем сообщить нашим заказчикам?

Подробнее...
 
ISO 29119 Testing Standard. Что такое? О чем? И главное зачем?
28.03.2017 11:54

Автор: Александр Мешков

Оригинальная публикация

Не так давно, буквально три года назад, мир тестирования всполошила новость о том, что теперь наконец появится стандарт в области тестирования программного обеспечения, который будет выпущен как ISO (International Organization for Standardization).

Почему это так важно было для мира тестирования?

Тестирование достаточно молодая профессия и лишь небольшая часть в целом всей ИТ отрасли. Возьмите своих знакомых не из ИТ, и спросите, что они знают о тестировании?

— Тестирование? Что? Это анкеты заполнять? Программы? Не, не слышали?

И это не просто мнение знакомых, даже такие мировые стандарты в области управления ИТ, как COBIT5 или ITIL пишут всего пару строк о тестировании.

Подробнее...
 
COMAQA Winter 2017: видеозаписи докладов с конференции, 1 поток
27.03.2017 10:27

В конце февраля сообществом COMAQA.BY была организована очередная конференция COMAQA Winter 2017. Спикеры из ведущих IT-компаний собрались вместе, чтобы рассказать о своем опыте в тестировании. Конференция проходила в два потока. Сегодня мы хотим поделиться записями докладов, озвученных в первый день, в которых:

1. Роман Сорока рассказал про логические инструменты в арсенале тестировщика.

2. Александр Павлов в своём выступлении “Эволюция браузерных тестов” поделился опытом работы с Selenium.

3.Дмитрий Татти выступил на тему “Тест длиною в паранойю” о рациональности внедрения автоматизации тестирования.

4. Роман Иовлев пытался заглянуть в будущее автоматизации тестирования.

5. Дмитрий Лемешко осветил ряд вопросов по тестированию мобильных приложений

6. Вадим Мустяца представил тему “Alfa-BDD: Как масштабировать BDD и побеждать айсберги”

7. Филипп Кекс поделится собственным опытом и об автоматизированном тестировании в играх.

Подробнее...
 
Тестируем кроссбраузерную совместимость — на что важно обратить внимание
24.03.2017 14:07

Автор: Татьяна Бирюкова

Оригинальная публикация: http://quality-lab.ru/cross-browser-compatibility-testing/

Как часто заказчики ПО хотят, чтобы их детище работало у любого пользователя, в любых условиях и окружениях? Здесь будет уместен ответ — всегда. Что же скрывается за этой фразой? Что именно требуется для проверки от тестировщика? И как он будет воплощать требования в жизнь?
Не секрет, что WEB-приложения имеют отличия от десктопных. Самое главное отличие и опасение — это то, что мы не знаем, в каком браузере и уж тем более — в какой версии этого браузера откроет приложение наш пользователь.

Подробнее...
 
Я.Субботник по тестированию 2017: подборка видеозаписей выступлений
23.03.2017 11:20

На прошедшем Я.Субботнике по тестированию, который проходил в Нижнем Новгороде 28 января, сотрудники компании Яндекс и приглашенные спикеры делились опытом работы в интересующей нас области. Темы докладов были разнообразными и интересными. Убедитесь сами - ниже вы можете ознакомиться с опубликованными материалами:

  1. Облачные тестовые среды Яндекс.Маркета, Олег Бекетов, Яндекс

  2. Back-to-back автотесты: практические вариации, Максим Свентух, Яндекс

  3. 1001 ночь QA-менеджера, Дмитрий Петунин, Intel

  4. Тестовые базы данных как сервис, Василий Окунев, Павел Новицкий, Яндекс

  5. Десктопные GUI-тесты на Python: Win32 API, MS UI Automation, и немного о будущем, Василий Рябов, Aquantia Rus

  6. Анализ логов в тестировании — что объединяет QA, аналитику и DevOps, Ирина Пчелинцева, Яндекс

Подробнее...
 
Почему безопасность продукта – это такая сложная штука
22.03.2017 12:15

Автор: Коллин Грин (Collin Greene)

Оригинал статьи: https://medium.com/@collingreene/why-product-security-is-hard-52e3f73178#.l1376jjjv

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

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

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

Создание ПО – тяжелая работа

Безопасность ПО – это очень трудно, но даже правильное создание программного продукта – непростая задача. Поиск багов безопасности – это подкатегория поиска багов в ПО.

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

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

Подробнее...