суббота, 28 февраля 2015 г.

Rapid Testing: Псевдоналагодження (debugging).


Псевдоналагодження (debugging) - це спосіб визначення ефективності стратегій тестування, що застосовуються в проекті.
Псевдоналагодження полягає в навмисному внесенні помилок в програму. Далі отримана версія тестується, і після цього визначається ефективність тестування шляхом порівняння знайдених і штучно створених помилок. Відношення числа знайдених штучно створених помилок до числа створених помилок має бути рівним відношенню числа знайдених помилок до числа прихованих помилок у продукті.

Цей метод дозволяє оцінити прогрес тестування.

пятница, 27 февраля 2015 г.

Rapid Testing: Негативне тестування.

Негативне тетування означає підхід, при якому тестувальник, розглядаючи програмний продукт в якості “чорного ящика”, визначає методи, як заставити продукт видавати невірні відповіді або взагалі перервати виконання. З’ясувавши у проектувальників, які вимоги повинні бути виконані перед запуском програми, спеціаліст по тестуванню може визначити набір тестових випадків для визначення реакції програмного продукту на недотримання однієї з цих умов.
Тестувальник застосовує спроби виконання програми:
  • на платформах, на яких її виконання не планувалось;
  • при відсутності комунікаційних ліній або при вводі неправильних вхідних даних;
  • при відсутності файлів даних, при відсутності записів в базах даних або при довільно переставлених даних в файлах даних;
  • при невірно введених іменах посилань або при невизначених, неправильних або відсутніх конфігураційних параметрах;
  • при вимкнених периферійних пристроях типу принтерів, сканерів, зовнішніх дисководів компакт-дисків або CD-RW, зовнішніх жорстких дисків, зовнішніх динаміків і т. д.
  • введення неправильних даних, що можуть бути у формі недопустимих даних, введених користувачем, випадково заповнених даними комунікаційних буферів, недопустимих значень в індексних файлах, переповнених журнальних файлів, в яких покажчик знаходиться в кінці файлу і т. д.

Здатність програми без збою витримати негативне тестування, називається стійкістю програми.

четверг, 26 февраля 2015 г.

Rapid Testing: Приховані помилки.

Приховані помилки - це помилки, що існують, але не виявлені. В середньому програми, що потрапляють до користувачів, містять від 0,2 до 20 прихованих помилок на 1000 інструкцій вихідного коду. У випадку інтенсивного застосування технологій статичного тестування при розробці проекту, до початку динамічного тестування кількість прихованих помилок має знизитись на 65-80%. Інші ж 20-25% прихованих помилок повинні бути виявлені на етапах:
  • тестування  модулів
  • комплексних випробувань
  • системних випробувань
  • приймальних випробувань
  • супроводу.
Всі приховані помилки розподілено за видами на незначні (Н), помірні (П), серйозні (С) та катастрофічні (К).
- Незначні (Н) приховані помилки - не впливають на дії користувача, програмний продукт з їх наявністю придатний для використання.
- Помірні (П) приховані помилки - впливають на дії користувача, але програмний продукт з їх наявністю придатний для використання з частковою втратою функціональності.
- Серйозні (С) приховані помилки - призводять до помилкових результатів, внаслідок чого програмний продукт непридатний до використання.
- Катастрофічні (К) приховані помилки - призводять до спотворення інформації (даних), внаслідок чого програмний продукт непридатний до використання і намагання його використати призводить до відмови системи.

среда, 25 февраля 2015 г.

Quality Built In @ Spotify от Андрея Дзыни: как стать лучшим тестировщиком?



Вы – тестировщик и стремитесь расти в дальше? Учитесь у самых лучших в отрасли! Присоединяйтесь к встрече от образовательного проекта GoIT с Андреем Дзыней – одним из лучших тестировщиков Украины.

Дата и время: 27 февраля, пятница, 19:00
Место: креативное пространство «Часопис», ул. Льва Толстого, 3.



Андрей Дзыня – инженер по тестированию ПО, тренер, консультант, спикер целого ряда отраслевых конференций, таких как: Agile EE 2013, HotCode 2013, Selenium Camp 2013, IT Brunch 2012 и другие. Реализовал массу успешных проектов как в Украине, так и в зарубежных компаниях. На данный момент занимает позицию Software Quality Engineer в компании Spotify.

