-

Забезпечення Якості -- Quality Assurance
-

середу, 24 грудня 2008 р.

QA Філософія (QA Engineers Philosophy)

  Філософія QA інженера чи просто філософія QA. Дуже цікаве поєднання слів, що дало б можливость (при його справедливості) віднести QA до окремої частини ІТ індустрії, можна навіть сказати до окремої її галузі (інституту). Але чи так це і чи має це поєднання слів якийсь сенс? Тому спочатку потрібно чітко для себе визначити «Що таке Філософія?».

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

  Тому, щоб говорити про те, що QA може мати власну філософію, потрібно вияснити чи являється професія QA одним із видів людської діяльності, яка направлена на постановку та раціональне вирішення найбільш загальних питань, що стосуються суті знань. І відповідь тут випливає із самої постановки питання. А саме, що QA – є однією з видів людської діяльності, яка передбачає аналіз якості програмного забезпечення: його надійності, функціональності, простоті в користуванні, та інших. Діяльність QA розгортається від планування тестування, самого процесу тестування і до наступного його аналізу. І тому я вважаю, що найбільш важливим та загальним питанням у роботі QA є добитися того, що створений продукт максимально близько відповідав вимогам (Requirements or Use Cases) до нього. Адже ідеального нічого не буває. І програма, яка б на 100% відповідала вимогам замовника і не містила б при цьому жодної помилки (Bug) немає в принципі, а існують реальні проекти з певним відсотком виконаних вимог та кількістю знайдених багів. І тому напрошується цілком виправдане заключення, що діяльність QA направлена на те, щоб цю різницю звести до мінімуму – різницю кількості (відсоток) виконаних та передбачених вимог, а також різницю безпомилкового проекта та реальною ситуацією (кількість знайдених багів). А ще слід врахувати, що віднайти всі баги також неможливо, як і передбачити всі ситуації та випадки використання проекта ми просто не в силі. Звичайно тут можна заперечити те, що діяльність QA не направлена на створення проекту та виправлення його помилок, а лише на знаходження в ньому помилок. Це абсолютно хибне уявлення. По-перше, завданням QA є не знайти всі присутні на проекті баги, а переконатися що їх немає. Адже QA так само відповідальний за знайдені баги, як і програміст за створення проекта. Тому QA повинен так само шукати правильне та максимально близьке вимогам рішення знайденої проблеми, але вже не на технічному рівні, а з точки зору логіки та правильної функціональності, виходячи з того, що одну і ту ж проблему можна вирішити кількома різними способами.

Таким чином залишається зрозуміти та вияснити ще особливий спосіб пізнання всього процесу, що повинен бути притаманний QA ...

пʼятницю, 12 грудня 2008 р.

понеділок, 3 листопада 2008 р.

четвер, 23 жовтня 2008 р.

Діаграми Прецедентів (Use Case UML Diagram)

Діаграма Прецедентів візуально зображає різноманітні сценарії взаємодії між акторами (користувачами) і прецедентами (випадками використання); описує функціональні аспекти системи (бізнес логіку).

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

Елементи Діаграми Прецедентів:
o Актор – користувач.
o Прецедент – випадок використання, дія. Позначається овалом.
o Граничні межі системи охоплюють усі випадки використання у системі.
Позначається прямокутником.

Елементи взаємодії Діаграми Прецедентів:
o Використовує – користувач виконує дію.
o Включає – один прецедент використовує іншого.
o Розширює – представлення дочірніх прецедентів.
o Вимагає – наступний прецедент вимагає виконання попереднього.
o Схожий – прецеденти подібні, але описують різну функціональність.
o Рівнозначний - подібна функціональність, але користувач сприймає, як різну.



понеділок, 20 жовтня 2008 р.

Тестування Функціональних Вимог

1. Визначити цілі проекту та їх пріоритетність
Виписати основні цілі проекту. Обговорити із замовником необхідність розробки не важливих та сумнівних цілей. Визначити їх пріоритетність.

2. Перевірити цілісність і прозорість функціональних вимог.
Чітко визначити які функції система повинна і не повинна виконувати.

3. Виявити неоднозначні вирази.
Створити тлумачний словник для чіткого визначення неоднозначних термінів. Уточнити у замовника визначення кожного з них.

Перелік основних пунктів Функціональних Вимог:

-Назва
-Короткий опис
-Актори
-Основний потік
-Альтернативний потік
-Передумови
-Післяумови
-Особливі вимоги
-Залежності

пʼятницю, 17 жовтня 2008 р.

Тест План

1. Вступ (Introduction)
Коротко, але зрозуміло і достатньо про продукт

2. Джерельні Документи (Related Documents)
Список джерел інформації

3. Пункти Тестування (Test Items)
Що буде тестуватися

4. Функціональність буде/не буде Тестуватися (Feature to be/not to be Tested)
Функціональність, яка буде/не буде тестуватися

5. Тест Підхід/ Тест Дизайн/ Тест Випадки (Test Approach/Test Design/Test Cases)
Як це буде тестуватися

