Теорія тестування

ЖЦ дефекту

New Opened Assigned (Deferred Rejected Duplicate) Fixed (Reopened->Assigned) Verified Closed

Яка різниця між пріоритетом і серйозністю?

1. Severity атрибут, що характеризує вплив дефекту на працездатність програми 2. Priority атрибут, що визначає пріоритет бага, виставляється PjM або Scrum master, таким чином визначаючи першочерговість виправлення бага на тлі інших багів

Фундаментальний процес тестування

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

Принципи тестування

1. Тестування показує наявність дефектів Тестування може показати наявність дефектів у програмі, але не довести їхню відсутність. А все-таки, важливо складати тест-кейси, які знаходитимуть якнайбільше багів. Таким чином, при належному покритті тестування, тестування дозволяє знизити ймовірність наявності дефектів в програмному забезпеченні. У той самий час, навіть якщо дефекти були знайдено у процесі тестування, не можна стверджувати, що їх немає. 2. Вичерпне тестування неможливе Неможливо провести вичерпне тестування, яке б покривало всі комбінації введення користувача і станів системи, за винятком зовсім примітивних випадків. Натомість необхідно використовувати аналіз ризиків та розстановку пріоритетів, що дозволить більш ефективно розподіляти зусилля щодо забезпечення якості програмного забезпечення. 3. Раннє тестування Тестування має починатися якомога раніше у життєвому циклі розробки програмного забезпечення, і його зусилля мають бути сконцентровані на певних цілях. 4. Скупчення дефектів Різні модулі системи можуть містити різну кількість дефектів - тобто щільність накопичення дефектів в різних елементах програми може відрізнятися. Зусилля з тестування повинні розподілятися пропорційно до фактичної щільності дефектів. В основному, більшість критичних дефектів знаходять в обмеженій кількості модулів. Це прояв принципу Парето: 80% проблем містяться у 20% модулів. 5. Парадокс пестициду Проганяючи ті самі тести знову і знову, Ви зіткнетеся з тим, що вони знаходять все менше нових помилок. Оскільки система еволюціонує, багато раніше знайдених дефектів виправляють і старі тест-кейси більше не спрацьовують. Щоб подолати цей парадокс, необхідно періодично вносити зміни до наборів тестів, рецензувати і коригувати їх з тим, щоб вони відповідали новому стану системи і дозволяли знаходити якомога більшу кількість дефектів. 6. Тестування залежить від контексту Вибір методології, техніки та типу тестування безпосередньо залежатиме від природи самої програми. Наприклад, програмне забезпечення для медичних потреб вимагає набагато суворішої та ретельнішої перевірки, ніж, скажімо, комп'ютерна гра. З тих же міркувань сайт з великою відвідуваністю повинен пройти через серйозне тестування продуктивності, щоб показати можливість роботи в умовах високого навантаження. 7. Помилка про відсутність помилок. Той факт, що тестування не виявило дефектів, ще не означає, що програма готова до релізу. Знаходження та виправлення дефектів будуть не важливими, якщо система виявиться незручною у використанні, і не задовольнятиме очікування та потреби користувача. І ще кілька важливих принципів: — тестування має проводитись незалежними фахівцями; - Залучайте кращих професіоналів; - Тестуйте як позитивні, так і негативні сценарії; — не допускайте змін у програмі у процесі тестування; - Вказуйте очікуваний результат виконання тестів.

Характеристики гарних вимог

1.Недвозначність — має існувати лише одне трактування вимоги. Так, наприклад, слід уникати у тексті вимог скорочень. 2.Перевіряємість - тестувальники повинні мати можливість перевірити, чи правильно вимога реалізована в системі. Для цього вимога має бути чіткою, точною, недвозначною. 3.Чіткість (короткість) - вимога не повинна містити зайвої інформації. Воно має бути викладено чітко та просто. 4. Точність - вимога повинна містити справжні факти. 5.Зрозумілість - вимога не повинна містити граматичних помилок, має бути викладена послідовно. 6.Здійсненість - вимога має бути здійсненна в рамках чинних обмежень (час, гроші, чинні ресурси) 7.Незалежність - для розуміння вимога не потрібно знати інших вимог. 8.Атомарність - вимога має містити одну пов'язану сутність. ("і", "або", "але" відсутні). Приклад: Користувач може авторизуватися та вибрати собі каталог для завантаження фотографій» 9.Необхідність — зацікавлені особи повинні потребувати цієї вимоги. 10. Абстрактність - у вимозі не повинно міститися інформації про те, як воно буде реалізовано. 11. Постійне - не повинно бути конфліктів між вимогами. (mm/dd/yyyy dd/mm/yyyy). 12. Ненадмірність - кожна вимога повинна бути описана один раз і не повинна містити в собі інших вимог. 13. Повнота - вимога має бути визначена для всіх можливих ситуацій (текст вимоги не вимагає додаткової деталізації, тобто в ньому передбачені всі необхідні нюанси, особливості та деталі цієї вимоги). 14. Модифікованість - якщо вимога атомарна і повна, вона модифікується (його можна переробити або переробити). 15. Трасування (простежуваність) - якщо вимога атомарна і має унікальний ідентифікатор, вона простежується. (Приклад: для реалізації ВR1 були реалізовані FR1 та FR2) Стандарти, що відповідають за вимоги: IEEE 830, RFC 219

Що таке Exploratory testing?

Одночасно є видом і технікою тестування. Мета такого тестування вивчення проєкту, функціоналу, проєктування тест-кейсів і в розумі й тут же їх виконання, не записуючи й не створюючи тестову документацію (або створюючи під час знайомства з системою). Мета - заглибитися у знання продукту та знаходити баги "на льоту".

