
<p>The iterative approach to software development emerged around the 1990s. What started as a small co-located, self-sustaining team approach was widely adopted by many development teams. The agile mindset paved way for multiple development frameworks, including the infamous “Scrum methodology”. </p>



<p>With time, processes undergo metamorphoses, during which a few unpleasant practices sneak in causing distractions within the teams. This article focuses on a few unpleasant software testing distractors within an Agile Scrum team.&nbsp;&nbsp;</p>



<p>The below agile testing distractors may not have a significant impact in plain sight, if left unattended they may cause potential harm in the long run.&nbsp;</p>



<div id="toc_container" class="no_bullets"><p class="toc_title">Table Of Contents</p><ul class="toc_list"><li><a href="#Muted_Refinement_sessionsnbsp"><span class="toc_number toc_depth_1">1</span> Muted Refinement sessions&nbsp;</a></li><li><a href="#Absence_of_testing_notesnbsp"><span class="toc_number toc_depth_1">2</span> Absence of testing notes&nbsp;</a></li><li><a href="#Separate_QA_boardnbsp"><span class="toc_number toc_depth_1">3</span> Separate QA board&nbsp;</a></li><li><a href="#Ignored_test_effortsnbsp"><span class="toc_number toc_depth_1">4</span> Ignored test efforts&nbsp;</a></li><li><a href="#Commenting_defectsnbsp"><span class="toc_number toc_depth_1">5</span> Commenting defects&nbsp;</a></li><li><a href="#Piggybacking_testersnbsp"><span class="toc_number toc_depth_1">6</span> Piggybacking testers&nbsp;</a></li></ul></div>
<h2 id="h-muted-refinement-sessions"><span id="Muted_Refinement_sessionsnbsp"><strong>Muted Refinement sessions&nbsp;</strong></span></h2>



<div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh6.googleusercontent.com/sXomQO3fUniztvQJkVhL5aaLVmojX6kgllxDRl6VcT_oVXcPEXhht-HsWY2Bdq-4Exi56oTV2JAMnvJ8q87DolB5JnwVaSlyB2EwCGksvBfeQRVsSerCo31HmogvGa4MksGSV0BRZ3cGBnGbe-c" alt="Muted Refinement sessions" width="400" height="400"/><figcaption>The unpleasant phenomenon in Agile testing 1&nbsp;</figcaption></figure></div>



<p style="padding-top: 20px">By default, the complexity of a user story is linked to developmental effort conveniently ignoring the testing effort involved. Sometimes implementation would hardly take any time but, the impact of this change stimulates a larger blast radius which significantly boosts the time required for testing. </p>



<p>A user story is complete and common understanding is established only if the story is addressed in 360degrees. Test implications should be considered during refinement sessions. Test <a href="https://testsigma.com/blog/quality-engineering-discussions-with-james-espie/" target="_blank" rel="noopener">engineers should facilitate this discussion</a> with the product owner and the wider development team during the refinement session.&nbsp;</p>



<h2 id="absence-of-testing-notes"><span id="Absence_of_testing_notesnbsp"><strong>Absence of testing notes&nbsp;</strong></span></h2>



<p>Refinement sessions provide a good opportunity for the PO(Product Owner) and the development team to scrub through the user story and add more details. Breaking down a user story into implementable tasks, clarifying any open questions, and validating certain aspects of implementations are the main aim of refinement meetings. However, most of the teams miss out on capturing the test notes.&nbsp;</p>



<p>Let us first discuss what a testing note is?&nbsp;</p>



<p><p style="padding-bottom: 30px">The supplemental details required to execute the tests for that particular user story is called a testing note. It can be any details like &#8211; test data, plugin requirements, dependency on external services, test limitations, test relevancy, etc.</p></p>



<div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh5.googleusercontent.com/5vtx-1rhghBdiJ_9puW34i9d3j70PtyOIeClmqtcu9n765OorbqDPmzfsHe2GodvqESTJ_rpKrSIDCJ3sbs82ZHiiPEH7FbY3Kyhki6Ov4-nrkjM_-U1Hm0cG-BEf3N-B4w-c2oCWciOqz12dF8" alt="Absence of testing notes" width="400" height="400"/><figcaption>The unpleasant phenomenon in Agile testing 2&nbsp;</figcaption></figure></div>



<p style="padding-top: 20px">In real-world projects, not all stories can be tested in all environments.&nbsp;</p>



<p>For example: develop or test environments have limited configuration capacity and files of certain sizes cannot be processed. Capturing testing notes helps teams to bring clarity and a shared understanding of how a particular scenario can be approached. It also gives POs a good opportunity to understand the hidden risks.&nbsp;</p>



<h2 id="separate-qa-board"><span id="Separate_QA_boardnbsp"><strong>Separate QA board&nbsp;</strong></span></h2>



<p>Mainstream scrum boards restrict by displaying only the user stories movement across swim lanes. However, an agile <a href="https://testsigma.com/blog/how-to-be-an-active-tester/" target="_blank" rel="noopener">tester performs much more test activities</a> than just the new feature testing or regression testing. For example:&nbsp;</p>



<p>1. Supporting small hot-fixes&nbsp;</p>



<p>2. Short enhancements&nbsp;</p>



<p>3. Legacy applications support&nbsp;</p>



<p>4. Usability testing&nbsp;</p>



<p>5. Automating the user stories&nbsp;</p>



<p>6. Maintenance of automated scripts&nbsp;</p>



<p><p style="padding-bottom: 30px">7. TestOps etc</p></p>



