среда, 29 апреля 2015 г.

Определение критериев тестирования

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

Существует пять типов критериев, которые могут определяться перед началом системного тестирования.

Критерий входа описывает, что нужно сделать перед началом тестирования. Например,  возможно, потребуется располагать документами технического задания в окончательной форме. Можно поставить задачу, чтобы программный продукт был упакован в том же виде, в каком он будет поставляться заказчику. Во время тестирования может возникнуть необходимость в  служебных программах, конфигурационных файлах или данных, которыми будет пользоваться заказчик. Если на вас возложена ответственность  за проверку документации, сопровождающей   программный продукт, она также должна быть доступна во время тестирования. Один из способов выполнения критерия входа предусматривает проверку готовности к испытаниям. Эта проверка использует контрольную таблицу элементов действий, которые другие группы согласились передать как входные данных для тестирования. 

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

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

Критерий успешного/неудачного прохождения теста. Прогон каждого теста должен давать заранее известные результаты. Если получен ожидаемый результат, считается, что продукт  успешно прошел тест, в противном случае прохождение теста завершается неудачно. В то же время может случиться так, что прогон некоторой группы тестов не выполняется, поскольку они либо искажены или заблокированы  дефектами, либо  необходимые для их прогона ресурсы отсутствуют. Целесообразно определить заранее, что делать с тестами, которые не удалось  выполнить. Возможно, будет запланировано пометить каждый невыполненный тест буквой "N " в итоговом отчете и объяснить в поле комментария, что случилось и что было предпринято в контексте решения проблемы. Может быть, в ваши планы входит замена искаженных тестов  специальным видом тестирования и регистрация результатов в специальном акте об испытаниях.

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



среда, 22 апреля 2015 г.

Перший український Тестатон. Підсумки


Цими вихідними (18.04 - 19.04) було проведено Перший Український Тестатон. Дякуємо команді GoIT за організацію івенту. І, нарешті, настав час підвести підсумки. 

Чому варто було відвідати Тестатон?


По-перше,
Тестатон - це як хакатон, тільки для тестувальників (с), але не тільки...


Насправді, це захід, який від якого кожен може взяти те, що йому потрібно:
  •  тестувальникам не лише випробувати себе під тиском, познайомитися та допомогти українським молодим стартапам, а й отримати сторонній фідбек від професіоналів;
  • стартапам - протестувати продукт на різних системах, виявити невидимі для девелоперського ока дефекти та, можливо, отримати нових прихильників їхнього продукту.
По-друге,
насолодитися чудовомим краєвидом з 19 та 20го поверхів компанії Ciklum та познайомитися з такими ж кльовим людьми.

Що за стартапи?

Настав час відкрити цю таємницю для тих, хто так і не зміг цього разу взяти участь у Тестатоні. Першими двома відібраними стартапами стали:

Helper (iOS , Andoid) - он-лайновий консультаційний сервіс, де кожен учасник може як надати так і отримати консультацію від професіоналів, використовуючи месенджер та (відео-) дзвінки.

Pibox (Web) - соціалізован “хмарне” рішення для сумісного доступу до файлів та зберігання в середині Facebook.

Номінації та чемпіони:

Після довготривалого оцінювання, у кожній номінації Тестатону було визначено найкращого.
Наші переможці:

Igor Khovrichev - Best Web QA
Николай Левченко - Best iOS QA
Анна Надзуга - Best Android QA
Volodymyr Pershyn - Best Crasher
Виктория Нечаева - Best Quality Bug Report
Сергей Рудов - Most Valuable Web Bug
Денис Яременко - Most Valuable iOS Bug
Максим Филиппов - Most Valuable Android Bug
Та ті, хто відстав буквально на трошки:

Testathon Web Summary Results

Igor Khovrichev66.9
Берлинец Павел64.7
Pavel Potanin63.6
Яна Малецкая55.5
Ольга Чудинова52.7
Сергей Рудов51.3
Виктория Нечаева46.7
Владимир Глушков42.5
Ольга Шкурка41.6
Анастасия Шипко40.7
Алёна Мирошниченко38.2
Игорь Барановский31.1
Александр Ищенко 23.6
Sergey Pivenko22.7
Нагорняк Николай17.2
Жанна Бітюкова17.1
Igor Lavrynenko15.5
Виталий Мазурчук9.7
Сергей Иващенко9.4
Testathon Android Summary Results