Тема встречи Quality Built In @ Spotify

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


Встреча носит полузакрытый характер. Необходимо зарегистрироваться и получить подтверждение от организаторов. Тематика ориентирована на тестировщиков-автоматизаторов уровня middle / senior QA и выше.
Но, вы можете свободно присоединиться к онлайн-трансляции.


Участие во встрече бесплатное. Оплачивается только время пребывания в креативном пространстве Часопис.

*GoIT  масштабный образовательный проект, основная цель которого - создать бренд Украины как сильной IT страны!

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

Rapid Testing: Класичні помилки, що допускаються тестувальниками.


  1. Припущення, що програма працює коректно. Тестувальник завжди повинен припускати, що програма працює некоректно. Його обов’язки заключаються в тому, щоб віднайти ті моменти, які програма виконує неправильно, а не те, що вона робить правильно.
  2. Небажання реєструвати кожну виявлену проблему. Подібні ситуації часто виникають під час прогону тривалого тесту. Необхідно вести журнал записів, в якому фіксуються незначні відхилення від норми. Якщо вести точні записи, то в кінці тесту можна повернутися до виявленої проблеми і провести спеціальне дослідження з метою визначити, чи насправді це дефект.
  3. Ігнорування чи навіть приховування проблеми. Ця помилка може призвести до важких наслідків, в тому числі і викликати проникнення дефекту в середовище замовника. Завжди потрібно пам’ятати, що будь-який виявлений дефект може приховувати за собою цілий ряд інших, прихованих дефектів.
  4. Ви дозволяєте розробникам вмовити себе не складати повідомлень про дефекти, не маючи на те достатньо підстав. Перед тим як прийняти рішення ігнорувати той чи інший дефект, необхідно впевнитись у правильності цього рішення.
  5. Прагнення не псувати відносини з розробником. Цей вид помилки має відношення до попереднього пункту. Особисті образи, які виникають, коли хтось знаходить недоліки в чужій роботі, можна згладити, , якщо професіонально застосовувати відповідні інстументальні засоби і процедури аналізу дефектів.
  6. Недостатня увага плануванню випробувань. Якщо ваш процес не підтримується плануванням випробувань, то може статися так, що у вас залишиться занадто мало часу на підготовку до тестування наступної зборки.
  7. Написання докладних звітів про неіснуючі проблеми. Це бездарна трата часу.

вторник, 24 февраля 2015 г.

Rapid testing: Якості, якими повинен бути наділений ідеальний тестувальник:)


  1. Повинен вміти руйнувати програмні продукти, не відчуваючи при цьому ніяких докорів сумління. Оскільки тестування виконується з метою виявлення дефектів, тестувальник не повинен відчувати дискомфорту, знаходячи помилки в роботі іншого виконавця.
  2. Повинен вміти розробляти і виконувати покрокові процедури.
  3. Повинен вміти описувати послідовність подій і конфігурацію системи, які призводять до виникнення проблеми. Це включає здатність чітко документувати процедури і результати, уміння усно передати інформацію розробникам, іншим тестувальникам і керівництву.
  4. Вміти критикувати і коректно сприймати критику.
  5. Вміти приносити розробникам і керівництву погані новини. Якщо о 23:00 виявляється, що не вдається досягти готовності випуску програмного продукту, тестувальник повинен бути готовим повідомити керівництву цю прикру новину.
  6. Вміти протистояти тиску (тестування являється завершальним етапом будь-якого процесу розробки і, як правило, протікає у стресових умовах).
  7. Володіти гарними розумовими здібностіми, тобто легко і швидко освоювати нові технології.
  8. Бути терплячим - бути готовим виконувати прогони тестів стільки раз, скільки потрібно для того, щоб виявити проблему, після чого повторно виконати тести, щоб переконатися в коректному усуненні проблеми.
  9. Володіти гнучким мисленням - вміти швидко переключатись на тестування нового програмного продукту.
  10. Володіти здатністю одночасно бачити загальну панораму і вміти при необхідності зосередитись на деталях.
  11. Бути експертом у декількох областях - групі тестування можуть знадобитися спеціалісти по базам даних, по комунікаціям, по тестуванню GUI-інтерфейсів, по інструментальним засобам тестування, по сценаріям автоматизації, а також спеціалісти з інших областей.

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