<div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh3.googleusercontent.com/8T1QM1uf0AmUJEIGlHrHTYiwxdbU27VMf4Pu3xUW61U9_6HaxbFlSSvNhWL6Ydg7ralpHDt8lDrqAFepsPXmkH-D9PD5a7VOLHa9AsCIsWDNvFFgdBRApjlBg26eri1isQBBBTNo9uEMqGxBtGc" alt="Separate QA board" width="400" height="400"/><figcaption>The unpleasant phenomenon in Agile testing 3&nbsp;</figcaption></figure></div>



<br><div class="bg-primary cta">
<p class="fz-21 “pt-1” "><b>Easily automate your user stories with completely customizable no-code test automation tool Testsigma.</b></p>
<div class="d-flex mb-1" style="justify-content:space-evenly">
     <button class="btn cta-btn bg-white"><a href="https://github.com/testsigmahq/testsigma" target="_blank" rel="noopener noreferrer">Try Testsigma </a></button></div>
</div><br>



<p>By and large development teams remain unaware of any of these activities. Agile development team tasks should be as transparent as possible. The available capacity of every team member should be taken into account before pulling in sprint tasks. </p>



<p>Especially the automation tasks are separated out to different scrum boards, this is detrimental in a long run. To stop this from becoming a major distractor, all the peripheral test activities should be made visible in the sprint scrum board to account for overall delivery within the agile scrum team.&nbsp;</p>



<p>The idea is not to completely discourage having a separate QA scrum board, this can be handy in some <a href="https://testsigma.com/blog/agile-automation-testing-safe/" target="_blank" rel="noopener">scaled agile</a> teams when multiple scrum teams have to coordinate several tasks. However, the clarity of what should stay away from mainstream scrum boards should be given a thought.&nbsp;</p>



<h2 id="ignored-test-efforts"><span id="Ignored_test_effortsnbsp"><strong>Ignored test efforts&nbsp;</strong></span></h2>



<p>After scrubbing and combing the backlog in the refinement session, PO prepares a prioritized backlog list which will be presented in a scrum planning meeting. The development team maps each task against the size which implies the effort required to implement the story. Planning is a crucial scrum activity, and most teams miss out on taking testing efforts into account.&nbsp;</p>



<p><p style="padding-bottom: 30px">This is an anti-pattern in agile methodology. A story is considered to be complete only if it goes through development and testing activities. Agile teams should encourage every team member to actively participate in the planning poker session. Test Engineers should confidently step forward to provide their view on the user stories during the planning meetings.</p></p>



<div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh4.googleusercontent.com/NBe9UdY9kggu_biAxAuULTkvu9_TC8_E21miSZPLUwthN6hV9RZn5tMnuTVBmVVRDZfbBqTATQvgRR_XmO_AGerigjrD7j52oEh5Clh1vTYtSwKMukFWwDokguIa8WuAib_5rYaNim2BocT7zcA" alt="Ignored test efforts" width="400" height="400"/><figcaption>The unpleasant phenomenon in Agile testing 4&nbsp;</figcaption></figure></div>



<h2 id="commenting-defects"><span id="Commenting_defectsnbsp"><strong>Commenting defects&nbsp;</strong></span></h2>



<p><p style="padding-bottom: 30px">Agile recommends reducing waste and weeding out all the overhead activities. Development teams who do not use external bug reporting tools, encourage team members to report the bugs within the user story tickets. In such cases, the test team will miss out on the most valuable QA activity “root cause analysis”. Why is it even important? Defects are a mirror to the health of the application, a good quality report states the weak links and helps the development team in strengthening those areas which need deeper attention.</p></p>



<div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh5.googleusercontent.com/OvOyCBgRq_6ruLf6WjmnaLZM7_MdLqQSMXBByYQ0UBe4y-TEdIA2N8BRY2CgNcrB4w2iyML35Qdx3SvNiEaXZYn1wjmT0tBya2xi0kkYxpHNcXTzxLGzv-ivJovBMUthNoVUactR6xoKRBX-hUc" alt="Commenting defects" width="400" height="400"/><figcaption>The unpleasant phenomenon in Agile testing 5&nbsp;</figcaption></figure></div>



<p style="padding-top: 20px">Teams commenting defects within the user story will be unable to aggregate the bugs and feed the root cause analysis activity. The whole idea of iterative development is driven by continuous improvement, when defects are not accessible teams miss out on valuable intrinsic details. To avoid this becoming a distractor in agile testing, it is important to educate development teams about the importance of defect analysis and follow bug reporting either using dedicated tools or some other way where they can aggregate data over a period of time&nbsp;</p>



<h2 id="piggybacking-testers"><span id="Piggybacking_testersnbsp"><strong>Piggybacking testers&nbsp;</strong></span></h2>



<p>Early feedback helps development teams to adopt changes more easily. User stories checked earlier in the development cycle help to establish an early feedback loop. In the real world situation, when the user story is developed and tested PO’s are expected to do a walk-through and bring forth any changes if required.&nbsp;</p>



<p>POs/PM create dependency on testers to give them the demo of a new feature. If the tester and PO fail to catch up on time, the tickets just pile up in the QA lane thus increasing the cycle time. Apprehend this bottleneck even before it piles up to cause deeper issues. Encourage POs to put their hands on the application and try out the features themselves. Doing so not just reduce the latency but also helps business to understand how the feature fits with wider application.&nbsp;</p>



<p style="padding-top: 10px">Related reads:</p>