Навіщо тестувати ПЗ?

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

Що таке техніка аналізу граничних значень? У чому цінність цієї техніки?

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

Що таке техніка аналізу класів еквівалентності?

(Еквівалентне розбиття)розробка тестів методом чорного ящика, в якій тестові сценарії створюються для перевірки елементів еквівалентної області. Як правило, тестові сценарії розробляються для покриття кожної області як мінімум один раз (Еквівалентна область)-частина області вхідних або вихідних даних, для якої поведінка компонента або системи, ґрунтуючись на специфікації вважається однаковою

Детально про етапи SDLC під час розробки IT-продукту

0. Ініціювання Необхідно з'ясувати бізнес-мету та потреби замовника, розробити так звану концептуальну пропозицію-Product Vision 0. Розробка концепції системи 1. Планування та - виявлення ризиків Визначення проблем, цілей та ресурсів (таких як персонал та витрати) - Як зробити Ваш продукт кращим, ніж у конкурентів? - За наявності будь-якої вже готової версії програми після аналізу цих даних у вас буде три варіанти: розробляти нову систему, покращити існуючу або залишити систему як є 2. Збір, аналіз та розробка вимог Найбільш важливий та фундаментальний етап у SDLC, виконується за участю клієнтом, експертів у доменній області та команди, проводиться аналіз ринку та конкурентів Визначаються бізнес-вимоги до продукту - який зиск принесе створення цієї системи замовнику (BRD-Business Requirements Document) Чітке визначення та документування вимог до продукту та їх затвердження від клієнта. Це робиться за допомогою документа SRS. На цьому етапі можна тестувати специфікацію. 3. Дизайн та проєктування архітектури продукту SRS - це орієнтир для розробників, щоб запропонувати кращу архітектуру для продукту. На основі вимог пропонується зазвичай кілька підходів до проєктування архітектури, що документуються у специфікації DDS Проєктування визначає модулі, представлення потоку даних, а також взаємодія із зовнішніми модулями та системами 4. Створення/Розробка продукту 5. Тестування* ЦЕЙ ЕТАП Є ПІДМНОЖИНОЮ ВСІХ ЕТАПІВ у гнучких методологіях Але саме на 5-му етапі дефекти реєструються, відстежуються і виправляються. Потім повторно продукт тестується доти не досягне стандартів якості, описаних у SRS документі. 6. Впровадження та розгортання продукту на ринку Іноді розгортання відбувається поетапно. Продукт може бути спочатку випущений в обмеженому сегменті і протестований в реальному бізнес-середовищі, наприклад, можна проводити UAT testing (User Acceptance Testing - тестування комп. сист. КЛІЄНТОМ, щоб перевірити, чи відповідає сист. вимогам) 7. Експлуатація та обслуговування Команда супроводжує продакшн версію ПЗ. Також на даному етапі SDLC-система оцінюється, щоб переконатися, що вона не застаріла. Можуть вноситись зміни у процес та у вихідне програмне забезпечення для впровадження оновлень. Також проводиться знову оцінювання, чи відповідає система спочатку заявленим вимогам, чи надійна система і відмовостійка. 8. Диспозиціонування (Утилізація) На даному етапі розглядаються способи припинення використання системної інформації, апаратного та програмного забезпечення та переходу на нову систему. Важливо це зробити таким чином, щоб запобігти несанкціонованому доступу до даних, що архівуються або знищуються. Хорошим прикладом як відбувається вилучення та з експлуатації є Google Music (за пів року користувачів додали, що ця програма буде закрита та відкритий ЮТУБ МУЗИК і перенесли користувачів та їх плейлист у новий сервіс)

Які рівні тестування знаєте?

1. Компонентне тестування (модульне) Компонентне тестування (також відоме як модульне) займається пошуком дефектів та верифікацією функціонування програмних модулів, програм, об'єктів, класів тощо. які можна протестувати ізольовано. Unit - найменша функціональна частина програми або програми, яка не може функціонувати окремо, а лише у поєднанні з іншими модулями. Але після розробки модуля його вже можна тестувати. Компонентне тестування проводиться з доступом до коду, що тестується, і з підтримкою робочого оточення, такого як фреймворк модульного тестування або утиліти налагодження. Насправді компонентне тестування зазвичай проводиться розробниками, які пишуть код. Отже, цей рівень тестування використовує метод Білого ящика. Якщо тестувати цей рівень методом Чорного ящика, то об'єктом тестування буде лише якийсь функціонал 2. Інтеграційне тестування Перевіряється інтеграція модулів, їхня взаємодія між собою, а також інтеграція підсистем в одну загальну систему. Проводиться після Юніт Тестування, щоб переконатися, що 2+ модулі успішно працюють разом. Інтеграційне тестування перевіряє інтерфейси між компонентами, взаємодію різних частин системи, таких як операційна система, файлова система, апаратне забезпечення, та інтерфейси між системами. 3. Системне тестування Тестування програмного забезпечення, що виконується на повній, інтегрованій системі, з метою перевірки відповідності системи вихідним вимогам, як функціональним, так і нефункціональним 4. Приймальне тестування Тестування, яке проводиться на етапі здачі готового продукту (або готової частини продукту) замовнику або кінцевому користувачеві. Приймальним тестуванням системи найчастіше займаються замовники чи користувачі системи, а також інші зацікавлені особи.

Які є етапи тестування?

