🗊Презентация Introduction of quality assurance. Testing

Introduction of Quality Assurance

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

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

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

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

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

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

New test case. Let’s focus on attributes

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

Test suite. Example

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.

Check-list as it is

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.

Bug’s example

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).

Bug’s lifecycle

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

Any questions?