<p><a href="https://testsigma.com/regression-testing" target="_blank" rel="noreferrer noopener">https://testsigma.com/regression-testing </a><a href="https://testsigma.com/blog/common-challenges-in-continuous-testing/" target="_blank" rel="noreferrer noopener">https://testsigma.com/blog/common-challenges-in-continuous-testing/ <br></a><a href="https://testsigma.com/blog/top-test-automation-challenges-to-look-out-for/" target="_blank" rel="noreferrer noopener">https://testsigma.com/blog/top-test-automation-challenges-to-look-out-for/ </a><a href="https://testsigma.com/blog/understanding-agile-testing-framework/" target="_blank" rel="noreferrer noopener">https://testsigma.com/blog/understanding-agile-testing-framework/ </a><a href="https://testsigma.com/blog/challenges-insprint-automation-regression-testing/" target="_blank" rel="noreferrer noopener">https://testsigma.com/blog/challenges-insprint-automation-regression-testing/</a></p>


The Unpleasant Phenomenon In Agile Testing


<p>The core objective of both code coverage and test coverage remains the measurement metrics leveraged to simplify the assessment of the quality of application code. These are significant for developers to rectify any errors if discovered and enhance the overall quality of an application.</p>



<div id="toc_container" class="no_bullets"><p class="toc_title">Table Of Contents</p><ul class="toc_list"><li><a href="#Code_Coverage_vs_Test_Coverage_8211_Overview"><span class="toc_number toc_depth_1">1</span> Code Coverage vs Test Coverage &#8211; Overview</a><ul><li><a href="#What_is_Code_Coverage"><span class="toc_number toc_depth_2">1.1</span> What is Code Coverage?</a></li><li><a href="#What_is_Test_Coverage"><span class="toc_number toc_depth_2">1.2</span> What is Test Coverage?</a></li></ul></li><li><a href="#Code_Coverage_vs_Test_Coverage_8211_A_Comparison"><span class="toc_number toc_depth_1">2</span> Code Coverage vs Test Coverage &#8211; A Comparison</a></li><li><a href="#Code_Coverage_vs_Test_Coverage_Which_One_Should_You_Choose"><span class="toc_number toc_depth_1">3</span> Code Coverage vs Test Coverage: Which One Should You Choose?</a></li><li><a href="#Summary"><span class="toc_number toc_depth_1">4</span> Summary</a></li><li><a href="#Frequently_Asked_Questions"><span class="toc_number toc_depth_1">5</span> Frequently Asked Questions</a><ul><li><a href="#What_is_the_difference_between_code_coverage_and_feature_coverage"><span class="toc_number toc_depth_2">5.1</span> What is the difference between code coverage and feature coverage?</a></li></ul></li></ul></div>
<h2 id="code-coverage-vs-test-coverage-overview"><span id="Code_Coverage_vs_Test_Coverage_8211_Overview"><strong>Code Coverage vs Test Coverage &#8211; Overview</strong></span></h2>



<h3 id="what-is-code-coverage"><span id="What_is_Code_Coverage">What is Code Coverage?</span></h3>



<p>Code Coverage is the percentage of the source code executed by a test suite. It points out what has been tested and what has not been tested, thereby revealing untested paths. Tools such as JaCoCo or Istanbul usually visualize such data by pointing out areas where more tests are needed. High code coverage may imply high quality but does not guarantee it; it is a good metric for the effectiveness of testing.</p>



<h3 id="what-is-test-coverage"><span id="What_is_Test_Coverage">What is Test Coverage?</span></h3>



<p><a href="https://testsigma.com/blog/test-coverage/" target="_blank" rel="noreferrer noopener">Test Coverage</a> is the extent to which the testing process covers the software requirements or specifications. It ensures testing all aspects, both functional and non-functional, based on defined criteria. Sometimes, test coverage may be measured using requirement traceability matrices or similar tools.</p>



<p>This will help ensure that all features have been validated and verified against requirements, thus enhancing confidence in the product, though it does not coincide with the thoroughness of testing.</p>



<p>Check here &#8211; <a href="https://testsigma.com/blog/how-create-best-test-case-design-get-maximum-test-coverage/" target="_blank" rel="noreferrer noopener">How do You Ensure Test Coverage</a></p>



<h2 id="code-coverage-vs-test-coverage-a-comparison"><span id="Code_Coverage_vs_Test_Coverage_8211_A_Comparison"><strong>Code Coverage vs Test Coverage &#8211; A Comparison</strong></span></h2>



<p>Let us look into this table to know more:</p>



<figure class="wp-block-table"><table><tbody><tr><td><strong>Aspect</strong></td><td><strong>Code Coverage</strong></td><td><strong>Test Coverage</strong></td></tr><tr><td><strong>Definition</strong></td><td>Measures the percentage of code executed during testing.</td><td>The extent to which testing covers requirements/specifications.</td></tr><tr><td><strong>Advantages</strong></td><td>Identifies untested code, helps improve code quality, provides insights into testing effectiveness, helps in refactoring, and can lead to fewer bugs in production.</td><td>Ensures all features are validated, highlights gaps in testing, enhances confidence in product quality, facilitates requirement tracking, and encourages comprehensive test design.</td></tr><tr><td><strong>How to Measure?</strong></td><td>Tools like JaCoCo, Istanbul, or Clover are used to track executed lines/branches.</td><td>Through requirement traceability matrices or testing frameworks that align tests with requirements.</td></tr><tr><td><strong>Mechanisms</strong></td><td>Instrumentation of code, Static analysis.</td><td>Mapping requirements to test cases and test case reviews.</td></tr><tr><td><strong>Tools</strong></td><td>JaCoCo, Istanbul, Clover.</td><td>TestRail, HP ALM, Jira (with plugins).</td></tr></tbody></table></figure>



<p>Check here &#8211; <a href="https://testsigma.com/blog/test-coverage-techniques/" target="_blank" rel="noreferrer noopener">Test Coverage Techniques</a></p>