6. Критеріїї Успішного/Неуспішного Результату ( Pass/Fail Criteria)
Критерії успішного/неуспішного результату

7. Оцінка (Estimations)
Скільки часу необхідно затратити на тестування

8. Середовище (Environment)
У якому середовищі необхідно тестувати

9. Відповідальність (Resource Responsibilities)
Скільки працівників і хто за що відповідальний

10. Ризики і Наслідки (Risks and Contingencies)
Які проблеми можуть виникнути під час тестування і потенційні рішення

11. Графік Тестування (Scheduler)
Як і коли буде відбуватися інформування, відповідальних осіб за проект, про результати тестування

12. Тестові Результати (Test Deliverables)
Що (дані, документи, інше..) буде створено під час тестування і доставлено разом з продуктом

Функціональні та Не Функціональні Вимоги

1. Функціональні Вимоги (Functional Requirements)

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

2. Не Функціональні Вимоги (Non-Functional Requirements)

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

2.1. Вимоги до Інтерфейсу (Interface Requirements)

2.1.1. Апаратні Інтерфейси (Hardware Interfaces)
Апаратні інтерфейси необхідні для підтримки системи, включаючи логічну структуру, фізичні адреси і очікувану поведінку.

2.1.2. Інтерфейси ПЗ (Software Interfaces)
Назви Інтерфейсів програмного забезпечення з якими аплікація повинна взаємодіяти.

2.1.3. Звязки Інтерфейсів (Communications Interfaces)
Звязки інтерфейсу з іншими системами або приладами.

2.2. Апаратні та Програмні Вимоги (Hardware/Software Requirements)
Опис апаратної та програмної платформ, необхідних для підтримки системи.

2.3. Operational Requirements

2.3.1. Безпека та Конфіденційність (Security and Privacy)

2.3.2. Надійність (Reliability)

2.3.3. Відновлювальність (Recoverability)

2.3.4. Продуктивність (Performance)

2.3.5. Потенціал (Capacity)

2.3.6. Збереження даних (Data Retention)

2.3.7. Керування помилками (Error Handling)

2.3.8. Правила Перевірки (Validation Rules)

2.3.9. Узгоджені стандарти (Convention Standards)

вівторок, 14 жовтня 2008 р.

Баґ

Основи теорії Баґу (Bug) на Lviv Software Developers Community.

четвер, 9 жовтня 2008 р.

Документація у тестуванні

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

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

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

З готовою документацією тестувати досить легко і приємно. Такий підхід, як мінімум, запевняє у максимальному тестовому покритті проекту. Також не варто обмежуватися тестовою документацією. Трішки творчого підходу при виконанні будь-якого завдання не завадить ;). Хорошим показником якості роботи тестера є тип і пріоритетність знайдених Багів, котрі також повинні бути задокументовані у зрозумілому стилі.
Кінцевий підсумок про якість продукту, який базується на результатах тестування, тобто знайдених Багах, зображається у Тестовому Звіті.
Найкращим шаблоном документу є той який є зручним для усіх хто його читає :).

середу, 8 жовтня 2008 р.

UML Діаграми

UML - (англ. Unified Modeling Language) — уніфікована мова об'єктно-орієнтованого моделювання. Вона є невід'ємною частиною процесу розробки програмного забезпечення.
UML Diagrams – діаграми написані (намальовані) мовою UML.

UML діаграми поділяються на типи:
• Структурні
o Діаграма класів (Class Diagram)
o Діаграма об’єктів (Object Diagram)
o Діаграма компонентів (Component Diagram)
o Діаграма композитів (Composite Structural Diagram)
oo Діаграма кооперацій (Collaboration)
o Діаграма розгортання (Deployment Diagram)
o Діаграма пакетів (Package Diagram)

• Поведінкові
o Діаграми взаємодії (Interaction Diagram)
oo Діаграма послідовності (Sequence Diagram)
oo Діаграма комунікації (Communication Diagram)
oo Діаграма огляду взаємодії (Interaction Overview Diagram)
oo Діаграма синхронізації (Timing Diagram)
o Діаграма діяльності (Activity Diagram)
o Діаграма прецедентів (Use case diagram)
o Діаграма станів (State Machine diagram)

понеділок, 6 жовтня 2008 р.

Планування тестування малих проектів

Процес тестування необхідно планувати, навіть якщо це маленький проект на декілька годин. Як мінімум:
- варто скласти список пунктів які необхідно перевірити,
- виписати основні функції які система повинна виконувати,
- не забути про середовище у якому система буде працювати.

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

понеділок, 22 вересня 2008 р.

Тестування Програмного Забезпечення

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

Цитуємо ;)

"I do not believe software engineers or system architects design better tests. I believe skilled software testers design better tests."

Karen N. Johnson

суботу, 20 вересня 2008 р.

Вітаємо :)

Привіт, усім хто цікавиться тестуванням.

Довгенько думали про то як би так у легкий і приємний спосіб покращувати систематично свої знання в галузі Тестування. Вирішили створити QA Club у Львові!


Читайте те що пишемо, пишіть те що думаєте, запитуйте те що вас цікавить

і

Приєднуйтеся! :)