1. Планування тестів 2. Тест-дизайн 3. Виконання тесту 4. Аналіз результату та звітність АБО Усього заведено виділяти 7 етапів тестування: 1. Робота із вимогами. Знайомство з вимогами замовника, що має являти собою підсумковий продукт, обговорення. Ретельне вивчення вимог має: -виявити супротивність вимог; -допомогти визначити потенційні дефекти у функціоналі. 2. Розробка стратегії тестування. Цей етап є важливим для лідів або менеджерів, оскільки від розуміння отриманої на попередньому етапі інформації залежить якість тестування. Тест - лід повинен: -резюмувати отриману інформацію, -оцінити терміни тестування, -розробити стратегію тестування: визначити види тестування, які можна застосувати до проєкт, проаналізувати наявні середовища та ресурси, що є для проведення тестування, описати пріоритети для непередбачених ситуацій, як і де буде вестися тестова документація; -визначення середовища тестування: яке обладнання необхідне для тестування, -скласти план, який містить опис, з чого починається і чим закінчується тестування, і що тестуватиметься. 3. Створення тестової документації. Мета цього етапу - створити документацію, обсяг якої охоплюватиме деталізацію, хід робіт, а також вноситиме ясність для замовника. Спілкування з іншими командами, розуміння бажань замовника впливають на якість тестової документації. Після проведеного тестування, можна проаналізувати його успішність. Тестова документація може складатися з: -тестових сценаріїв: що і як перевірятиметься при регрес-, димовому та приймальному тестуваннях; -звітності: результати тестування, списку багів та їхня серйозність; -методологій тестування Деталізація тестової документації залежить від проєкту, тому вона може відрізнятися і за охопленням, і за форматом, і за обсягом. Для тестувальника важливо підтримувати документацію в актуальному вигляді, вносити зміни, пов'язані зі зміною підсумкового продукту. 4. Тестування прототипу. При створенні та тестуванні прототипу продукту необхідно виявити основні відхилення від очікуваного результату та відповідність до бізнес-стратегії. Тут же виявляються помилки у роботі логіки основного функціонала, усуваються знайдені вразливості та дефекти, допущені на етапі розробки. Замовник може сам брати участь у процесі тестування прототипу, що він міг оцінити, якому етапі перебуває розробка продукту. Після тестування висуваються побажання замовника. Нові побажання необхідно задокументувати, оцінити терміни, впровадити у проєкт та передати на огляд замовнику. Найкращий спосіб тестування прототипу - проведення закритого бета-тестування, коли препарат тестує продукт мала кількість людей, які в результаті будуть використовувати його після релізу. Це допомагає врахувати побажання кінцевих користувачів. Дуже важливо ліду чи менеджеру проєкт передавати інформацію тестувальникам та розробникам про побажання замовника, на які часті збої в продукті натикалися користувачі для того, щоб зробити його зрозумілішим. 5. Основне тестування. Тестування програмного забезпечення є найтривалішим та об'ємним процесом. Тут формуються репорти про знайдені дефекти, виконується набір тестових сценаріїв, створюється тестове середовище, виконується тестування, види якого задокументовані на етапі створення тестової документації. Смоук- та регрес-тестування є одними з основних видів тестування, які проводяться на даному етапі. 6. Стабілізація. На цьому етапі закінчується робота із побажаннями замовника. Протягом створення онлайн-ресурсу команда розробників займалася своїми справами, реалізуючи «хотілки» замовника, а тестувальники репортували про нові дефекти. А на етапі стабілізації розробники починають слухати тестувальників, усуваючи те, що працює, але некоректно. Якщо продукт існує у якійсь великій системі, то цьому етапі також перевіряється комунікація системи та продукту, тобто проводиться інтеграційне тестування. 7. Експлуатація. Після усунення дефектів команда розробників переходить на етап тестування продукту в продакшн середовищі. Оскільки багато хто ставить крапку на проєкт після релізу, дуже важливо відзначити, що тут відбувається не тільки реліз продукту, а й пост-релізова підтримка. При всьому бажанні не можна врахувати всі нюанси використання, відтворити те середовище, в якому буде використано продукт. Тому на даному етапі необхідно наголосити на тому, що кажуть користувачі, важливо прислухатися до їхньої думки, оскільки вони беруть участь не тільки у використанні продукту, але й тестуванні, натикаючись на знайдені помилки. Ваш продукт стає частиною життєдіяльності людей, тому усунення дефектів та їх пошук проводяться швидко, але ретельно. Не завжди кінцевий користувач може надати інформацію про те, що він зробив для отримання помилки, тому за повторення дефекту береться команда QA.

Які типи тестування можете назвати?

1. Функціональне тестування 2. Нефункціональне тестування 3. Структурне тестування Структурне тестування направлено на тестування структури системи або компонента. Цей вид тестування, як правило, відносять до тестування «білого» та «сірого» ящиків, оскільки ми перевіряємо, що відбувається всередині системи або додатка. Методи структурного тестування: -Строкове покриття (Statement Coverage) - перевірка застосування усіх операторів в програмі на використання (хоча б один раз). -Покриття шляху (Path Coverage) - метод тестування, призначений для задоволення критеріїв охоплення кожного логічного шляху через програму. -Покриття рішення (Branch Coverage) - перевіряє, чи має кожна умова розгалуження для програми дійсні чи хибні значення; -Покриття умови (Condition Coverage) - метод, схожий на Branch Coverage, основна відмінність полягає в перевірці стану покриття для умовних і неумовних гілок. 4. Тестування змін При тестуванні змін в системі дуже важливо зрозуміти різницю та межу між поняттями регресійне тестування (Regression testing) та повторне тестування (Retesting). -Регресійне тестування (Regression testing) проводиться з метою перевірки працездатності функціоналу, що існує, та перевірки на відсутність сторонніх помилок після оновлення білда (внесення правок або доповнень в систему). -Повторне тестування (Retesting) - проводиться для підтвердження виправлення помилки та роботи даного функціоналу.