<h2 id="h-code-coverage-vs-test-coverage-which-one-should-you-choose"><span id="Code_Coverage_vs_Test_Coverage_Which_One_Should_You_Choose"><strong>Code Coverage vs Test Coverage: Which One Should You Choose?</strong></span></h2>



<p>It’s now time to address the elephant in the room – code coverage vs test coverage: which one to choose and why. As both of these are completely different measurement approaches, it won’t be justified to choose between the two. Code coverage is a quantitative measure and is more related to the <a href="https://www.geeksforgeeks.org/software-engineering-white-box-testing/" target="_blank" rel="noreferrer noopener">white-box testing</a> technique. While on the other hand, test coverage is a qualitative measure and a black-box testing approach.&nbsp;</p>



<p>So there’s no exact answer to this question &#8220;code coverage vs test coverage: which one to choose &#8220;, as it would entirely depend on your business requirements and the intricacy of the software application. In a majority of the cases, however, both test coverage and code coverage are used.</p>



<h2 id="h-summary"><span id="Summary"><strong>Summary</strong></span></h2>



<p>People have always mistaken both test coverage and code coverage to be the same term. But they don’t have anything in common!</p>



<p>For all the testers, having an in-depth analysis of code coverage and test coverage is vital. Not only do these techniques offer efficient testing, but also help developers save hundreds of hours and executives save resources.</p>



<p>Additionally, 100% code coverage should not be sought at any stage of SDLC because it will end up wasting more time and resources as developers would miss out on vital testing modules when short at the time.<br><br>None of the <strong>code coverage </strong>or <strong>test coverage </strong>is a perfect choice, but you should try both of them for a considerable amount of time. The combo would most likely yield the ideal results.</p>



<h2 id="frequently-asked-questions"><span id="Frequently_Asked_Questions"><strong>Frequently Asked Questions</strong></span></h2>



<h3 id="what-is-the-difference-between-code-coverage-and-feature-coverage"><span id="What_is_the_difference_between_code_coverage_and_feature_coverage">What is the difference between code coverage and feature coverage?</span></h3>



<p>Code coverage measures the percentage of code executed during tests, while feature coverage assesses whether all specified features or functionalities are tested.&nbsp;</p>





Test Coverage Metrics
<blockquote class="wp-embedded-content" data-secret="qUh8jJzk0z"><a href="https://testsigma.com/blog/test-coverage-metrics/">Test Coverage Metrics &#8211; A Complete Overview</a></blockquote><iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; clip: rect(1px, 1px, 1px, 1px);" title="&#8220;Test Coverage Metrics &#8211; A Complete Overview&#8221; &#8212; Testsigma Blog" src="https://testsigma.com/blog/test-coverage-metrics/embed/#?secret=9eK50ZbHwN#?secret=qUh8jJzk0z" data-secret="qUh8jJzk0z" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>


Test Automation Coverage
<blockquote class="wp-embedded-content" data-secret="fdeFMof11F"><a href="https://testsigma.com/blog/test-automation-coverage/">Test Automation Coverage | What it is &amp; How to Improve it?</a></blockquote><iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; clip: rect(1px, 1px, 1px, 1px);" title="&#8220;Test Automation Coverage | What it is &amp; How to Improve it?&#8221; &#8212; Testsigma Blog" src="https://testsigma.com/blog/test-automation-coverage/embed/#?secret=hgeV90fGLl#?secret=fdeFMof11F" data-secret="fdeFMof11F" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>


Flutter Test Coverage
<blockquote class="wp-embedded-content" data-secret="ORgMsVPya3"><a href="https://testsigma.com/blog/flutter-test-coverage/">Flutter Test Coverage | How to Generate &amp; Analyse Report?</a></blockquote><iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; clip: rect(1px, 1px, 1px, 1px);" title="&#8220;Flutter Test Coverage | How to Generate &amp; Analyse Report?&#8221; &#8212; Testsigma Blog" src="https://testsigma.com/blog/flutter-test-coverage/embed/#?secret=nATJX4qKCO#?secret=ORgMsVPya3" data-secret="ORgMsVPya3" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>


Test Coverage Techniques
<blockquote class="wp-embedded-content" data-secret="2w6vGo385P"><a href="https://testsigma.com/blog/test-coverage-techniques/">Test Coverage Techniques Used In Software Testing</a></blockquote><iframe class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; clip: rect(1px, 1px, 1px, 1px);" title="&#8220;Test Coverage Techniques Used In Software Testing&#8221; &#8212; Testsigma Blog" src="https://testsigma.com/blog/test-coverage-techniques/embed/#?secret=IxYkrbLA4c#?secret=2w6vGo385P" data-secret="2w6vGo385P" width="500" height="282" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>




feature image of Code Coverage vs Test Coverage

Code Coverage vs Test Coverage: Differences You Need to Know


<p>Working in software development as a tester, it can be difficult to find time to improve the testing process when you are the bottleneck to release with lots of tickets, stories or features to test. I am currently a QA Lead at <a href="https://cerahq.com/" target="_blank" rel="noreferrer noopener nofollow">Cera Care</a>, one of the fastest growing healthcare startups in Europe. Working in this fast moving environment is very challenging for my team, where features are prioritised over anything else and teams have up to 6 developers to 1 QA engineer. </p>



<p>As you can imagine this does not allow much time for activities outside of feature testing. Quality is compromised as the feature will be described as a minimal viable product (MVP). Improvements are added to the backlog to be implemented after the initial pilots or user feedback. </p>