Rapid testing: Інспекції та їх характеристики.

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

  1. В результаті інспекцій створюються списки помилок, для кожної з яких визначений рівень значимості, що характеризує пріорітет процесу її усунення. Список помилок заноситься в базу даних дефектів і використовується при внесенні змін в систему, покладену в основу майбутніх версій;
  2. В результаті інспекцій створюються версії контрольних переліків для одного чи більше етапів, на основі яких інспектори виконують аналіз основних причин виникнення дефектів. Ці контрольні переліки повністю готові до використання під час наступного виконання даного етапу в рамках поточного або іншого проекту;
  3. В результаті інспекцій визначаються показники, які управляють характеристичною моделлю помилок проекту і служать вхідними даними для програми оцінки похибки програмного забезпечення (SWEEP), яку використовують для прогнозування прихованих дефектів, що залишаються в самому програмному продукті. Ці показники служать також основою для постійного удосконалення процесу виконання інспекцій;
  4. Інспекції сприяють підвищенню кваліфікації інспекторів, які, вертаючись до виконання своїх обов’язків розробника, мають більш глибокі знання про продукт і вимоги, архітектуру, проект і запрограмовані алгоритми, а також про типи помилок, які варто відслідковувати під час роботи над їх власними робочими продуктами.

воскресенье, 22 февраля 2015 г.

Rapid Testing; Тестування “чорного” та “білого ящика”.

  1. Тестування “чорного ящика”. Якщо відомі конкретні функції, які повинен виконувати даний продукт, можна прогнати тести, що підтверджують повну працездатність кожної з функцій. Термін “чорний ящик” значить, що при розробці тестових випадків тестувальники нічого не знають про внутрішню структуру або код. Технології, що зазвичай застосовуються під час тестування “чорного ящика” називають технологіями динамічного тестування.
  2. Тестування “білого ящика”. Якщо відомі особливості роботи всередині продукту, можна виконати тести, які підтверджують, що внутрішня робота продукту проходить відповідно специфікаціям, а всі внутрішні компоненти використовуються правильно. Термін “білий ящик” означає, що при розробці тестових випадків тестувальники використовують будь-які доступні відомості про внутрішню структуру або код. Технології, що використовуються під час тестування “білого ящика”, зазвичай називають технологіями статичного тестування.

суббота, 21 февраля 2015 г.

Rapid Testing: Категорії дефектів.


  1. Новий - дефект був виявлений під час тестування, цей факт був відображений у звіті, але розробник не отримав розпорядження усунути проблему.
  2. Виправити - розробник отримав розпорядження усунути проблему, відповідні роботи ведуться.
  3. Відкласти - прийнято рішення відкласти роботу по усуненню дефекту до наступних випусків програмного продукту.
  4. Ігнорувати - дефект був отриманий помилково, програмний продукт працює у відповідності до проектного задуму.
  5. Виправлено - розробник виявив і усунув основну причину дефекту і виконав попередньо тестування, щоб переконатись, що проблема вирішена.
  6. Виправлено та перевірено - спеціаліст по тестуванню перевірив виправлення, використовуючи для цього таку ж методику тестування і конфігурацію засобів, як і під час попередньої перевірки.

пятница, 20 февраля 2015 г.

Rapid testing: Основні елементи шаблону тестового випадку:

  1. Ідентифікатор тестового випадку - включає номер версії тесту;
  2. Власник тесту - ім’я та ініціали особи, що використовує тест;
  3. Дата останнього перегляду - ця інформація дозволить визначити, чи є даний тест актуальним;
  4. Назва тесту - описове ім’я теста, яке дозволяє легко відшукати тест і зрозуміти його призначення;
  5. Місцезнаходження тесту - це повне ім’я шляху, включаючи сервер;
  6. Технічна вимога, що тестується - це повинен бути унікальний ідентифікатор, що відображається на документи з технічними вимогами;
  7. Мета тестування - коротке і чітке формулювання того, чого повинен досягнути даний тест;
  8. Конфігурація засобів тестування - специфікація вводу, специфікація виводу, умови випробувань;
  9. Налаштування на проходження тесту - це процедура схожа на методику тестування. Передбачає опис дій, які виконує тестувальник, і очікуваних результатів;
  10. Методика тестування - опис дій, які виконує тестувальник, і очікуваних результатів;
  11. Взаємозалежність тестових випадків - ідентифікація будь-якого тестового випадку, прогін якого повинен передувати прогону даного теста, щоб виконання даного теста починалось при заданих умовах;