Які існують UI-стандарти?

10 Правил оформлення UI від Якоба Нільсена 1. Інформативність системи (користувач завжди повинен знати статус системи. Користувачеві має бути зрозумілою взаємодія з системою) 2. Схожість системи з реальним світом (не використовувати специфічні терміни, а слова з реального життя) 3. Свобода дій (скасування, повернення дії, відновлення, видалення та інше) 4. Єдині стандарти (використовувати одні й самі речі й одні й самі терміни) 5. Запобігання помилкам (звести до мінімуму кількість умов, за яких можуть виникати помилки, давати користувачеві наочний приклад та підказки) 6. Наочність (користувач не повинен ламати голову в спробах зрозуміти як він досяг того чи іншого стану) 7. Гнучкість та ефективність (надавати досвідченим користувачам можливість уникати рутинних дій та приховувати розширені можливості від недосвідчених) 8. Естетичний та мінімалістичний дизайн. 9. Розуміння проблем та їх вирішення (помилки повинні бути точно і зрозуміло описані, а також є пропозиція їх вирішення) 10. Довідкові матеріали та документація (очевидне теж потрібно документувати)

Опишіть основні фази STLC? Дайте визначення Entry та Exit Criteria.

6 основных этапов SDLC: Planning Analysis Design Implementation (реализация) Testing & Integration Maintenance ПС у Кулікова є гарний опис Entry та Exit Criteria.

Що таке випробування на основі ризиків?

Risk based testing — це тестування проекту з увагою на ризики. Risk based testing — використовує ризики як метод для визначення пріоритетності та виокремлення певних тестів у процесі тест дизайну. Логіка Тест Дизайну Виходячи із того, що Ризик — це ймовірність виникнення небажаного результату. І цей результат пов'язаний з впливом. Тестування на основі ризику передбачає в першу чергу тестування функціональностей, які мають найбільший вплив та ймовірність збою. І у найбільш критичних місцях. Risk-based testing включає аналіз та вимірювання метрик у цих критичних місцях Коли недостатньо часу для тестування всіх функціональних можливостей, ми таким самим чином ПРІОРИТЕЗУЄМО. Головна ЛОГІКА => зменшити загальний ризик. Зменшити ймовірність виникнення дефектів, особливо багів з високим впливом на систему, які можуть вплинути максимально болісно на неї. Risk-based testing слід розпочинати на початку проекту та використовувати ці знання у тест-плані. Мета тестування означає зробити проект не абсолютно безризиковим проектом. А провести тестування за найкращими методологіями управління ризиками для досягнення результату проекту, який співвідносить ризики з якістю, особливостями, бюджетом та графіком. Як провести Risk-based testing ? Складіть пріоритетний перелік ризиків. Проведіть тестування, яке вивчає кожен ризик. По мірі "випаровування" ризиків і появи нових, спрямовуйте свої тестові зусилля, щоб фокусуватися на поточному скоупі.

Класифікація Серйозності та Пріоритетності

Severity 1. Blocker. Помилка, яка приводить програму в неробочий стан або блокує роботу більшу частину функціоналу (з додатку не викидає, просто просування на якомусь етапі далі неможливе). Подальша робота з програмною системою або її функціями - неможлива. Потрібно чекати на перезбір програми від розробників і якщо можливо тестувати її з інших пристроїв Наприклад, при натисканні певної кнопки програми, нічого не відбувається і подальша робота до функціоналів неможлива 2. Critical/Crash. Критичний дефект, який приводить деякий ключовий функціонал у неробочий стан (збій). Так само це може бути суттєве відхилення від бізнес логіки, неправильна реалізація необхідних функцій, втрата даних користувача і т.д. Наприклад, відкриваємо додаток, а на етапі реєстрації нас викидає на робочий стіл або зависає програма після якихось дій. 3. Major. Дуже серйозна помилка, що свідчить про відхилення від бізнес-логіки або порушує роботу програми. Не має критичної дії на додаток. Тобто помилка у важливому, але не ключовому функціоналі. Наприклад, у RPG (role played game) є відхилення в розрахунках монет при купівлі зброї 4. Minor. Незначний дефект, що не порушує функціонал програми, що тестується, але який є невідповідністю очікуваного результату. Наприклад, помилка дизайну. Помилка у додатковому функціоналі 5. Tweak (не у всіх трекінгових системах) Помилка, яка створює незручність у використанні 6.Text (не у всіх трекінгових системах) Невелика помилка в тексті (письмова помилка) 7. Trivial (не у всіх трекінгових системах) Малопомітний Баг, який не має впливу на функціонал або роботу програми, але який може малоймовірно виявлений Priority: 1. High. Баг може бути виправлений якнайшвидше, т.к. він критично впливає працездатність програми. 2. Medium. Дефект повинен бути обов'язково виправлений, але він не має критичного впливу на роботу додатка. 3. Low. Помилка має бути виправлена, але вона не має критичного впливу на програму і усунення може бути відкладено, залежно від інших більш пріоритетних дефектів. Пріоритет визначають 2 параметри: 1. Яку шкоду завдає баг 2. Можливість появи цього бага

Що таке Smoke та Sanity тестування і яка між ними різниця?

Smoke testing Тестування, спрямоване на перевірку найголовнішої, ключової функціональності, непрацездатність якої робить безглуздою саму ідею використання програми Sanity Testing Тестування, спрямоване на докази того, що конкретна функція працює відповідно до заявлених у специфікації вимог

Діаграма переходу станів (State-transition Diagram)