<p>Before being able to tackle the quality technical debt another priority comes along meaning there is no time to revisit the feature. What has this got to do with being an active tester you might ask? Well, that’s where the testing role within my team has changed to more of an advisor and involves collaborating closely with developers, product, user experience (UX) and data.</p>



<figure class="wp-block-image is-resized"><img loading="lazy" src="https://lh6.googleusercontent.com/dI1RSiHdiHE94aLrHdLqNb1rn8ZBI_OFRwjrBFsRif39IG66YpL-gK413gqrMK512G4tQQHeHyZjVlieNb1eSgRIpg3jEKi0ect1jWj_lgGyBsX9Nb7zvOzdjuXFDZJyHJn3WtfoBRlBVShefA" alt="Testsigma - How To Be An Active Tester" width="600" height="400" /></figure>



<p>Tester stereotype by<a href="https://unsplash.com/@markusspiske?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" target="_blank" rel="noreferrer noopener nofollow"> Markus Spiske</a></p>



<div id="toc_container" class="no_bullets"><p class="toc_title">Table Of Contents</p><ul class="toc_list"><li><a href="#How_to_break_down_the_traditional_testers_stereotype"><span class="toc_number toc_depth_1">1</span> How to break down the traditional testers stereotype</a></li><li><a href="#Being_proactive_instead_of_reactive_in_testing"><span class="toc_number toc_depth_1">2</span> Being proactive instead of reactive in testing</a></li><li><a href="#Getting_involved_in_development_discussions"><span class="toc_number toc_depth_1">3</span> Getting involved in development discussions</a></li><li><a href="#Working_with_data_to_understand_user_funnels"><span class="toc_number toc_depth_1">4</span> Working with data to understand user funnels</a></li><li><a href="#Tester_participation_is_often_a_2_way_process"><span class="toc_number toc_depth_1">5</span> Tester participation is often a 2 way process</a></li><li><a href="#Testers_everywhere"><span class="toc_number toc_depth_1">6</span> Testers everywhere</a></li></ul></div>
<h2 id="how-to-break-down-the-traditional-testers-stereotype"><span id="How_to_break_down_the_traditional_testers_stereotype">How to break down the traditional testers stereotype</span></h2>



<p>Only a short while ago, I had a conversation with a startup founder who I explained the difference between checking and testing in relation to the value a tester can provide to the development process. With a strong product knowledge and an inquisitive mindset to explore the inner workings of a system. </p>



<p>The tester can get involved in conversations at the beginning of the development process. In my current organisation that starts with user research to discover what the current challenges are that the user is facing. At this stage the tester can sit in on the user research sessions or read the results that are published on dovetail. </p>



<p>This insight is invaluable for the testers to understand how the user would interact with the feature once it has been developed. They can form realistic scenarios when they come to explore the system and run their <a href="https://www.developsense.com/blog/2009/04/of-testing-tours-and-dashboards/" target="_blank" rel="noreferrer noopener nofollow">testing tours</a>.</p>



<h2 id="being-proactive-instead-of-reactive-in-testing"><span id="Being_proactive_instead_of_reactive_in_testing">Being proactive instead of reactive in testing</span></h2>



<p>Building on the participation of the tester in the user experience research phase. Sometimes you need help from other people and teams to enable your productivity. Such as investigating ways to make parts of the system easier to test with developers. Or finding data to improve your test data set with the data analysts. </p>



<p>This can be a frustrating process of waiting for others&#8217; time and delaying hands-on testing activities. This is where testers, by becoming an advisor, advocate or coach (however you want to describe it) can be very valuable. </p>



<p>Collaborating with the product team to make user stories clearer and easier to implement. Refining those acceptance criteria and improving the definition of done for development to include testing, monitoring and release documentation. This frees up testers time to concentrate on activities which refine the testing focus, increase the quality of the <a href="https://testsigma.com/blog/test-data/" target="_blank" rel="noreferrer noopener">test data</a> or open up almost impossible areas to test. </p>



<p>Read here more on <a href="https://testsigma.com/blog/active-testing/" target="_blank" rel="noreferrer noopener">Active Testing</a></p>



<div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh4.googleusercontent.com/QzLyZj5iRtUz5t2f0FzVXUlts-zI8BjQPBYnWbF0JZYep0BSgmE67_0RWV_b9d3_RhfzLFH8sVQLAfWNXu8JpYoVlY4O0DUqC0ociPv6Ls4aJctPmswaoDPJv72trMbL_TlgmHcpGPJu_622xg" alt="Testsigma - Being proactive instead of reactive in testing" width="600" height="400" /><figcaption>Developer and tester collaboration by<a href="https://unsplash.com/@charlesdeluvio?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" target="_blank" rel="noreferrer noopener nofollow"> charlesdeluvio</a></figcaption></figure></div>



<h2 id="getting-involved-in-development-discussions"><span id="Getting_involved_in_development_discussions">Getting involved in development discussions</span></h2>



<p>Whether you consider yourself a technical or non-technical person (what the word technical means in terms of testing is another blog article). You can always get involved in developer discussions such as “technical refinements” (also called whiteboarding sessions). </p>



<p>Raising questions around <a href="https://testsigma.com/blog/testability/" target="_blank" rel="noreferrer noopener">testability </a>and consistency across API specifications for example is really important to improve the quality of the application. Also at the code review stage of development, a tester can ask the developer to walk them through the feature and the tests they’ve implemented. Identify edge cases and discover any cases which aren’t covered by the automated checks. Understanding the test coverage and where to focus your testing can help identify issues quicker.</p>



<h2 id="working-with-data-to-understand-user-funnels"><span id="Working_with_data_to_understand_user_funnels">Working with data to understand user funnels</span></h2>



