Ok, we didn`t really want it but seems like it is high time to dwell upon not that joyful stuff. Our team has never been into bureaucracy, yet documents remain crucial for our cooperation with clients globally. In particular, we realized the testing artifacts are often underestimated, although poorly created, their effect on project flow is disastrous. That`s the reason why we devote today`s post to the testing documentation overview and the role of each for your product success.
Probably, one of the most comprehensive reports you`ll get when outsourcing QA services. Here you`ll find the outline describing software scope and activities, the way QA engineers test a particular product together with the risks related. You may consider the plan of high quality if it includes:
A technical document that requires the use of specific terminology. The report contains a full description of defects, severity, and priority classified, as well as the conditions creating the problems.
A typical report contains Bug Summary, Severity/Priority, Steps to Reproduce, Actual Result, and Expected Result. The most important is, however, the way a QA engineer combines all the parts and makes the bug description clear for a developer to fix the issues. Our team recommends answering three questions when delivering a useful bug report to the developers.
Besides, the report will classify the software defects per Severity and Priority criteria. Often confused, yet these characteristics stay at the core of every bug description.
Severity is an attribute that characterizes the impact a defect has on the software behavior.
A blocking error entirely hinders software functioning, making it impossible to use. The solution to the problem is critical for further project growth.
A critical defect refers to incorrect functioning of a particular software area. Drawbacks in security, temporarily crashed server, complete failure of a feature, unsuccessful app installation are the key examples of critical bugs.
A significant error affects major functionality or data. The error might be not critical, sometimes, there are other input points to use the system.
A minor error that does not hinder product flow, often minor issues refer to the inconsistencies in the user interface.
A trivial error isn`t always evident even through the user interface. It is a problem of third-party libraries or services, an error that does not affect the overall quality of the product. E.g. grammar, spelling mistakes, some layout discrepancies.
Priority, by contrast, indicates urgency or importance of fixing an error. The higher the priority, the faster a developer has to fix the defect. Though a software tester may set the criterion initially, it is a project/product manager who takes a final decision here.
The category falls into the following levels:
Priority is quite a subjective decision, always determined by business needs, defect severity, available resources in the team to fix and perform regression tests, deadlines, etc. Yet the task of your product manager is to carefully manage bug priority to follow smooth software development.
At the test design stage, QA engineers create tests relevant to the initial software requirements:
Test Scenario is a one-line statement that describes the area in the software to be tested. Product complexity usually defines the number of scenarios each area might have: from one to a few hundred. The term is often confused with a test case, although scenarios always require several steps to perform. In other words, a test scenario includes several test cases with the sequence they are executed.
Test Case is a series of simple steps, conditions, and inputs required to check a particular functionality. The key intent of writing a test case is to show whether the software passes or fails its functional requirements. The following structure is typical for a test case:
Action taken by a QA engineer (e.g. open page “login”)
Expected Result – the required behavior of the software (e.g. “login” page opens)
Test Result – showcases the actual software behavior (passed/failed/blocked)
Often prepared at the beginning, this is a list of tests to run on a particular software part. We complete a checklist during the testing process, include the scenarios we checked and describe the results. You`ll get it after the testing process is finished for your development team to fix the detected errors.
This is it. Now you know the types of docs QA team is to prepare while working on your project. We advise requesting all the above to make sure QA engineers check your software properly.
If you managed to read it till the end, you`re one of those lucky to get our best wishes to your project growth 🙂
Quality control is obsolete. The spread of Agile, DevOps, and shift-left approach has pushed traditional…
Be honest, if your phone disappeared right now, your world would be in shambles. Data…
Teams have a love-hate relationship with Android. It’s highly customizable and has an incredibly vast…
Apple applications are easy to test. Compared to Android, that is. But when it comes…
Result-driven QA isn’t always about planning and strategizing. Sometimes, the best thing for your product…
A flimsy UI doesn’t lead to customer frustration, negative reviews, and high churn. When people…