State & Transition Diagram (скорочено S&T) — схема станів і переходів. Техніка для візуалізації

QA QC Testing

Testing (продукто-орієнтовний підхід) Процес відповідаючий за створення і виконання тестів, знаходження та документування дефектів, взаємодія з розробниками, автоматизація тестів, написання тестової документації, створення звітів та інше. Загалом тестувальник шукає дефекти Quality Control (продукто-орієнтовний підхід) процес контролю відповідності розроблювальної системи написаним до неї вимогам. Постійний моніторинг чи робимо ми продукт якісним та таким яким його було заплановано. QC фахівець аналізує результати тестування і відповідає за виявлення дефектів та контролює чи знищуються вони. Quality Assurance (процесно-орієнтований підхід) Комплекс заходів, який охоплює всі технологічні аспекти на всіх етапах розробки ПЗ для підвищення якості продукту. QA інженер аналізує технічні особливості та вимоги до продукту, оцінює ризики, планує задачі для процесу покращення якости ПЗ, створює бази документів, тестового середовища, аналізує результати тестування, забезпечує методи і технології всіх учасників процесу тестування

Що таке Traceability Matrix?

Traceability matrix — подвійна таблиця, що перевіряє відповідність функціональних вимог продукту (functional requirements) і підготовленим тест-кейсам. На перетині відповідних рядка та стовпця ставиться відмітка, яка позначає, що ця вимога покривається тест-кейсом. Таким чином цей інструмент дає візуальне зображення таких параметрів: наявність у системі ще не покритих тест-кейсами вимог (якщо у вимог немає жодного перетину з тест-кейсами); надлишкове тестування — якщо вимога має кілька перетинів з тест-кейсами. Що має містити матриця покриття вимог? У кожному рядку має бути: номер та опис задачі з таск-трекера; модуль, до якого належить задача (опціонально); приймальний критерій (Acceptance criteria); пріоритет; номер та опис відповідного тест-кейсу. Матриця коректно виконує свою роль лише за умови її постійної актуалізації. Інакше вона не тільки стає марною, а й може заплутувати тестувальників

Що таке Use Case/User Stories?

Use Case (Сценарій користування) - це перелік дій, сценарій, за яким користувач взаємодіє з додатком або програмою для виконання будь-якої дії та досягнення конкретної мети. Детальніше в статті: «Що таке use case та для чого вони потрібні» User Story (Історія користувача) - це неформальне загальне пояснення функцій програмного забезпечення, написане з точки зору кінцевого користувача. Її мета полягає в тому, щоб сформулювати, яку цінність для замовника несе функціонал програмного забезпечення.

Validation VS Verification

Validation перевірка того, чи продукт відповідає очікуванням і потребам користувачів Verification підтвердження того, що певні вимоги буди виконані

Рівні та види вимог

Вимоги-це властивості ПЗ, які повинні бути належним чином представлені в ньому для вирішення конкретних практичних завдань Рівні вимог: Піраміда вимог BRD 1. Бізнес вимоги Визначають призначення ПЗ, описуються в документі про бачення (vision) та межі проекту (scope). BRD відповідають на питання які задачі ми вирішимо з допомогою цієї системи ? Приклад: ми хочемо за допомогою системи, що розробляється, прискорити процес доставки товару споживачеві 2. Вимоги користувачів SRS Визначають набір завдань користувача, які повинна вирішувати програма, а також способи (сценарії) їх вирішення в системі. Користувацькі вимоги можуть виражатися у вигляді фраз тверджень, у вигляді сценаріїв використання (use case), історій користувача (user stories), сценаріїв взаємодії (scenario) -Документи: Use case, User story та таблиці "подія-відгук". Це частини правильного SRS -Відповідають на запитання: що клієнти можуть зробити за допомогою системи, щоб досягти мети описаної в бізнес вимогах? -Приклад: продавець магазину може надіслати запит на товар, який буде отримано на складі 3. Функціональні вимоги FRD Визначають функціональність ПЗ, яку розробники повинні побудувати, щоб користувачі змогли виконувати свої завдання в рамках бізнес-вимог. Іноді вони називаються ВИМОГАМИ ПОВЕДІНКИ (BEHAVIORA REQUIEMENTS), вони містять положення з традиційним "повинен" - Документ: SRS (Software Requirements Specification), у ньому є FRD (Functional Requirement Document), у цих документах описується так повно, як необхідно, очікувана поведінка системи. - На яке питання відповідають: Якими функціями має володіти система, щоб користувачі змогли виконати свої цілі, описані у вимогах користувача. - Приклад: Система повинна додавати обраний товар у кошик при натисканні кнопки "Додати". Види вимог по характеру: 1. Функціональний характер - вимоги до поведінки системи -Бізнес-вимоги -Користувацькі вимоги -Функціональні вимоги 2. Нефункціональний характер (обмеження архітектури/реалізації/експлуатації) - вимоги до характеру поведінки системи

Які є атрибути баг-репорту? Які основні поля для заповнення?

Документ, який описує знайдений дефект, а також дії необхідні для його відтворення -BUG ID -SUMMARY -DESCRIPTION -PRECONDITIONS -STEPS TO REPRODUCE -ACTUAL RESULT -EXPECTED RESULT -SEVERITY -PRIORITY -REPRODUCIBILITY -STATUS -RESOLUTION -ATTACHMENTS -ENVIRONMENT -ADDITIONAL INFORMATION(COMMENTS)

Що таке логи (log files)? Як зняти логи на мобільних пристроях?

