{"id":171,"date":"2020-05-25T13:19:00","date_gmt":"2020-05-25T13:19:00","guid":{"rendered":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/?p=171"},"modified":"2020-07-21T10:19:52","modified_gmt":"2020-07-21T10:19:52","slug":"case-history-qa-strategy","status":"publish","type":"post","link":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/","title":{"rendered":"Simple Case History of the QA Strategy for Agile Teams"},"content":{"rendered":"\n

We would like to present our agile visualization tool, the QA battle plan, a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.<\/p>\n\n\n\n

Like a wrong architectural approach or using the wrong programming language, the wrong testing and quality assurance strategy can result in adverse effects during the course of a project. In the best case, it only causes delays or additional expenses. In the worst case, the tests done prove to be insufficient, and severe deviations occur repeatedly when the application is used.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Introduction<\/strong><\/h2>\n\n\n\n

Agile development teams notice issues and document their effects in the Retrospectives, but they are often unable to identify the root cause, and therefore cannot solve the problem because they lack QA expertise. In such cases, the teams need the support of an agile QA coach. This coach is characterized on the one hand by his knowledge of the agile working method, and on the other hand by his experience in agile quality assurance.<\/p>\n\n\n\n

The first step in the agile QA coach\u2019s work is recording the status quo of the testing methods of the agile development team. For this purpose, he will use the QA battle plan, e.g. within the framework of a workshop. The QA battle plan provides a visual aid to the development teams which they can use to assess the planning aspects of quality assurance. Throughout the project, the QA battle plan can also be used as a reference for the current procedure and as a basis for potential improvements.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

Anti-patterns<\/strong><\/h2>\n\n\n\n

In addition, the QA battle plan makes it possible to study the case history of the current testing method. By means of this visualization, the agile QA coach can reveal certain anti-pattern symptoms in the quality assurance and testing process, and discuss them directly with the team. In software development, an anti-pattern is an approach that is detrimental or harmful to a project\u2019s or an organization\u2019s success.<\/p>\n\n\n\n

I will describe several anti-patterns below. In addition to the defining characteristics, I will present their respective effects. As a contrast to the anti-pattern, the pattern\u2014good and proven problem-solving approaches\u2014will also be presented.<\/p>\n\n\n\n

<\/div>\n\n\n\n

The \u201cIt\u2019ll be just fine\u201d Anti-pattern<\/strong><\/h2>\n\n\n\n

This anti-pattern is characterized by the complete lack of testing or other quality assurance measures whatsoever. This can cause severe consequences for the project and the product. The team cannot make any statement regarding the quality of their deliverables, and consequently, they do not, strictly speaking, have a product that is ready for delivery. Errors occur upon use by the end user, repeatedly distracting the team from the development process because they have to analyze and rectify these so-called incidents, which is time-consuming and costly.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
No testing<\/th>Effect<\/th>Solution<\/th><\/tr><\/thead>
\u2022 There are no tests<\/td>\u2022 No quality statement<\/td>\u2022 \u201cLeave quickly\u201d<\/td><\/tr>
<\/td>\u2022 Testing is done in the user\u2019s environment<\/td>\u2022 Introduce QA<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n

The solution is simple: Test! The sooner deviations are discovered, the easier it is to remove them. In addition, quality assurance measures such as code reviews and static code analysis are constructive measures for consistent improvement.<\/p>\n\n\n\n

<\/div>\n\n\n\n

The Dysfunctional Test Anti-pattern<\/strong><\/h2>\n\n\n\n

ISO 25010 specifies eight quality characteristics for software: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. When new software is implemented, the focus is most often on functional suitability, but other characteristics such as security and usability play an important role today as well. The higher the priority of the other quality characteristics, the more likely a non-functional test should be scheduled for them.<\/p>\n\n\n\n

Therefore, the first question to be asked at the start of a software project is: Which quality characteristics does the development, and therefore the quality assurance, focus on? To facilitate the introduction of this topic to the teams, we use the QA octant. The QA octant contains the quality characteristics for software systems according to ISO 25010. These characteristics also point to the necessary types of tests that result from the set weighting of the different functional and non-functional characteristics.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
Functional tests only<\/th>Effect<\/th>Solution<\/th><\/tr><\/thead>
\u2022 There are only functional tests<\/td>\u2022 No quality statement about non-functional characteristics<\/td>\u2022 Discuss important quality characteristics with the client<\/td><\/tr>
<\/td>\u2022 It works as required, but\u2026<\/td>\u2022 Non-functional test types<\/td><\/tr>
<\/td><\/td>\u2022 Start with the QA octant<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n

The Attack of the Development Warriors Anti-pattern<\/strong><\/h2>\n\n\n\n

Many agile development teams\u2014especially teams that consist only of developers\u2014only rely on development-related tests for their QA measures. Usually, they only use unit and component tests for this purpose. Such tests can easily be written with the same development tool and promptly be integrated in the development process. The possibility to obtain information about the coverage of the tests with respect to the code by means of code coverage tools is particularly convenient in this context. Certainty is quickly achieved if the code coverage tool reports 100% test coverage. But the devil is in the detail, or in this case, in the complexity. This method would be sufficient for simple applications, but with more complex applications, problems arise.<\/p>\n\n\n\n

With highly complex applications, errors may occur despite a convenient unit test coverage, and such errors can only be discovered with extensive system and end-to-end tests. And for such extensive tests, the team needs advanced QA know-how. Testers or trained developers have to address the complexity of the application at higher levels of testing in order to be able to make an appropriate quality statement.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
The attack of the development warriors<\/th>Effect<\/th>Solution<\/th><\/tr><\/thead>
\u2022 Development-related tests only<\/td>\u2022 No end-to-end test<\/td>\u2022 Include a tester in the team<\/td><\/tr>
\u2022 No tester on the team<\/td>\u2022 Bugs occur with complex features<\/td>\u2022 Test at higher levels of testing<\/td><\/tr>
\u2022 100% code coverage<\/td>\u2022 Quick<\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n

The \u201cSpanish Option\u201d Anti-pattern<\/strong><\/h2>\n\n\n\n

The time in which a function has been coded and is integrated into the target system is becoming ever shorter. Consequently, the time for comprehensive testing is becoming shorter as well. For agile projects with fixed iterations, i.e. sprints, another problem arises: The number of functions to be tested increases with every sprint.<\/p>\n\n\n\n

Plain standard manual tests cannot handle this. Therefore, testers and developers should work together to develop a test automation strategy.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
Manual Work<\/th>Effect<\/th>Solution<\/th><\/tr><\/thead>
\u2022 There are only manual tests<\/td>\u2022 Delayed feedback in case of errors<\/td>\u2022 Everybody shoulders part of the QA work<\/td><\/tr>
<\/td>\u2022 Testers are overburdened<\/td>\u2022 Test at all levels of testing<\/td><\/tr>
<\/td><\/td>\u2022 Introduce automation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n

The Automated Regression Gap Anti-pattern<\/strong><\/h2>\n\n\n\n

A project without any manual tests would be the other extreme. Even though this means a high degree of integration in the CI\/CD processes and quick feedback in case of errors, it also causes avoidable problems. A high degree of test automation requires great effort\u2014both in developing the tests and in maintenance. The more complex the specific applications, and the more sophisticated the technologies used, the higher the probability of test runs being stopped due to problems occurring during the test run, or extensive reviews of test deviations being required. Furthermore, most automated tests only test the regression. Consequently, automated tests would never find new errors, but only test the functioning of the old features.<\/p>\n\n\n\n

Therefore, automation should always be used with common sense, and parallel manual and, if necessary, explorative tests should be used to discover new deviations.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
100% test automation<\/th>Effect<\/th>Solution<\/th><\/tr><\/thead>
\u2022 There are only automated tests<\/td>\u2022 Very high effort<\/td>\u2022 Automate with common sense<\/td><\/tr>
<\/td>\u2022 Everybody is overexerted<\/td>\u2022 Manual testing makes sense<\/td><\/tr>
<\/td>\u2022 Build stops due to problems<\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n

The Test Singularity Anti-pattern<\/strong><\/h2>\n\n\n\n

Tests of different types and at different levels each have a different focus. Consequently, they each have different requirements regarding the test environment, such as stability, test data, resources, etc. Development-related test environments are frequently updated to new versions to test the development progress. Higher levels of testing or other types of tests require a steadier version status over a longer period of time.<\/p>\n\n\n\n

To avoid possibly compromising the tests due to changes in the software status or a modified version, a separate test environment should be provided for each type of test.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
One Test Environment<\/th>Effect<\/th>Solution<\/th><\/tr><\/thead>
\u2022 There is only one test environment<\/td>\u2022 No test focus possible<\/td>\u2022 Several test environments<\/td><\/tr>
<\/td>\u2022 Compromised tests<\/td>\u2022 By level of testing or test focus<\/td><\/tr>
<\/td>\u2022 No production-related tests<\/td>\u2022 \u201cOne test environment per type of test\u201d<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n

The \u201cManual\u201d Building Anti-pattern<\/strong><\/h2>\n\n\n\n

State-of-the-art development depends on fast delivery, and modern quality assurance depends on the integration of the automated tests into the build process and the automated distribution of the current software status to the various (test) environments. These functions cannot be provided without a build or CI\/CD tool.<\/p>\n\n\n\n

If there are still tasks to be done relating to the provision of a CI\/CD process in a project, they can be marked as \u201cto do\u201d on the board.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
No Build Tool<\/th>Effect<\/th>Solution<\/th><\/tr><\/thead>
\u2022 There is no build tool<\/td>\u2022 No CI\/CD<\/td>\u2022 Introduce CI\/CD<\/td><\/tr>
<\/td>\u2022 Slow delivery<\/td>\u2022 Highlight gaps on the board<\/td><\/tr>
<\/td>\u2022 Delayed test results<\/td><\/td><\/tr>
<\/td>\u2022 Dependent on resources<\/td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n

The Early Adopter Anti-pattern<\/strong><\/h2>\n\n\n\n

New technologies usually involve new tools, and new versions involve new features. But introducing new tools and updating to new versions also entail a certain risk. It is advisable to proceed with care, and not to change the parts\/tools of the projects all at once.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
Early Adopter<\/th>Effect<\/th>Solution<\/th><\/tr><\/thead>
\u2022 Always the latest of everything\u2026<\/td>\u2022 Challenging training<\/td>\u2022 No big bang<\/td><\/tr>
<\/td>\u2022 Deficiencies in skills<\/td>\u2022 Old tools are familiar<\/td><\/tr>
<\/td>\u2022 New problems<\/td>\u2022 Highlight deficiencies in skills on the board<\/td><\/tr><\/tbody><\/table><\/figure>\n","protected":false},"excerpt":{"rendered":"

In this post the QA Navigation Board is presented as a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.<\/p>\n","protected":false},"author":65,"featured_media":465,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","footnotes":""},"categories":[7],"tags":[218,219,220,221,222,223,224,225,17,226,19,203,207,214,215,216,217],"topics":[85],"class_list":["post-171","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-quality-assurance","tag-test-environment","tag-test-data","tag-case-history","tag-functional-tests","tag-dysfunctional-tests","tag-test-singularity","tag-test-management","tag-manual-tests","tag-quality-assurance","tag-automated-tests","tag-qa-navigation-board","tag-editorschoice","tag-anti-pattern","tag-git","tag-selenium","tag-plugins","tag-xray","topics-qa-navigation-board"],"acf":[],"yoast_head":"\nSimple Case History of the QA Strategy - ZEISS Digital Innovation Blog<\/title>\n<meta name=\"description\" content=\"We would like to present the QA Navigation Board, a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Simple Case History of the QA Strategy - ZEISS Digital Innovation Blog\" \/>\n<meta property=\"og:description\" content=\"We would like to present the QA Navigation Board, a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/\" \/>\n<meta property=\"og:site_name\" content=\"Digital Innovation Blog\" \/>\n<meta property=\"article:published_time\" content=\"2020-05-25T13:19:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-07-21T10:19:52+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a.png\" \/>\n\t<meta property=\"og:image:width\" content=\"2000\" \/>\n\t<meta property=\"og:image:height\" content=\"1125\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Kay Grebenstein\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Kay Grebenstein\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"8 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/\",\"name\":\"Simple Case History of the QA Strategy - ZEISS Digital Innovation Blog\",\"isPartOf\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a.png\",\"datePublished\":\"2020-05-25T13:19:00+00:00\",\"dateModified\":\"2020-07-21T10:19:52+00:00\",\"author\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/6dc424ee6360e5a9547865996d0aca1d\"},\"description\":\"We would like to present the QA Navigation Board, a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.\",\"breadcrumb\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#primaryimage\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a.png\",\"contentUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a.png\",\"width\":2000,\"height\":1125},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Simple Case History of the QA Strategy for Agile Teams\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#website\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/\",\"name\":\"Digital Innovation Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/6dc424ee6360e5a9547865996d0aca1d\",\"name\":\"Kay Grebenstein\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/grebenstein_kay-1-150x150.jpg\",\"contentUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/grebenstein_kay-1-150x150.jpg\",\"caption\":\"Kay Grebenstein\"},\"description\":\"Kay Grebenstein worked as a tester and agile QA coach for ZEISS Digital Innovation, Dresden. He ensured quality and tested software in projects in various specialist domains (telecommunications, industry, mail order, energy, ...). He still shares his experiences at conferences, meetups and in publications of various kinds.\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/author\/enkaygrebenstein\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Simple Case History of the QA Strategy - ZEISS Digital Innovation Blog","description":"We would like to present the QA Navigation Board, a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/","og_locale":"en_US","og_type":"article","og_title":"Simple Case History of the QA Strategy - ZEISS Digital Innovation Blog","og_description":"We would like to present the QA Navigation Board, a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.","og_url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/","og_site_name":"Digital Innovation Blog","article_published_time":"2020-05-25T13:19:00+00:00","article_modified_time":"2020-07-21T10:19:52+00:00","og_image":[{"width":2000,"height":1125,"url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a.png","type":"image\/png"}],"author":"Kay Grebenstein","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Kay Grebenstein","Est. reading time":"8 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/","name":"Simple Case History of the QA Strategy - ZEISS Digital Innovation Blog","isPartOf":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#primaryimage"},"image":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#primaryimage"},"thumbnailUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a.png","datePublished":"2020-05-25T13:19:00+00:00","dateModified":"2020-07-21T10:19:52+00:00","author":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/6dc424ee6360e5a9547865996d0aca1d"},"description":"We would like to present the QA Navigation Board, a tool that allows agile development teams to recognize and eliminate typical QA issues and their effects.","breadcrumb":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#primaryimage","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a.png","contentUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a.png","width":2000,"height":1125},{"@type":"BreadcrumbList","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/case-history-qa-strategy\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/"},{"@type":"ListItem","position":2,"name":"Simple Case History of the QA Strategy for Agile Teams"}]},{"@type":"WebSite","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#website","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/","name":"Digital Innovation Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/6dc424ee6360e5a9547865996d0aca1d","name":"Kay Grebenstein","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/#\/schema\/person\/image\/","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/grebenstein_kay-1-150x150.jpg","contentUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/grebenstein_kay-1-150x150.jpg","caption":"Kay Grebenstein"},"description":"Kay Grebenstein worked as a tester and agile QA coach for ZEISS Digital Innovation, Dresden. He ensured quality and tested software in projects in various specialist domains (telecommunications, industry, mail order, energy, ...). He still shares his experiences at conferences, meetups and in publications of various kinds.","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/author\/enkaygrebenstein\/"}]}},"author_meta":{"display_name":"Kay Grebenstein","author_link":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/author\/enkaygrebenstein\/"},"featured_img":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-content\/uploads\/sites\/3\/2020\/05\/202005_Case_History_QA_Navigation_Board_1a-600x338.png","coauthors":[],"tax_additional":{"categories":{"linked":["<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">Quality Assurance<\/a>"],"unlinked":["<span class=\"advgb-post-tax-term\">Quality Assurance<\/span>"]},"tags":{"linked":["<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">test environment<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">test data<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">case history<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">functional tests<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">dysfunctional tests<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">test singularity<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">test management<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">manual tests<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">quality assurance<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">automated tests<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">qa navigation board<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">Editor's Choice<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">anti-pattern<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">GIT<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">Selenium<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">Plugins<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/category\/quality-assurance\/\" class=\"advgb-post-tax-term\">XRAY<\/a>"],"unlinked":["<span class=\"advgb-post-tax-term\">test environment<\/span>","<span class=\"advgb-post-tax-term\">test data<\/span>","<span class=\"advgb-post-tax-term\">case history<\/span>","<span class=\"advgb-post-tax-term\">functional tests<\/span>","<span class=\"advgb-post-tax-term\">dysfunctional tests<\/span>","<span class=\"advgb-post-tax-term\">test singularity<\/span>","<span class=\"advgb-post-tax-term\">test management<\/span>","<span class=\"advgb-post-tax-term\">manual tests<\/span>","<span class=\"advgb-post-tax-term\">quality assurance<\/span>","<span class=\"advgb-post-tax-term\">automated tests<\/span>","<span class=\"advgb-post-tax-term\">qa navigation board<\/span>","<span class=\"advgb-post-tax-term\">Editor's Choice<\/span>","<span class=\"advgb-post-tax-term\">anti-pattern<\/span>","<span class=\"advgb-post-tax-term\">GIT<\/span>","<span class=\"advgb-post-tax-term\">Selenium<\/span>","<span class=\"advgb-post-tax-term\">Plugins<\/span>","<span class=\"advgb-post-tax-term\">XRAY<\/span>"]}},"comment_count":"0","relative_dates":{"created":"Posted 6 years ago","modified":"Updated 6 years ago"},"absolute_dates":{"created":"Posted on May 25, 2020","modified":"Updated on July 21, 2020"},"absolute_dates_time":{"created":"Posted on May 25, 2020 1:19 pm","modified":"Updated on July 21, 2020 10:19 am"},"featured_img_caption":"","series_order":"","_links":{"self":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/posts\/171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/users\/65"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/comments?post=171"}],"version-history":[{"count":11,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/posts\/171\/revisions"}],"predecessor-version":[{"id":808,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/posts\/171\/revisions\/808"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/media\/465"}],"wp:attachment":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/media?parent=171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/categories?post=171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/tags?post=171"},{"taxonomy":"topics","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/en\/wp-json\/wp\/v2\/topics?post=171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}