<p>One of the most powerful collaborations a tester can make in my opinion is working with the data team. Whether that be looking at user funnels or considering data requirements in the development process. Analysing data in customer data tools like segment can help you identify the most important parts of the system for your users. Also the aim of analysing production data is to validate test scenarios and possibly identify new scenarios. </p>



<p>Walking through the user funnels with data analysts can help understand what the data is saying. Statistics was never my strong point, despite studying it at A Level (UK college exams) and taking statistics modules at university in my psychology degree (You can read more about my journey on my blog). The data team also provides the bridge between the business and application data. For example in my organisation, reports provided by the data team are crucial for finance to pay employees on time.</p>



<p style="padding-bottom: 30px"> In this example, the data engineers extract and transform the data from the application databases. Meaning the data platform has no direct dependencies on the application itself, only the data in the database. This can lead to data issues downstream without any breaking changes within the application. See the diagram below to explain the complexities of what I described.</p>



<div class="wp-block-image"><figure class="aligncenter size-full is-resized"><img loading="lazy" src="https://testsigma.com/blog/wp-content/uploads/Data-dependencies-from-web-application.png" alt="Testsigma - Working with data to understand user funnels" class="wp-image-19599" width="600" height="400" /><figcaption>Data dependencies from web application</figcaption></figure></div>



<h2 id="tester-participation-is-often-a-2-way-process"><span id="Tester_participation_is_often_a_2_way_process">Tester participation is often a 2 way process</span></h2>



<p>Tester participation is a two way communication. With all the teams involved that I described above it can feel like as a tester you are the one always asking for people to help you out. However, it&#8217;s very much a two way street, later down the line everyone will appreciate your pestering and constant asking of questions. Working closely with these teams you can develop an understanding for each representative&#8217;s specific interests in the application, enabling you to understand and speak their language. </p>



<p>Putting in the effort to build these relationships and understand the team&#8217;s challenges will influence the quality of the product. Though it may seem very one sided. There are many situations where the tester will be called upon as well such as reproducing live issues from product owners, developers asking testers to create some test data, UX clarifying whether the designs are still up-to-date or data analysts requesting a dump of pre-production environment to run through their data pipeline.</p>



<h2 id="testers-everywhere"><span id="Testers_everywhere">Testers everywhere</span></h2>



<p>To wrap things up, testers pop up everywhere within the software development lifecycle (SDLC). Being curious is a key asset of the tester within the engineering function. Asking questions is another core skill to encourage conversations and discover unknown information. By participating in all the activities described here, a tester can discover interesting insights previously never discovered. </p>



<p>By collaborating with people across the engineering function, a tester can improve their communication with technical and non-technical people. Proactively exploring information from multiple sources helps to paint a clearer picture of the whole software development process and beyond.</p>



<p><button class="btn bg-primary cta-btn" style="margin: auto"><a style="color:#fff" href="https://github.com/testsigmahq/testsigma" target="_blank" rel="noopener noreferrer">Collaborate better on your test automation tasks with Testsigma, try it here.</a></button></p><br>



<p><strong>Related reads:</strong></p>



<p><a href="https://testsigma.com/blog/how-to-be-an-efficient-and-productive-software-tester/" target="_blank" rel="noreferrer noopener">How to be an efficient and productive software tester?</a></p>



<p><a href="https://testsigma.com/blog/how-to-be-an-open-minded-tester/" target="_blank" rel="noreferrer noopener">How To Be An Open-Minded Tester?</a></p>



<p><a href="https://testsigma.com/blog/different-types-of-tools-to-help-testers-day-to-day-life-easier/" target="_blank" rel="noreferrer noopener">Different Types Of Tools To Help Make Tester&#8217;s Day-To-Day Life Easier</a></p>



<p><a href="https://testsigma.com/blog/15-must-have-skills-for-a-top-automation-tester/" target="_blank" rel="noreferrer noopener">15 Must Have Skills For a Top Automation Tester</a></p>



<p><a href="https://testsigma.com/blog/how-to-become-an-automation-tester/" target="_blank" rel="noreferrer noopener">How to Become an Automation Tester</a></p>



<p></p>


How To Be An Active Tester ?

The era of Low-code/No-code platforms: What you should know?

The Era of Low Code No Code Platforms: What You Should Know?

Automated Functional Testing — How To Do and Best Practices?

How to Begin in Sprint Automation: A Tactical Guide

Cross-Platform-End-to-End-Testing–Explained-with-Real-life-scenarios

Cross Platform Testing: Best Practices & Essential Tools

Interview tips when appearing for QA roles

QA Interview Tips When Appearing for QA Roles


<p>&#8220;What QE leaders ask, when buying Test automation tools/platform&#8221;</p>



<p>First of all, what do we mean by QE?</p>



<p>They are Quality Engineers and they exist in every field like retail, manufacturing, software, SaaS, infrastructure etc.</p>



<p>I’m specifically going to talk with respect to Software testing Quality Engineers</p>



<p>Having worked as a Tester myself for first 8 years of my career at MNCs and Banks,&nbsp;I have a perspective from a client-vendor aspect or being the client myself 🙂&nbsp;</p>



<p>On top of it, having worked as a Solutions architect for 3 years now, for testing tools and platform and helped more than 300 + clients globally,&nbsp;</p>



<p>In this blog, I have shared points according to what I learnt about the needs of a testing team and their manager in any set-up or company, and what they expect when they want to buy a test automation tool or platform.</p>



<p><strong>Here are the top items from trivial to big ones, but all are absolutely important while making a decision:</strong></p>



<p><strong>1. Do I need a tool/ platform?</strong></p>