Логи (лог-файли, log-files) - це файли, які містять інформацію про роботу сервера або комп'ютера, в які записуються певні дії програми, а також всі дії користувача над нею. Для зняття логів на Android-пристроях використовують такі інструменти, як Minimal ADB, Android Studio. Для зняття логів на iOS-пристроях використовують iTunes, iMazing, XCode (для MacOS). Детальніше в статтях: «Зняття логів на Android-пристроях» «Зняття логів у iOS»

Таблиця прийняття рішень (Desicion Table)

Метод проектування тестів шляхом чорного ящика в якому тестові приклади призначені для комбінації вхідних даних і причин, показаних в таблиці рішень "Decision Table" завжди складається з "Умов" ("Conditions") і "Дій" ("Actions"), інформація про які береться з вимог. Ця таблиця допомагає визначити мінімальну кількість тестів, що покривають всі можливі варіанти комбінацій вихідних умов. Умова значення для виконання дій Дія правило виконання дії Статус тестування

Що таке End-to-End тест?

Наскрізне тестування - це методологія тестування програмного забезпечення для перевірки потоку додатків від початку до кінця. Метою цього тестування є імітація реального сценарію користувача та перевірка системи, що перевіряється, та її компонентів для інтеграції та цілісності даних. Він виконується від початку до кінця в реальних сценаріях, таких як зв'язок програми з обладнанням, мережею, базою даних та іншими програмами. Повноцінна перевірка облікового запису Gmail включатиме такі кроки: Зазвичай для такого виду тестування розробляють сценарій, який максимально наближений до реальної експлуатації програми. Наприклад, у сценаріях закладаються, підключення до бази даних, отримання даних з БД, виправлення даних у БД, взаємодія з мережею та багато іншого. Таким чином, наскрізні тести, це такі інтеграційні тести, які діють на систему через її самі зовнішні інтерфейси та перевіряють очікувану реакцію системи через ці самі інтерфейси.Чому саме інтеграційні? Тому, що це єдине, що про них можна сказати точно: вони за визначенням не можуть бути модульними тестами. А все інше: чи вони одночасно приймальні, навантажувальні або ще якісь - залежать тільки від загального плану/стратегії тестування і тих роликів, які ці тести в них грають. Запуск сторінки входу в Gmail через URL. Вхід в обліковий запис Gmail за допомогою дійсних облікових даних. Доступ до Inbox. Відкриття прочитаних та непрочитаних електронних листів. Створення нового електронного листа, відповідь або пересилання електронного листа. Відкриття надісланих елементів та перевірка електронної пошти. Перевірка електронних листів у папці 'Спам' Вийти з програми Gmail, натиснувши кнопку «вийти»

Типи мобільних додатків. Поясніть різницю між Native, Web App, Hybrid App.

Нативні додатки (Native apps) - мобільні додатки, написані мовами програмування, затвердженими розробниками програмного забезпечення під кожну конкретну платформу, а тому органічно вбудовуються в самі операційні системи. Додатки завантажуються через магазини програм (App Store, Google Play тощо) та відповідають вимогам цих магазинів. Нативні програми можуть повністю або частково працювати і за відсутності інтернет-з'єднання, тому користувачі менше залежать від якості зв'язку і можуть користуватися програмою там і тоді, коли їм це зручно. Мобільні веб-додатки (Web apps) - це мобільна версія сайту лише з розширеним інтерактивом. Різниця між веб-додатком та адаптивною версткою сайту не велика, оскільки і там і там застосовуються стандартні веб-технології, а швидкість роботи обмежена якістю інтернет-з'єднання. При цьому веб-програми не розміщуються в спеціалізованих магазинах програм і зазвичай використовують браузер телефону для роботи. Гібридні додатки (Hybrid apps) - Генератори мобільних додатків дозволяють створювати кросплатформні додатки, наближені за функціоналом та якістю до нативних додатків. Це щось середнє між нативними та веб-додатками. Такі програми встановлюються через офіційні магазини, мають обмежений доступ до апаратної частини смартфонів та планшетів, в них можна настроювати push-сповіщення. А також вони, як правило, дешевші за нативні програми.

Positive vs Negative Testing

Позитивне Тестування очікуваної правильної поведінки користувача Негативне Тестування нестандартної поведінки користувача, чи не буде ПЗ виконувати функції при невірних та некоректних діях користувача, тестування направлене на перевірку чи повідомить система про неправильні дії

Що таке Bug, Error, Failure, Fault?