Анна Надзуга32.9
Юлія Крамаренко32.4
Юлия Комарова30.1
Anna Polonska27
Ярослав Нагний25.1
Валентина Рашевская18.7
Валентина Лескова14.3
Максим Филиппов12.4
Vita Kucheruk1.5

Testathon iOS Summary Results

Николай Левченко46
Павел Бойко 45.6
Volodymyr Pershyn40.7
Денис Яременко39.4
Дима Голоцван23.4
Роман Бегун15.3
Ольга Макаревич15.1
Юлия Куприна8.2
Вита Омельченко3.5

Суддівський фідбек:

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

Web

 Oleksii Burdin
Hе вистачало секьюріті багів. Були на HTML, була парочка на JS у те саме поле, але не було жодної навіть найпростішої SQL-ін’єкції. Якби була - присудили Best Security Bug б тому, хто її написав. Але це все не дотягує до повноцінного тестування безпеки. І ще ніхто чомусь не користався різними шаблонами і плагінами для пошуку багів, як наприклад чудовий плагін BugMagnet для Firefox та BugMagnet для Chrome. 

Georgii Kurtanidze
Часто можно было встретить завышение севирити, отсутствие или неполное описание окружения(ОС, браузер, версия браузера, разрешение экрана). Участники делали больше фокус на интерфейс, чем на функциональность. Частое отсутствие Actual и Expected Result. Добавляли мало скриншотов, в основном не более одного на баг.

Android

Oleg Kuzych
Наиболее частые ошибки на Андроиде были: завышение severity, отсутствие логов при crash (stack trace), не всегда был указан environment, вместо одного бага на первопричину, заводили несколько багов на следствие.



Oleksandr Maidaniuk
Буду лаконічно: завищення, а тільки в деяких випадках заниження Severity у багів; відсутність скріншотів та креш-репортів у деяких учасників; відсутність планування і фокусу тільки на основний функціонал; хотілося більшого використання інстументів для тестування (debugging, memory leaks, logs). Дуже приємно вразили кількість знайдених багів за лімітованих 5 годин часу.

iOS

Shevchenko Maryna
На жаль, мало хто зробив перед початком тестування Smoke, щоб побачити загальну картину. Складалося враження, що тільки декілька фіч протестовані добре, а інші взагалі - ні. Часто стикалися з завищеним северіті та доданими креш логами без степів. 



Vladimir Primakov
Большинство тестировщиков проводили тестирование от частного, а не от общего - по этой причине многие баги были попросту упущенны и отсутствовал полный охват тестируемого приложения. Встречалось, некоректное задание северити, отсутствие указания версии тестируемого продукта и выделения проблемных областей на скриншотах. Еще, к сожалению, акценты тестирования в большинстве случаев были  сделаны на второстепенном функционале.


Трошки фото для заздрощів ;)









В планах провести командний тестатон. Stay tuned! 

четверг, 16 апреля 2015 г.

Testathon in Ukraine. Last chance to register!

Первый в Украине Тестатон
Как хакатон, только для тестировщиков ;)


Осталось буквально еще несколько мест для участия! Поспешите, регистрация заканчивается сегодня.

Снаружи ты – бывалый тестировщик, а в душе – пытливый непоседа?
На работе ты плаваешь в рутине и соскучился по “тест-драйву”?
Завидуешь программистам, которые зависают на своих хакатонах?


Мы придумали как встряхнуть тебя! Приходи на тестатон от проекта GoIT  и:


  • Насладись тестированием новинок от украинских стартапов
  • Собери свой Dream Team и познакомся с интересными людьми
  • Стань №1 в своей номинации
  • Помоги вырасти родным стартапам, которые всколыхнут мир (с твоей помощью)


Время: 18-19 апреля 2015, 11:00 - 17:00
Место: ул. Амосова, 12, офис Сiklum


Присоединяйся, протестируй самого себя, получи приз за лучший багрепорт и ощути своё влияние на развитие украинской IT-индустрии!


Участие – бесплатное, количество мест – ограничено. Для участия необходима предварительная регистрация.




Блок для “почемучек”:


Для кого это?
Тестатон для всех любознателных тестировщиков, жаждущих развития и новизны


Для чего это?
Посредством  тестатона мы отвечаем сразу на 2 вопроса:


  1. Как тестировщику не заскучать от работы и развиваться увлекательно?
  2. Как украинским стартапам, с ограниченным бюджетом, создать действительно качественный продукт?


Что будем тестировать?
Мы выбрали для вас 2 ярких проекта:
  1. Мобильное приложение на iOS и Android для получения косультаций из первых рук.
  2. Веб-приложение – “облачный” мессенджер для пересылки файлов.


Что для этого нужно?
  1. Твой мобильный девайс и/или лэптоп и зарядное устройство к нему :)
  2. Твоё непреодолимое стремление развиваться


Кто это придумал?
Идейные лидеры события: Александр Майданюк (Head of Quality Assurance Solutions at Ciklum Interactive и Head of QA Branch в GoIT) и Марина Шевченко (Mobile QA Engineer в Ciklum и Educational Consultant в GoIT).

Judges:
Поддержку в проведении оказала компания Ciklum.


Информационные партнёры мероприятия: QA Club Kyiv, AVentures,
TA Venture, Kyiv Startup Week, UA Web Challenge, IT Jam Meet&Mix, AIN, Brainbasket Foundation

понедельник, 6 апреля 2015 г.

Несколько рекомендаций по разработке стратегии тестирования

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

2. Тестируйте новые функциональные возможности и программный код, кото­рый изменялся с целью исправления или совершенствования старых функ­циональных средств. Эвристическое правило гласит: если программный код подвергался исправлениям, его необходимо протестировать. В начальной версии программного продукта новым является все. Однако если версия является оче­редным обновлением или эксплуатационной версией, особое внимание следует уделить новому коду. Имейте ввиду, что любые изменения, внесенные в про­граммный код, могут исказить даже те части программы, которые непосредственно "не затрагиваются" изменениями. В этом случае лучше всего как можно чаще выполнять регрессионные тесты для всей функциональности программы, какими бы ни были изменения в коде. 

суббота, 4 апреля 2015 г.

Структура показателей качества программного обеспечения.

1.Функциональные возможности (Functionality) 
- Пригодность (Suitability) 
- Правильность (Accuracy) 
- Способность к взаимодействию (Interoperability) 
- Защищенность (Security) 
- Согласованность (Compliance)
2 Надежность (Reliability) 
- Завершенность (Maturity)
- Устойчивость к ошибкам (Fault tolerance) 
- Восстанавливаемость (Recoverability) 
- Согласованность (Compliance) 
3 Практичность (Usability) 
- Понятность (Understandability) 
- Обучаемость (Lernability) 
- Простота использования (Operability) 
- Привлекательность (Attractiveness) 
- Согласованность (Compliance) 

четверг, 2 апреля 2015 г.

Типы приемочных испытаний (Acceptance Testing).

    Контрольные испытания (pilot tests), в условиях которых система устанавливается на экспериментальной базе с целью выяв­ления дефектов, представлены альфа- и бета-тестированием.
    Если пользователи принадлежат той же компании, что и разработчики, такое тестирование обычно называется альфа-тестированием (alpha testing). Если пользователями являются заказчики, готовые рабо­тать с программным продуктом еще до его официальной готовности, то такое тести­рование называется бета-тестированием (beta testing).

    Аттестационные испытания (benchmark test) - заказчик выполняет заранее определенный набор тестовых слу­чаев, имитирующих типичные условия, в которых система будет работать после ввода в эксплуатацию. Для аттестационных испытаний могут быть использованы тестовые случаи, которые разработаны и отлажены вашей тестирующей организацией и кото­рые в то же время были проверены и одобрены заказчиком. По завершении кон­трольных и аттестационных испытаний заказчик должен уведомить вас, какие требования не удовлетворены, а какие должны быть изменены, чтобы можно было перейти к заключительным испытаниям. 

    Заключительным типом приемочных испытаний является установочная проверка (installation   test), по условиям которой завершенная версия программного продукта устанавливается на площадках заказчика с целью получить от него подтверждение, что программный продукт соответствует всем требованиям и заказчик согласен на его поставку.