Етичний Кодекс Менеджера

1. Роби одразу добре... погано - само зробиться. Роби так, щоб не переробляти.
2. Працюємо на спільний результат. Проблема колеги - твоя проблема також.
3. Робота менеджера - спілкування. Знайди час для розмови з колегами.
4. Інформація - наше спільне багатство. Довідався щось нове - розкажи.
5. Не розповсюджуй плітки: якщо не впевнений - не кажи. Невірна інформація шкідлива.
6. Недоінформованість дорого коштує. Незнаєш, або не розумієш - запитуй, не стидайся.
7. Підтримуй авторитет свого колеги. Це підтримає твій авторитет.
8. Доказуючи свою правильність, використовуй факти. Емоції краще залишити для стадіону.
9. Усі маємо право на власний погляд. Намагайтеся зрозуміти колегу.
10. Домовитися завжди можна!

Александр Крымов
скопійовано і перекладено з сайту Мегарост

"Простежувальність"

Traceability from Use Cases to Test Cases

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

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

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

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

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

Роль Бізнес Аналітика у проекті

The Role of the Analyst in Agile Projects

Posted by Shane Hastie on Dec 05, 2008 12:04 PM

UML Діаграми

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

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

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

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

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

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

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

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

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

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

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

Тест План

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)

Баґ

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