Помилка (Error) Дія людини, що створила помилку (прорахунок), що призводить до дефекту Bug Дія, яку допустив розробник, який писав код чи аналітик, який формує вимоги Дефект (Defect, Bug) Недолік компонента або системи, що може призвести до збою чи відмови. Дефекти також можуть перебувати в документації та дизайнах. Дефект це результат помилкової дії, його можна не бачити, але він є Збій (Failure) Якщо код з дефектом виконано, то система може бути не в змозі виконати те, що повинна робити (або зробити те, що від неї не очікують Падіння системи, дія, коли проявляється дефект

SDLS. ЖЦ Розробки ПЗ

Структура, що визначає завдання, що виконуються на кожному етапі процесу розробки програмного забезпечення. ТАКОЖ Період часу, який починається з моменту прийняття рішення про створення ПЗ і закінчується моментом його повного зняття з експлуатації Етапи: Planning Analysis Design Implementation (реалізація) Testing & Integration Maintenance

Тест кейс і його структура

Тест-кейс (Test Case) - це сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації функції, що тестується або її частини. Test case ID Test Case Title Summary Preconditions Steps to Reproduce + Expected result

Що таке тест-план? Яка його структура?

Тест-план (Test plan) - це документ, який описує весь обсяг робіт з тестування, починаючи з опису об'єкта тестування, стратегії, розкладу, критеріїв початку і закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення. Тест-план призначений для: -врегулювання процесів тестування; -пріоритезації завдань; -планування ресурсів; -обліку програмного забезпечення та людських ресурсів Якісний тест-план, щонайменше, повинен складатися з нижчеперелічених пунктів: 1. Що необхідно протестувати? У цьому пункті необхідно детально описати об'єкт тестування. Це може бути опис системи, додатка, обладнання. Якщо об'єктом тестування є додаток, то слід перерахувати всі його функціональні блоки. Також необхідно вказати на якому обладнанні, в яких браузерах буде виконуватися тестування. 2. Як буде проводитися тестування? У цьому пункті необхідно детально описати стратегію тестування. Необхідно перерахувати види тестування і їх застосування по відношенню до об'єкта тестування. 3. Коли буде проводитися тестування? На даному етапі описується послідовність проведення робіт: підготовка (Test preparation), тестування (Testing), аналіз результатів (Test result analysis) в розрізі запланованих фаз розробки. Обов'язково повинні бути вказані дати або критерії переходу від однієї фази до наступної. 4. Критерії початку тестування Залежно від конкретного проєкту, критерії початку тестування можуть бути різні. Приклади деяких можливих варіантів початку тестування перераховані нижче: готовність тестової платформи (тестового стенда); закінченість розробки необхідного функціоналу; наявність всієї необхідної документації. 5. Критерії закінчення тестування: вимоги до кількості відкритих багів виконані; витримка певного періоду без зміни вихідного коду програми Code Freeze (CF); витримка певного періоду без відкриття нових багів Zero Bug Bounce (ZBB); всі тести успішно пройдені; закриті всі баги з високою та середньою критичністю. Якщо при складанні тест-плану ви відповісте на всі ці питання, то отримаєте хороший чорновий варіант документа з планування тестування. Після цього його потрібно доопрацювати, спираючись на пункти зазначені нижче, і тест-план буде майже готовий: оточення тестованої системи (опис програмно-апаратних засобів); необхідне для тестування обладнання та програмні засоби (тестовий стенд і його конфігурація, програми для автоматизованого тестування і та ін.); ризики та шляхи їх вирішення.

Тестовий набір

Тестовий набір (Test Suite) - набір тестів, що реалізують бізнес-завдання, що виконується тестованою системою. Тестовий набір включає крім тестових сценаріїв ще й тестові дані або правила їх генерації.

Що таке Regression і Confirmation тестування, яка між ними різниця?

Тестування змін: При тестуванні змін в системі дуже важливо зрозуміти різницю та межу між поняттями регресійне тестування (Regression testing) та повторне тестування (Retesting). Регресійне тестування (Regression testing) проводиться з метою перевірки працездатності функціоналу, що існує, та перевірки на відсутність сторонніх помилок після оновлення білда (внесення правок або доповнень в систему). Повторне тестування (Retesting) - проводиться для підтвердження виправлення помилки та роботи даного функціоналу Спочатку виконується повторне тестування, а потім регресійне. У проєкт, де доступно достатньо ресурсів, регресійне тестування та повторне тестування проводяться одночасно.

Що таке Performance Testing?

Тестування продуктивності Тестування направлене на перевірку того, як швидко працює система під певним навантаженням. 1. Навантажувальне тестування направлене на перевірку того, як система працює під заданою очікуваною навантаженістю і з невеликим її пере лімітом(запас міцності). 2. Тестування масштабуємості Перевірка здатності системи до модернізації(збільшення БД, сервера, продуктивності серверної програми) під навантаженням, що перевищують очікувані. 3. Стрес Перевірка того як працює ПО під значним збільшенням навантаження або при відмові якогось важливого для роботи ПО ресурсу. 4. Об'ємне Тестування здатності прог. прод. працювати з великими об'ємами даних

Техніки створення т-к методом білого ящика: Тестування операторів (Statement Testing) Тестування рішень (Decision Testing) Тестування шляхів (Path Testing)

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

Що таке Configuration testing?

Тестування, спрямоване на перевірку роботи програмного забезпечення при різних конфігураціях системи (заявлених ОС, драйверах, що підтримуються, при різних конфігураціях комп'ютерів і т.д.) Вплив змін конфігурації. приклад: експерименти з різними методами балансування навантаження. Можна поєднати з іншими видами тестування навантаження Рівні проведення конфігураційного тестування: 1. Серверний Взаємодія ПЗ з оточенням, в яке воно буде встановлене ● Апаратні засоби (тип та кількість процесорів, обсяг пам'яті, характеристики мережі/мережевих адаптерів тощо) ● Програмні засоби (ОС, драйвера та бібліотеки, стороннє ПЗ, що впливає на роботу програми тощо) 2. Клієнтський Виконується з позиції кінцевого користувача та конфігурації його робочої станції. ● Тип, версія та бітність операційної системи (крос-платформне тестування) ● Тип і версія Web браузера, якщо тестується Web додаток (крос-браузерне тестування) ● term-12Тип та модель відеоадаптера ● Робота програми за різних роздільних здатностей екрана ● Версії драйверів, бібліотек тощо.

Вгадування помилок (Error Guessing)

Техніка прі якій використовуючи свої знання QA-спеціаліст може "передбачити" при яких вхідних умовах є ризик помилки. Для цього важливо мати досвід. Така перевірка ефективна в додаток до інших технік, бо виявляє критичні моменти невеликі терміни

Назвіть характеристики хорошого тест-кейсу

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

Що таке тестування?

Це процес аналізу ПЗ та супутньої з ним документації з метою знаходження дефектів та підвищення якості продукту.

Методології Розробки ПЗ SDM

Це фреймворки або підходи, які використовуються для структурування, планування та контролю процесу розробки програмного забезпечення. ПРОСТІШЕ: модель розробки - це деякі правила, за якими ПЗ проживає SDLC Модель Структура, що визначає послідовність виконання та взаємодію процесів, дій та завдань протягом усього життєвого циклу ПЗ. Модель VS Методологія Методологія - це як спосіб мислення команди та підхід до розробки ПЗ Модель - це як зразкова схема (орієнтир) як розробляти ПЗ Види SDM plan driven vs change driven

Як часто варто проводити регресійне тестування продукту?

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

Чек ліст і його структура

Чекліст - це список, який містить ряд необхідних перевірок під час тестування програмного продукту. Чеклісти організовані дуже просто. Вони складаються з переліку блоків, секцій, сторінок, інших елементів, які слід протестувати, наприклад: 1. Реєстрація і особистий профіль а)Реєстрація на сайті б)Редагування профілю 2. Форма зворотного зв'язку а)Валідація полів б)Відправка листа/повідомлення в)Доставка листа/повідомлення 3. Пошук а)Пошук по назві б)Перехід за посиланням в)Робота пошуку з різноманітними параметрами 4. Коментарі а)Додавання коментаря б)Відображення коментаря При проходженні чекліста тестувальник зазначає статус навпроти кожного пункту, який протестовано. Можливі такі варіанти статусів: «Passed» - перевірка пройдена успішно, багів не знайдено; «Failed» - знайдений один або більше багів; «Blocked» - неможливо перевірити, тому що один з багів блокує поточну перевірку «In Progress» - поточний пункт, над яким працює тестувальник; «Not run» - ще не перевірено; «Skipped» - пункт перевірятися не буде з певної причини. Наприклад, поточний функціонал ще не реалізований.

