Software Quality Assurance:
Software QA includes the whole software development PROCESS — it is made to be sure that any agreed-up on procedures and standards are followed, improving and monitoring the process, and conviction of the fact, that problems are found and dealt with. It focuses on ‘prevention’.
Quality Assurance determines the quality of processes used to make a quality product. In addition, it is a system of management activities. Quality Assurance is a preventive process, which applies for the whole life cycle and deals with the process.
It is very important for a tester to understand what is the difference between Quality control and Quality Assurance.
Quality control measures the quality of a product. It is a specific part of the Quality Assurance procedure. This corrective process applies for particular product and deals with the product.
Priority and Severity will be assigned for a concrete bug to know the importance of the bug.
Priority: Allows to the developer to understand which bug have to be fixed first.
Severity: How strongly the bug is affecting the application.
Defect: If you found any mismatch, while performing the test case, you will describe it to the development team. It is called defect.
Bug: It will be called bug if developer accepts your defect.
Test case is a document that includes information about an event, input or action, and an estimated response, to check if a singularity of an application is working properly.
Test condition. The condition is needed to test a feature.
Test script is the script which is created by an automation tool while recording an application features.
Test data means the input data (invalid, valid data), which is giving to check the application’s feature whether it is working correctly or not.
Test bed means the test environment (software, hardware set up) in which an
application will run exactly.
An approved document and the review is called – a baseline document (i.e) SRS (Software requirement Specification), test plan.
Configuration management involves the processes used to coordinate, control and track: requirements, code, documentation, change requests, problems, designs, tools, libraries, compilers, patches and changes made to them, and who makes the changes.
Verification usually includes meetings and reviews to evaluate plans, documents, code, specifications and requirements. This can be done with issues lists, checklists, inspection meetings and walkthroughs.
Validation usually takes place after verifications are completed and includes actual testing.
The term ‘IV & V’ means Independent Verification and Validation.
An informal meeting for informational purposes or evaluation is called ‘walkthrough’. Small preparation or no preparation at all is typically required.
An inspection is more formalized than a ‘walkthrough’, usually it includes 3-8 people: a reader, a recorder to take notes and a moderator. Typically inspection focuses on a document such as test plan or requirements spec, and the purpose of it is not fixing anything, but finding the problems and seeing what’s missing. Attendees have to prepare for this type of meeting: anyway, main problems will be found during reading the document. A written report will be the result of the inspection meeting. Despite preparation for inspections is painstaking and difficult work, but it is one of the most cost effective methods of ensuring quality.