-

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

пʼятниця, 30 вересня 2011 р.

Матриця Прослідковування планування розробки Тест Кейсів





Матриця Прослідковування планування розробки Тест Кейсів повинна допомогти максимально покрити кожну Вимогу необхідними Тест Кейсами.

пʼятниця, 26 серпня 2011 р.

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

1. Аналіз/Тестування Вимог до Продукту
2. Планування Тестування
3. Дизайн Тестів
4. Розробка Тестової Документації
5. Виконання Тестування
6. Аналіз Результатів та Покращення Тестування
7. Перетестовування
8. Звітування
9. Завершення Тестування

пʼятниця, 29 липня 2011 р.

Характерні Ознаки Якості ПЗ

Quality Attributes

Availability
Efficiency
Flexibility
Installability
Integrity
Interoperability
Maintainability
Portability
Reliability
Reusability
Robustness
Safety
Testability
Usability

середа, 2 лютого 2011 р.

Defect/ Bug/ Fault, Error/ Mistake, Fail, Failure

Defect or Bug or Fault: A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

Error or Mistake: A human action that produces an incorrect result.

Fail: A test is deemed to fail if its actual result does not match its expected result.

Failure: Deviation of the component or system from its expected delivery, service or result.

If someone makes an error or mistake in using the software, this may lead directly to a problem - the software is used incorrectly and so does not behave as we expected. However, people also design and build the software and they can make mistakes during the design and build. These mistakes mean that there are flaws in the software itself. These are called defects or sometimes bugs or faults. Remember, the software is not just the code; check the definition of soft-ware again to remind yourself.
When the software code has been built, it is executed and then any defects may cause the system to fail to do what it should do (or do something it shouldn't), causing a failure. Not all defects result in failures; some stay dormant in the code and we may never notice them.


*ISTQB Glossary

середа, 20 жовтня 2010 р.

Методи Дизайну Тестів

Test Design Techniques

Specification-based or Black-box Techniques:
- Equivalence Partitioning
- Boundary Value Analysis
- Decision Table Testing
- State Transition Testing
- Use Case Testing

Structure-based or White-box Techniques:
- Statement Testing and Coverage
- Decision Testing and Coverage
- Condition coverage and multiple condition coverage

Experience-based techniques:
- Error guessing
- Exploratory testing

*ISTQB Foundation Level Syllabus

Методи Тестування

Test Techniques

1. Based on the software engineer’s intuition and experience
1.1. Ad-hoc testing
1.2. Exploratory testing

2. Specification-based techniques
2.1. Equivalence partitioning
2.2. Boundary-value analysis
2.3. Decision table
2.4. Finite-state machine-based
2.5. Testing from formal specifications
2.6. Random testing

3. Code-based techniques
3.1. Control-flow-based criteria
3.2. Data flow-based criteria
3.3. Reference models for code-based testing

4. Fault-based techniques
4.1. Error guessing
4.2. Mutation testing

5. Usage-based techniques
5.1. Operational profile
5.2. Software Reliability Engineered Testing

6. Techniques based on the nature of the application
6.1. Object-oriented testing
6.2. Component-based testing
6.3. Web-based testing
6.4. GUI testing
6.5. Testing of concurrent programs
6.6. Protocol conformance testing
6.7. Testing of real-time systems
6.8. Testing of safety-critical systems

7. Selecting and combining techniques
7.1. Functional and structural
7.2. Deterministic vs. random

*Guide to the Software Engineering Body of Knowledge (IEEE -Computer Society)

вівторок, 12 жовтня 2010 р.

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

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

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

Принцип 3. Раннє тестування.
Тестування розпочинається так швидко як це можливо і фокусується на визначенні цілей.

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

Принцип 5. Парадокс пестицидів.
Якщо тестування повторюється, то один набір тест кейсів не буде знаходити нові дефекти. Уникнути "парадокс пестицидів" можна регулярною перевіркою, оновленням, та дописуванням нових тестів.

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

Принцип 7. Відсутність дефектів оманлива.
Знаходження та виправлення дефектів не допомагає, якщо система непридатна і не задовільняє потреб та очікувань користувача.

*ISTQB Foundation Level Syllabus