Що таке Black/Grey/White Box Testing?

Чорний ящик (Black box) Методи засновані на специфікаціях та досвіді Тестування як функціональне, так і нефункціональне, не передбачає знання внутрішнього влаштування компонента чи системи. Білий ящик (White box) Методи засновані на структурі Тестування, засноване на аналізі внутрішньої структури компонента або системи де передбачається, що внутрішня структура/пристрій/реалізація системи відомі тестувальнику Сірий ящик (Gray box) Методи засновані на специфікаціях та частково на структурі Тестування програмного забезпечення, яке передбачає, комбінацію White Box та Black Box підходів. Тобто внутрішній пристрій програми частково відомі тестувальнику.

Які техніки тест-дизайну знаєте?

Чорний ящик: Еквівалентний поділ (Equivalence Partitioning) Граничні значення (Boundary Values) Таблиця прийняття рішень (Desicion Table) Парне тестування (Pairwise Testing) Діаграма переходу станів (State-transition Diagram) Сценарна техніка(Use case testing) Білий ящик: Тестування операторів (Statement Testing) Тестування рішень (Decision Testing) Тестування шляхів (Path Testing) Experiensed based: Вгадування помилок (Error Guessing) Дослідницьке тестування (Exploratory Testing) Тестування, на снові чек-лістів(Checklist-based Testing)

Особливості тестування мобільних додатків

Що тестувати у мобільній версії: 1. Розмір екрана та сенсорний інтерфейс(зручний для натискання розмір елементів та достатня швидкість їх реагування) 2. Підтримка альбомного та портретного режимів 3. Ресурси телефону (працездатність після оновлення ОС, Витік пам'яті, енергозатрати, Збереження даних у кеш-пам'яті та збереження кешу у додатку, недостатня кількість місця для встановлення або роботи програми, встановлення на карту пам'яті та перевірка роботи батареї. 4. Різні функції на пристроях()гарнітура, вбудований мікрофон, блютуз, відсутність/наявність камери та джипіес 5. Різні розширення екрана та версії ОС(ретіна та звичайні екрани, встановлення додатка на підтримувані пристрої, додаток не потрібен встановлюватись на не підтримувальні версії ОС) 6. Реакція додатка на зовнішні переривання(дзвінки, смс, вилучення акумулятора, зарядка пристрою, підключення та відключення карти пам'яті, робота з фізичною клавіатурою, сумісність з іншими додатками, вмикання/вимикання екрана) 7. Підключення та відключення wi-Fi(інформативне повідомлення) 8. Робота в фоновому режимі 9. Постійний зворотний зв'язок з користувачами(реакція кнопок на натискання, повідомлення про завантаження/прогрес-бар, наявність повідомлення про спробу видалити важливу інформацію, наявність повідомлення/екрану прі завершенні процесу/гри, наявність і синхронність звукових і вібрацій з повідомленнями на екрані) 10. Інтернаціоналізація(тестування перекладу, всі написи входять у відповідні кнопки, зміна мови швидка без перезавантаження додатку, текст має бути не надто скороченим та зрозумілим при використанні трикрапки, при першому запуску мова має відповідати мові пристрою по замовчуванню, тестування формату дати)

Тестування, на снові чек-лістів(Checklist-based Testing)

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

Які бувають види(підходи) інтеграційного тестування?

● Знизу вгору (Спочатку збираються та тестуються модулі найнижчих рівнів, а потім за зростанням до вершини ієрархії) ● Зверху вниз (Цей підхід передбачає рух із високорівневих модулів, а потім прямує вниз). ●Сендвіч-тестування — підхід, комбінований з двох попередніх. ● Великий вибух (Всі модулі всіх рівнів збираються докупи, а потім тестуються) Перший підхід дозволяє легко знаходити програмні дефекти, коли другий знаходить архітектурні.