|
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 из которых критические! ПМ, придя в себя, отвечает – ок, какие из исправленных багов уже прошли ретест? Какие области приложения относительно стабильны? Что хорошего мы можем сообщить нашим заказчикам? |
|
Подробнее...
|
|
28.03.2017 11:54 |
|
 Автор: Александр Мешков
Оригинальная публикация
Не так давно, буквально три года назад, мир тестирования всполошила новость о том, что теперь наконец появится стандарт в области тестирования программного обеспечения, который будет выпущен как ISO (International Organization for Standardization).
Почему это так важно было для мира тестирования?
Тестирование достаточно молодая профессия и лишь небольшая часть в целом всей ИТ отрасли. Возьмите своих знакомых не из ИТ, и спросите, что они знают о тестировании?
— Тестирование? Что? Это анкеты заполнять? Программы? Не, не слышали?
И это не просто мнение знакомых, даже такие мировые стандарты в области управления ИТ, как COBIT5 или ITIL пишут всего пару строк о тестировании. |
|
Подробнее...
|
|
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-приложения имеют отличия от десктопных. Самое главное отличие и опасение — это то, что мы не знаем, в каком браузере и уж тем более — в какой версии этого браузера откроет приложение наш пользователь.
|
|
Подробнее...
|
|
23.03.2017 11:20 |
|
На прошедшем Я.Субботнике по тестированию, который проходил в Нижнем Новгороде 28 января, сотрудники компании Яндекс и приглашенные спикеры делились опытом работы в интересующей нас области. Темы докладов были разнообразными и интересными. Убедитесь сами - ниже вы можете ознакомиться с опубликованными материалами:
-
Облачные тестовые среды Яндекс.Маркета, Олег Бекетов, Яндекс
-
Back-to-back автотесты: практические вариации, Максим Свентух, Яндекс
-
1001 ночь QA-менеджера, Дмитрий Петунин, Intel
-
Тестовые базы данных как сервис, Василий Окунев, Павел Новицкий, Яндекс
-
Десктопные GUI-тесты на Python: Win32 API, MS UI Automation, и немного о будущем, Василий Рябов, Aquantia Rus
-
Анализ логов в тестировании — что объединяет QA, аналитику и DevOps, Ирина Пчелинцева, Яндекс |
|
Подробнее...
|
|
22.03.2017 12:15 |
|
 Автор: Коллин Грин (Collin Greene)
Оригинал статьи: https://medium.com/@collingreene/why-product-security-is-hard-52e3f73178#.l1376jjjv
Перевод: Ольга Алифанова
Если недостатки ПО могут стоить миллионы долларов, очень полезно исследовать вопрос, почему так тяжело создать безопасное ПО.
Работа над безопасностью вся целиком связана с трудностями, и цель статьи – собрать наиболее специфические для приложений сложности, чтобы в последующих статьях предложить их решения. Она не направлена на защиту безопасников -мол, без ошибок сделать ПО никак нельзя.
Создание ПО – тяжелая работа
Безопасность ПО – это очень трудно, но даже правильное создание программного продукта – непростая задача. Поиск багов безопасности – это подкатегория поиска багов в ПО.
Программное обеспечение кардиостимулятора, спутника или линкора должно, возможно, быть идеальным в плане безопасности, но для большинства приложений самыми важными будут время до релиза, количество фич и другие подобные цели.
Мы знаем, что создать идеальное ПО возможно, но это очень трудно, и зачастую не в приоритете. Nasa и марсоход "Curiosity" – это пример оптимизированного соотношения качества к нулевому количеству багов, потому что стоимость бага в ПО крайне высока. |
|
Подробнее...
|
|
21.03.2017 10:43 |
|
На юбилейной пятой международной IT-конференции Стачка в г. Ульяновске прозвучало множество докладов от специалистов в сфере информационных технологий. Ниже представлены доклады тех, кто представлял на конференции тему тестирования ПО.
-
Чернобров Михаил (Rambler & Co) поделился опытом тестирования фронтенда.
-
Ваказов Рамис (SimbirSoft) рассказал о важности внедрения тестирования на начальных этапах проекта.
-
Малейков Алексей (HTML Academy) изучал вопрос о регрессионном тестировании вёрстки. |
|
Подробнее...
|
|
|
|