<p>I’m a tester first and any good tester would know the basic skill of asking questions like &#8211; Why do I need a tool in the first place? This would mean figuring out the limitations of your existing set-up too. For example &#8211; How do I make different devices available to my teams spread globally?</p>



<p>This could be a classic, typical question to need a test automation tool or platform. Thus, depending on a team’s requirements, this list of questions can be created.</p>



<p><strong>2. Will my team be happy using the tool?</strong></p>



<p>When choosing a tool, you should also know or understand the technical prowess and limitations of your team.</p>



<p>So, during a “proof of concept” phase while testing or trying out the tool,&nbsp;you can check with your team on different aspects:&nbsp;</p>



<ol><li>Ease of use of the tool</li><li>Availability / Up-time of the platform</li><li>Integrating the tool with any of your existing tech stack or frameworks.</li></ol>



<p>Why is this important?&nbsp;</p>



<p>Because ultimately, it’s the team who will be using the tool.&nbsp;</p>



<p>So, it&#8217;s important they know how to use the tool and be comfortable using it.</p>



<p><strong>3. Is the tool/ platform solving my problem?</strong></p>



<p>As it is, testing is a demanding job with last-minute changes and builds popping up.</p>



<p>None of the testers and their leaders wants to add to their trouble, if the tool itself is flaky, unstable, and cannot be depended on for results, then what’s the point of it?</p>



<p>The tool should be robust and solving either the need of the test project</p>



<p>Or a requirement or help the test team deliver better results.</p>



<p>For instance: I remember once a client in one of my companies was very particular about the record and playback feature in our product.</p>



<p>He wasn’t asking it for the heck of it; rather he wanted to help his testers transition into automation.</p>



<p>So, like the above example, the tool needs to help the team using it.</p>



<p><strong>4. Future goal for the team and the tool </strong></p>



<p>The software development cycle was forever highly agile and in this fast-paced era of ever-changing technological aspects, you would definitely want to think about the future goals of the team and project, and, what role will the Test automation tool/ platform be playing in it?</p>



<p>You may also want to think about this one with respect to the Return on investment (ROI) aspect; after all, you will be paying for the subscription model of the tool/platform.</p>



<p>A classic example of this question can be:</p>



<p>Will the tool help me in leveraging its features while creating a test pipeline a QA environment or w.r.t <a href="https://testsigma.com/continuous-integration" target="_blank" rel="noreferrer noopener">Continuous integration</a> or Continuous delivery?</p>



<p>💡 <strong>Pro tip&nbsp;</strong></p>



<p>Always take the trial of a tool, before you make the decision of buying it.</p>



<p><button class="btn bg-primary cta-btn" style="margin: auto"><a href="https://github.com/testsigmahq/testsigma" target="_blank" rel="noopener noreferrer" style="color:#fff">Try Testsigma, a tool that brings test automation to everyone.</a></button></p>



<p>I can go about adding an exhaustive list of pointers to make this list endless and unnecessary.</p>



<p>But, we as testers, always try to understand and emphasise on the Root Cause. And that is what I have tried to with this blog, without beating around the bush.&nbsp;</p>



<p>I hope you find value in it.&nbsp;</p>



<p></p>


Buying a Test Automation Platform? What do QE leaders ask?

Buying a Test Automation Platform? What do QE Leaders Ask?


<p>Many times, we spend our whole day planning out the activities but there is no real outcome. We think, plan, and decide to do multiple things in a day but unfortunately, we are not able to execute them. Reason? We will discuss the reasons and more in this blog.</p>



<p>As a Software Tester, we should be implementing the below tips/activities so that you can be a more efficient &amp; more productive, good tester :</p>



<div id="toc_container" class="no_bullets"><p class="toc_title">Table Of Contents</p><ul class="toc_list"><li><a href="#1_Understand_the_Requirements"><span class="toc_number toc_depth_1">1</span> 1. Understand the Requirements </a></li><li><a href="#2_Testcase_designing"><span class="toc_number toc_depth_1">2</span> 2. Testcase designing</a></li><li><a href="#3_Test_Data_Designing"><span class="toc_number toc_depth_1">3</span> 3. Test Data Designing </a></li><li><a href="#4_Identify_Smoke_Test"><span class="toc_number toc_depth_1">4</span> 4. Identify Smoke Test</a></li><li><a href="#5_Defect_Logging_Tracking"><span class="toc_number toc_depth_1">5</span> 5. Defect Logging &amp; Tracking</a></li><li><a href="#6_Clear_Communication"><span class="toc_number toc_depth_1">6</span> 6. Clear Communication </a></li><li><a href="#Conclusion"><span class="toc_number toc_depth_1">7</span> Conclusion</a></li></ul></div>
<h2 id="1-understand-the-requirements"><span id="1_Understand_the_Requirements"><strong>1. Understand the Requirements </strong></span></h2>



<p>The first &amp; foremost point is to understand the requirements to save your time as a tester. Once you understand the requirements, the purpose of the requirement, and the objective of the requirement &#8211; it will be easier for you to design your high-level scenarios. Then, based on your high-level scenarios, you can identify test cases that can be further used during your test execution.&nbsp;</p>



<p>You can consider the same while working in an Agile software development model as well. In Agile software development methodology, you will get user stories from clients. So, to save your time as a tester, you can analyze those user stories, by brainstorming sessions, collaborating within teams, etc. Once you understand the need for a particular user story, it will then become easy for you to test it.&nbsp;</p>



<p>It’s a good practice to implement in your day-to-day life while working on a software testing project.&nbsp;</p>



<h2 id="2-testcase-designing"><span id="2_Testcase_designing"><strong>2. Testcase designing</strong></span></h2>



