| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
What to test
Testing sub-task for every user story
Comments, tips, tricks, data, screenshots, risks, test results, test cases
Additional information about testing of the specific user story
Why to test
For purpose of proof our testing and results
When someone asks, how did you test it or how should I test it? We need to know the answer
For purpose of a tutorial:
for QA - We need to test user story again in late phases /in regression tests and we need to know how
for customer - Customer will test feature ideally in the sprint acceptation and for sure in UAT. He needs to know how (how to set data, in which tables, what to calculate and where to find it)
For other QA - Hand over knowledge between QAs
For purpose of a testing documentation
when feature is complex, we need to have some call or chat with CE/IE/SA/client. This additional information about testing, we need to store here (not in our private files).
For purpose of reporting.
subtasks are easy to add into dashboard or report
we could have an overview about our testing
For purpose of clear comments in user story
when we have some information about testing is not needed to put in comments in user story - it will be mess in the future. This testing informations should have be in separate space - subtasks
Where to test
in every user story is button “create subtask“
after click - new subtask is created
name of this subtask should be “Testing“
How to test
It is easy to manage status of the subtasks
Open - you have not started yet
In progress
Closed - testing has been done
Better to have some additional information in JIRA, than everywhere else.
Added value for us and for client
Examples
...
Testing Actual Price Calculation Based on YearMonth Average
In this sub-task, we are testing the calculation of the actual price, which is determined as the average of the current yearMonth.
The test cases involve scenarios for different countries and include negative tests to ensure robustness. For the France scenario, we verify that the tyre_id from Rollups matches the dealerWebsite_selection in the PP table.
We ensure it meets the requirements for inclusion in pricing analysis.
We also find the product for the specified tyre_id (170935) with SKU 004977 and validate that it can be found using lizeo_tyre_id in the Product master.
Then, we create a LPG (Local Price Guide) for this product and country.
You must make sure that the SO online price field contains the average of valid values from rollUp, as calculated in an Excel file.
For the US scenario, we ensure that the lizeo_Tyre_id 91436 and SKU 253313_66380 are correctly linked to the product and validate that the Michelin actual SO retail price and its average from Rollup are correctly reflected in USD for LPG "JanTest12 - AMN retail SO price."
In the EU3 scenario, we verify that the product with SKU 004977 has correct pricing data for France within the EU3 LPG, as there is no data for other countries.
Additionally, we conduct negative tests to ensure that discrepancies in dates are appropriately handled. One such example is setting an empty including in pricing analysis.
These test cases directly address the requirements outlined in the sub-task and have been executed to ensure the accuracy and reliability of the actual price calculation.
Moreover we are looking if LPG is not matched with external data.
Validating System Functionality Across Multiple Scenarios
In this quality assurance test, the focus is on testing various aspects of the system, including specific scenarios for different regions and conducting negative tests to ensure robustness. The focus here includes the PP table competitiveness targets, PX table dealer website selection, RollUp for AMN/EU, and LPG with proper settings.
The tests conducted cover specific scenarios such as France with one competitor, AMN with two competitors, and AMN2 with one competitor, all of which have been verified as "OK."
Additionally, specific checks and validations have been performed for the Europe region, particularly for France, involving data from LPG id(74) - JanPack - France with SKU: 742184 and lizeo_tyre_id = 17985.
In this context, it is crucial to exercise caution regarding the data in the competitiveness target table. For this specific test case, it is essential to have relevant records in this table for calculation purposes. These values should be retrieved from the PP table to ensure accurate testing and validation.
Table checks have been carried out to ensure that all fields in LPG are properly filled, including verifying records in catCom, lizeoProductReferences, productMaster, cost (with SKU: 742184), and currentPrices (with SKU: 742184).
In this scenario, the focus is on a specific competitor with the lizeo_tyre_id 163279.
The RollUp data indicates an average (AVG) of 139.12 for this competitor. Additionally, the competitor matching in the PX table has been verified.
The competitiveness target in the PP table for the United States is set as 406.MLTV6 with a default value of *.
The LPG has been tested and confirmed as working, with values that align correctly with the calculated results.
We are checking that the values are working correctly according to calculations.
Further checks have been made in DATAMART_EU to ensure that the product is present, as its absence would impact the calculation of the SO actual price.
Checks in the PP table dealerWebsiteSelection_EU have been conducted to validate website/dealer or website/dealer aggregation.
We are also making sure that the "include in pricing analysis" field is set to "YES."
The verification of the counted SO price actual in LPG has been confirmed as 122.59.
In this scenario, the focus is on setting competitors for pack pricing, where it is necessary to add competitors for the base product. The pack price elements are then calculated based on these competitors. Specifically, the lizeo_tyre_id is 10068, and the SKU is 355408.
Competitors' settings for Pack pricing have been tested, including the addition of competitors for the base product and the matching of competitors in the PX table.
The competitiveness target in the PP table for Europe has been checked to ensure compliance within and outside the target range.
In this case, the test involves scenarios where the competitiveness targets in the PP table for Europe are adjusted, specifically changing the minimum target index to 81, which aligns with the conditions outlined in the attached Excel file. This test evaluates the system's behavior when the competitiveness targets fall outside the designated range.
Specific tests have also been conducted for AMN and AMN2, including validations of LPG, Datamart, PP table, competitiveness target, and competitor matching.
Negative tests have been carried out to assess scenarios where index MIN/MAX is not filled in the PP table and to verify the calculation with Intex target.
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
|
Testing Website/Dealer Table Functionality
In the EU sub-task, the focus is on testing the DealerWebsite Selection for Europe, specifically in Slovakia, where the aggregation has been modified on two rows.
For data load testing purposes, a sample data filter is applied to expedite the testing process, and the "incremental" option should be turned off. A specific lizeo_tyre_id and country, such as Slovakia, are chosen for testing. After applying the filter and copying it from the grid, the data load is saved by clicking on the floppy disk icon. It's noted that in a previous issue, formula outputs were not ticked in the calculation, emphasizing their importance for proper functionality. The data load process is initiated by clicking on "Run now" and awaiting job completion.
In the Data mart sub-task, data filtering is performed to align with the filter applied during data load testing, focusing on Slovakia and lizeo_tyre_id 82197.
The testing includes verifying that as new websites are added to the table, it is appropriately updated. It encompasses validating the ability to select websites for competitiveness calculations based on the "Include in Pricing Analysis" field and to manually specify the "website/dealer aggregation" for each website, with a focus on filtering capabilities and mass editing efficiency. Furthermore, the sub-task involves ensuring that modifications made to "Include in Pricing Analysis" and "website/dealer aggregation" are preserved and not lost when the table is updated due to changes in websites or dealers in the SO data, specifically through a PP table check.
NOTE:
view of subtasks in sprint dashboard should be turned off in Jira dashboard setting (ask
...
your project manager for this change)
should be used quick filter for this change
subtasks should not be visible in swim-lanes
learn how to remove sub-task from Scrum/Kanban board
