Introduction of quality assurance. Testing - презентация, доклад, проект скачать

Нажмите для полного просмотра!

Introduction of quality assurance. Testing, слайд №1

Introduction of quality assurance. Testing, слайд №2

Introduction of quality assurance. Testing, слайд №3

Introduction of quality assurance. Testing, слайд №4

Introduction of quality assurance. Testing, слайд №5

Introduction of quality assurance. Testing, слайд №6

Introduction of quality assurance. Testing, слайд №7

Introduction of quality assurance. Testing, слайд №8

Introduction of quality assurance. Testing, слайд №9

Introduction of quality assurance. Testing, слайд №10

Introduction of quality assurance. Testing, слайд №11

Introduction of quality assurance. Testing, слайд №12

Introduction of quality assurance. Testing, слайд №13

Introduction of quality assurance. Testing, слайд №14

Introduction of quality assurance. Testing, слайд №15

Introduction of quality assurance. Testing, слайд №16

Introduction of quality assurance. Testing, слайд №17

Introduction of quality assurance. Testing, слайд №18

Introduction of quality assurance. Testing, слайд №19

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Introduction of quality assurance. Testing. Доклад-сообщение содержит 19 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1

Описание слайда:

Слайд 2

Описание слайда:

Introduction of Quality Assurance

Слайд 3

Описание слайда:

Testing in a nutshell Competencies: - Guarantee quality of a product - Finding defects (bugs) - Preventing bugs - Work with docs

Слайд 4

Описание слайда:

Couple of words about documentation 1. Test cases; 2. Test plan; 3. Check list; 4. Test suite; 5. Bug reports.

Слайд 5

Описание слайда:

Test plan Test plan – main document for application testing. It describes testing strategy and testing approaches. It contains following: •Title, author, version control, history of changes •Table of contents •Introduction. Short description of application and requirements •Functionality that will be and that will not be tested •Types of testing •Testing documents •Hardware, software and tools •Entry and exit criteria •Suspension criteria and resumption requirements •Responsible people •Schedule and risks •Approvals •Appendixes

Слайд 6

Описание слайда:

Some facts about test cases • Test cases can be based on requirements (specifications, communication with customer, mails) or existent functionality • Used for requirements coverage, providing more quality for less time • The source for reporting and QA • Usually automated test scripts base on test cases • Allows to organize team work

Слайд 7

Описание слайда:

New test case. What to start with? Learn requirements and pick out all possible cases including negative cases Check the genuineness of the test case Test case should describe an atomic independent functionality Don’t use passive voice; Test cases should not contain tough language and be ambiguous Avoid using redundant steps Review your test cases

Слайд 8

Описание слайда:

New test case. Let’s focus on attributes Unique ID. Author Revision history Priority (critical, major, minor, trivial) Description Preconditions, steps and expected result Post conditions Comments, related requirements and bugs

Слайд 9

Описание слайда:

New test case. Let’s focus on attributes

Слайд 10

Описание слайда:

Test suite. Briefly Test suite – batch of test cases, which check certain functionality. For example: User registration Sending messages Removing account

Слайд 11

Описание слайда:

Test suite. Example

Слайд 12

Описание слайда:

Check-list. Main purposes Check-list – list of attributes, applications, characteristics and checks themselves, need for testing. Mainly used for internal needs. Also: Allows tester not to forget to check something; Expand test coverage; Reduce testing costs; Test control.

Слайд 13

Описание слайда:

Check-list as it is

Слайд 14

Описание слайда:

One more thing. Bugs. Bug is nothing else but program flaw, in other words – defect in software. It can be found while testing software application or product, and usually means difference between expected and actual behavior. As a rule, such defects show up as a result of error in logic or in coding and result into the failure on unpredicted behavior.

Слайд 15

Описание слайда:

Bug’s example

Слайд 16

Описание слайда:

Bug reports Each bug should be conveyed to the developer. Thus, bug should be reported in a appropriate way. That’s why we need documents called Bug Reports. They should contain following: Defect ID – bug’s unique number; Defect description – the summary of the issue; Product version – determines version of a product in which defect is found; Steps to reproduce – includes steps for recreating. Also should contain description for expected and actual results, basing on evidences like screenshots or video recording; Date raised – date of bug reporting; Status – New, Assigned, Open, Retest, Verification, Closed, Failed; Fixed by – This field includes the details of the developer who fixed the defect; Severity – means an impact of the bug on a system (Critical, Major, Minor); Priority – determines the sequence, in which bug will be fixed (Low, Medium, High).

Слайд 17

Описание слайда:

Bug’s lifecycle

Слайд 18

Описание слайда:

Bug’s lifecycle 1. Finding defect. Status – New 2. Dev team with Project Manager decides whether defect is valid. If not – status Rejected 3. If the defect is not rejected then the next step is to check whether it is in scope. Suppose we have another function- email functionality for the same application, and you find a problem with that. But it is not a part of the current release then such defects are assigned as a postponed or deferred status. 4. Then manager verifies, if such was earlier. If yes – status ‘Duplicate’ 5. If bug is new, bug is assigned to the developer, who starts fixing it. Status – ‘In Progress’ 6. After fixing of bug it’s status is set to ‘Fixed’ 7. After this tester starts verifying whether bug is fixed indeed. If such, bug is ‘Closed’. Otherwise, it’s ‘Re-opened’ and re-assigned to a developer