<p>Often, it has been observed that we tend to lose our focus on <a href="https://testsigma.com/blog/test-case-design-techniques/" target="_blank" rel="noreferrer noopener">Testcase designing</a>. We, as a tester want to test the requirement as early as possible and complete the testing. This should not be the scenario nor should be the aim of a software tester. </p>



<p>Sometimes, testers write detailed test cases whereas some testers design test cases on a very high level. You can choose and design as per the test process being implemented in your current organization where you are currently working.&nbsp;</p>



<p>Testcases should be designed in such a way that it reflects end-user behaviour. If we design our test cases (keeping the user requirement in mind) then it will give you a good outcome in terms of <a href="https://testsigma.com/blog/test-coverage/" target="_blank" rel="noreferrer noopener">test coverage</a> as well as client satisfaction. </p>



<h2 id="3-test-data-designing"><span id="3_Test_Data_Designing"><strong>3. Test Data Designing </strong></span></h2>



<p>I am sure you will agree with me about the fact that test data is equally important as the other factors which I have described above.&nbsp;</p>



<p>Preparing good test data is very important for a software tester. When you create test data, you must include valid and invalid test data to test <a href="https://testsigma.com/blog/positive-and-negative-testing-scenarios/" target="_blank" rel="noreferrer noopener">positive and negative scenarios</a> of your application.</p>



<p>While test case designing, if you think you know what type of test data you will require, you can create that and keep it aside for your reference. Having said that, during test execution also, you can prepare your test data and use it as you progress.&nbsp;</p>



<h2 id="4-identify-smoke-test"><span id="4_Identify_Smoke_Test"><strong>4. Identify Smoke Test</strong></span></h2>



<p>If you want to be an efficient tester, try to identify the <a href="https://testsigma.com/blog/smoke-testing/" target="_blank" rel="noreferrer noopener">smoke tests</a> out of a test suite that you or somebody else in the team might have created to test a particular functionality. This practice will help you as and when you receive any new build. Whenever you receive any new build, you can consider the set of smoke tests to be executed and ensure that the build is stable for testing and that testing can be carried forward.</p>



<p>For example, You have a total of 100 test cases. You can segregate the main functionalities in the app and identify the smoke tests. You can create a separate folder and keep smoke tests aside to use it as and when you require.&nbsp;</p>



<p>This set of smoke tests can be modified depending upon the addition of new functionalities or changes when they occur as you progress in the project.&nbsp;</p>



<h2 id="5-defect-logging-tracking"><span id="5_Defect_Logging_Tracking"><strong>5. Defect Logging &amp; Tracking</strong></span></h2>



<p>While you are testing a feature in AUT (Application under Test), during test execution, it is obvious that you will come across some functionality that might not work as per the user requirements. So, in that case, you would be raising a defect and failing your test case.</p>



<p>As a software tester, you must supply all the required information about a defect and assign it to the respective person/developer who can investigate it and fix it. Steps to reproduce, environmental changes, screenshots, expected result vs actual result, etc. should be provided while creating a new defect. Here, is a related article: <a href="https://testsigma.com/blog/how-to-write-a-good-bug-report-some-tips/" target="_blank" rel="noreferrer noopener">how to write a good bug report</a>.</p>



<p>One important step which usually testers forget is to track the progress of their defects. Once you raise a new defect, it&#8217;s your responsibility to track that defect for you to re-test it and close the defect. </p>



<p>Here know the <a href="https://testsigma.com/blog/defect-tracking-tools/" target="_blank" rel="noreferrer noopener">Best Defect Tracking Tools </a></p>



<h2 id="6-clear-communication"><span id="6_Clear_Communication"><strong>6. Clear Communication </strong></span></h2>



<p>Whether you are a <a href="https://financesonline.com/top-20-it-development-software/" target="_blank" rel="noreferrer noopener nofollow">fresher in software testing</a> or an experienced professional, you must be able to clearly express your thoughts to others. Communication is key when you are dealing with your client, manager, team, Business Analyst, Product Owner, etc. It’s good to be technically strong but at the same time, it will add as a bonus for you if you communicate in a clear &amp; concise way.</p>



<p>💡 <strong>Pro tip&nbsp;</strong></p>



<p><a href="https://testsigma.com/automated-testing" target="_blank" rel="noreferrer noopener">Automate</a> Repetitive tasks using a Test Automation Tool.</p>



<p><p><button class="btn bg-primary cta-btn" style="margin: auto"><a href="https://github.com/testsigmahq/testsigma" target="_blank" rel="noopener noreferrer" style="color:#fff">Try Testsigma, a free and open-source tool for all your web and mobile test automation needs.</a></button></p><br></p>



<h2 id="conclusion"><span id="Conclusion">Conclusion</span></h2>



<p>Many of you may be already using the above tips whereas for others, it will be new. So, I would recommend you start implementing the above as soon as possible and you will observe changes in yourself as a software tester.&nbsp;</p>



<p>It will help you in being more efficient &amp; more productive with your work as well as you will add value to your organization &amp; the project you are working on. Let me quickly reiterate the points here for your benefit:</p>



<ol><li>Understand the requirements&nbsp;</li><li>Testcase designing</li><li>Test Data Designing</li><li>Identify Smoke Tests</li><li>Defect logging &amp; tracking</li><li>Clear Communication&nbsp;</li></ol>



<p>Thank you!</p>



<p class="has-small-font-size"><br><p class="has-small-font-size">PC: <a href="https://www.freepik.com/vectors/time-illustration" target="_blank" rel="noreferrer noopener nofollow">Time illustration vector created by freepik &#8211; www.freepik.com</a></p></p>


How to be an efficient and productive software tester?