12. Очистка тесту - якщо система була переведена у нестійкий стан або дані виявились зруйнованими, очистка надасть шанс позбавитись подібних ситуацій.




четверг, 19 февраля 2015 г.

Rapid Testing: План проведення випробувань.

Корисні рекомендації з розробки плану проведення випробувань пропонує стандарт IEEE Standart 829: IEEE Standart for Software Test Documentation. Згідно цього стандарту план проведення випробувань повинен містити 16 розділів:

  1. Ідентифікатор плану проведення випробувань;
  2. Вступ;
  3. Компоненти, що повинні тестуватись;
  4. Характеристики і властивості, що повинні тестуватись;
  5. Характеристики і властивості, що не повинні тестуватись;
  6. Підхід;
  7. Критерій успішних та невдалих випробувань;
  8. Критерій призупинення випробувань і вимоги відновлення випробувань;
  9. Вихідні результати тестів;
  10. Задачі тестування;
  11. Інформація про конфігурацію засобів тестування;
  12. Розподілення відповідальності;
  13. Підбір кадрів і підготовка персоналу;
  14. Графік робіт;
  15. Ризики та непередбачувані обставини;
  16. Затвердження плану проведення випробувань.

среда, 18 февраля 2015 г.

Rapid Testing: Планування випробувань.


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

  1. Визначення стратегії тестування: 1) визначити об’єм тестових робіт, шляхом аналізу документів з вимогами до програмного продукту; 2) визначити підхід до тестування, за рахунок вибору статичних і динамічних тестів, пов’язаних із кожною стадією розробки; 3) визначити критерії входу і виходу для кожної стадії тестування, а також всі точки контролю якості; 4) визначити стратегію автоматизації, якщо планується використання автоматизації якогось виду тестової діяльності.
  2. Визначення складу і структури випробувальної системи (апаратних і програмних засобів).
  3. Оцінка трудозатрат (ресурси і графіки робіт), яку можна розбити на п’ять етапів: 1) визначення задач, що повинні бути виконані;.2) оцінка працезатрат на вирішення окремих задач і всього життєвого циклу тестування; 3) визначення часу, необхідного для вирішення кожної задачі і тривалості всього життєвого циклу тестування; 4) побудова детального розкладу і поетапного графіка кожної тестової задачі;
  4. Оцінка ризиків невиконання графіка робіт.
  5. Підготовка і перегляд документів з планом проведення випробувань.

вторник, 17 февраля 2015 г.

Rapid Testing: Формулювання та тестування вимог.

Процес формулювання вимог включає такі стадії:
  1. Опитування замовника з метою з’ясування вимог, які він пред’являє до програмного продукту;
  2. Підготовка документу, що містить визначені вимоги;
  3. Підготовка специфікацій вимог;
  4. Підготовка матриці простежуваності вимог;
  5. Повторний перегляд вимог.

Сформульовані вимоги повинні відповідати таким критеріям:
  1. Кожна вимога повинна бути наділена унікальним ідентифікатором;
  2. Вимоги повинні бути представлені з точки зору користувача системи;
  3. Повинні бути включені як функціональні, так і нефункціональні вимоги.

Статичне тестування вимог. Метою даного тестування є перевірка вимог на повноту, однозначність, несуперечливість, наявність ідентифікаторів і можливість прослідковування, можливість тестування (статичного або динамічного) в процесі реалізації. Якісно виконане статичне тестування дозволить значно заощадити час і кошти. Найбільш поширеними методами статичного тестування є:
  1. Інспекції. Основною організаційною формою інспекції являється нарада, на якій робочий продукт аналізується з метою виявлення дефектів. Кожен учасник спеціально готується до наради, а сама нарада проводиться відповідно до спеціального набору правил. Виявлені дефекти документуються, результати наради публікуються.
  2. Наскрізний контроль. Представляє собою менш формальний захід, ніж інспекції, в тому сенсі, що від учасників не потребується спеціальної підготовки, за виключенням презентатора. При цьому ніякі звіти не вимагаються.
  3. Експертні оцінки. Перевірка вимог може бути виражена словесно або електронною поштою.

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