Many years have passed since the first testing methodology made its way into SDLC processes. At the time, the software testing activities were simple and straightforward: validating the application against user requirements after the development stage was over. 



The times moved ahead, and the procedures evolved. Today, several testing types exist under the umbrella term of ‘software testing.’ Two of them are scripted testing and exploratory testing. They both have their own specifications, benefits and use cases that decide where you can use which approach. 



“Scripted Testing” is the primary topic of our blog. And our aim here is to help you understand the nuances of scripted testing and its differences from <a href="https://www.atlassian.com/continuous-delivery/software-testing/exploratory-testing#:~:text=Exploratory%20testing%20is%20an%20approach,the%20scope%20of%20other%20tests." target="_blank" rel="noreferrer noopener nofollow">exploratory testing</a>.



We will discuss the definition, benefits, and use cases of scripted testing. Alongside this, we will also highlight some of the major differences between the two testing types.



<div id="toc_container" class="no_bullets">Table Of Contents<ul class="toc_list"><li><a href="#What_is_Scripted_Testing">1 What is Scripted Testing?</a></li><li><a href="#Scripted_Testing_to_Automated_Testing">2 Scripted Testing to Automated Testing</a></li><li><a href="#When_to_Use_Scripted_Testing">3 When to Use Scripted Testing?</a></li><li><a href="#Exploratory_Testing_vs_Scripted_Testing_vs_Automated_Testing">4 Exploratory Testing vs Scripted Testing vs Automated Testing</a></li><li><a href="#Takeaway">5 Takeaway</a></li><li><a href="#Frequently_Asked_Questions_FAQs">6 Frequently Asked Questions (FAQs)</a><ul><li><a href="#What_is_manual_scripted_testing">6.1 What is manual scripted testing?</a></li><li><a href="#What_is_an_example_of_scripted_testing">6.2 What is an example of scripted testing?</a></li></ul></li></ul></div>
<h2 id="h-what-is-scripted-testing">What is Scripted Testing?</h2>



In software testing, scripted testing is an approach where the testing team follows a step-by-step procedure to check the application under test (AUT). The idea is to ensure that all necessary tests undergo execution during the testing phase. Therefore, the testers stick to a script that consists of all the necessary instructions to conduct the testing process.



Prior to starting the software test execution phase, the testing team needs to understand the user requirements, define the test cases, and follow the testing instructions and steps; basically, keep all the documents ready for testing purposes. While QAs can deviate from the script, it is usually nominal, not negatively affecting the testing potential.



Advantages 



Scripted testing offers multiple advantages other than maintaining all your test cases and instructions at one central location:



<ul><li>Test cases are designed as per requirements, which helps in creating test cases covering functional and non-functional aspects of the applications &#8211; according to the requirements</li><li>Test case tracking is easy as it follows user requirement documents</li><li>It is easy to access the scripts of other team members as well</li><li>Scripted testing is beneficial in understanding complex test scenarios where prior planning is necessary</li><li>It is helpful in identifying and removing redundant test cases, which further supports the move to <a href="https://testsigma.com/automated-testing" target="_blank" rel="noreferrer noopener">automated testing</a></li><li>It helps in determining usability and GUI issues with accuracy</li><li>Scripted testing assists testers in gaining proper knowledge about testing the application, even if they lack domain understanding.</li><li>It is easy to automate and follow through to record and understand the results</li></ul>



Disadvantages 



There are some disadvantages to scripted testing that you should know about:



<ul><li>It is possible to miss and overlook critical bugs as testers will only follow the test cases document as the reference</li><li>Designing and planning the test cases are a time-consuming process</li><li>It is not a suitable approach for a situation that calls for a quick and rapid response</li></ul>



<h2 id="h-scripted-testing-to-automated-testing">Scripted Testing to Automated Testing</h2>



When these scripted test cases are executed repeatedly, automating them makes sense. Automated testing executes test scripts without the need for human supervision and saves time and efforts. 



<div class="cta-banner-v2">
<div class="title-with-description ">
Here is a guide with in-depth discussions on do&#8217;s and don&#8217;ts of automated testing.
</div>
<a href="https://testsigma.com/automated-testing" target="_blank" class="cta-btn-v1" rel="noopener">Check out the Guide</a>
</div>



When you decide to automate your scripted tests, it is advised to choose the tool that is right for your requirements. Here is a blog that will help you choose the right tool for test automation. Testsigma is a tool that would be right for you if you are looking for: 



1. A tool that lets you start your test automation in minutes. 



2. Does not need you to be an expert at coding. 



3. Lets you automate for web, mobile, APIs and desktop from the same place. 



For more features of Testsigma, check <a href="https://testsigma.com">here</a>. 



 <h2 id="h-when-to-use-scripted-testing">When to Use Scripted Testing?</h2>



As scripted testing is a group of all things necessary in software testing, there are a few scenarios you should know about to implement this process. For instance, scripted testing is the best approach when working on complex and high-risk applications. Some examples of where scripted testing should be your approach are where time and precision coincide. Applications referring to finances, healthcare, and defense must follow this approach so they do not miss out on any test steps and increase the test coverage to ensure minimal life-threatening bugs.



Here are some of the instances where you would need to use scripted testing:



<ul><li>When there are too many test steps, and you cannot risk skipping/missing any, you need to document the test cases.</li><li>When testers need to run redundant test cases and keep the test document handy</li><li>Instances where high test coverage is necessary with better testing skills because high-level scripts provide testers with a set of actions to cover all these testing requirements</li><li>It is well-suited for a testing approach where proper documentation is required so testers can easily follow through with all the testing requirements</li><li>Scripted testing is the right initial approach for precision-sensitive apps and heavy tools for running test cases and moving toward automation with the intent to eliminate the instances of missed test steps</li><li>This is the right approach when you are automating the test cases to avoid missing out on any steps to check the application functionality</li></ul>



<h2 id="h-exploratory-testing-vs-scripted-testing-vs-automated-testing">Exploratory Testing vs Scripted Testing vs Automated Testing</h2> 



<figure class="wp-block-table"><table><tbody><tr><td>Scripted Testing&nbsp;</td><td>Exploratory Testing&nbsp;</td></tr><tr><td>Suitable to execute when all requirements and documents are available&nbsp;</td><td>You can run this testing even when requirements and documents are unavailable&nbsp;</td></tr><tr><td>Comparatively, more preparation is needed&nbsp; because it can only be done after proper documentation&nbsp;</td><td>Not much preparation is required&nbsp;</td></tr><tr><td>Testers can even do it without complete domain knowledge&nbsp;</td><td>Testers require the right domain knowledge&nbsp;&nbsp;</td></tr><tr><td>New testers can easily perform scripted testing</td><td>Exploratory testing is better done by testers with some experience</td></tr><tr><td>Tests can be traced back to the original document to understand and analyze the test coverage&nbsp;</td><td>Without documents, it is difficult to track the tests back to the original requirement documents to understand the test coverage&nbsp; </td></tr><tr><td>Emphasis on adaptability and learning&nbsp;</td><td>Emphasis is on prediction and decision-making&nbsp;</td></tr><tr><td>Independent of skills of testers&nbsp;</td><td>Dependent on the skills of testers&nbsp;</td></tr><tr><td>Feedback is slow&nbsp;</td><td>Feedback is faster&nbsp;</td></tr><tr><td>It is easier to manage the test coverage&nbsp;</td><td>It is difficult to manage the test coverage&nbsp;</td></tr><tr><td>Can be automated&nbsp;</td><td>It cannot be automated&nbsp;</td></tr><tr><td>Scripted testing workflow &#8211; Steps are: 1. Go through requirements/use cases 2. Prepare the test scripts 3. Run the test scripts and see if it matches the acceptance criteria</td><td>Exploratory testing workflow &#8211; Steps are: 1.Testers explore the application 2. Derive and Execute the test cases per their experience and intuition</td></tr></tbody></table></figure>



When compared to automated testing &#8211; scripted testing is easier to automate as the specifications and requirements are clearly outlined, while exploratory is usually unplanned and is not automated.



<div class="cta-banner-v2">
<div class="title-with-description ">
Here is a guide with in-depth discussions on do&#8217;s and don&#8217;ts of automated testing. 
</div>
<a href="https://testsigma.com/automated-testing" target="_blank" class="cta-btn-v1" rel="noopener">Check out the guide</a>
</div>



<h2 id="h-takeaway">Takeaway</h2>



Scripted testing is straightforward and easy to follow as it depends on documentation and user requirements. Testers follow this type of testing approach as it helps them follow the right sequence of test cases and record the results for a better analysis. Scripted testing differs from the <a href="https://testsigma.com/blog/exploratory-testing/" target="_blank" rel="noreferrer noopener">exploratory testing</a> that QAs use when they have deep technical and domain knowledge about AUT.



We highlighted all the relevant points in this blog about both testing approaches &#8211; advantages, disadvantages, and differences between them. Testsigma is a no-code testing automation that supports almost every testing effort, including test data management, results recording. test scripts in plain English, and proper documentation. 



For more details, check out the <a href="https://testsigma.com/request-demo" target="_blank" rel="noreferrer noopener">demo</a> and see our tool in action for yourself. 



<div class="cta-banner-v2">
<div class="title-with-description ">
Start Automating your test scripts, in minutes
</div>
<a href="https://testsigma.com/" target="_blank" class="cta-btn-v1" rel="noopener">Check out Testsigma</a>
</div>



 <h2 id="h-frequently-asked-questions-faqs">Frequently Asked Questions (FAQs)</h2>



<h3 id="h-what-is-manual-scripted-testing">What is manual scripted testing?</h3>



Manual scripted testing involves humans understanding the application, writing test scripts, and then executing them. It involves no automation. Testers carry out the entire process themselves and note down the results for developers and stakeholders to analyze.



<h3 id="h-what-is-an-example-of-scripted-testing">What is an example of scripted testing?</h3>



An example of scripted testing is a project that uses traditional software development methodologies that consists of detailed documentation along with proper test scripts. If you develop any application using the waterfall model, it is likely to come under a scripted testing approach.

What is Scripted Testing and How Does it Differ from Exploratory Testing?

What is Scripted Testing | How it Differs from Exploratory Testing?

Several testing procedures and techniques find flaws throughout the Software Testing Life Cycle, abbreviated STLC. Defect leakage measures the percentage of problems that leak from one testing stage to the next, demonstrating the efficacy of testing. However, because certain defects, faults, and mistakes are present at the most internal level of the program, even the most well-known and efficient testing processes cannot locate and identify them all.&nbsp;



Leakage is found in the later phases of the software testing life cycle (STLC). Proficient software engineers, therefore, use a method known as defect leakage in software testing to calculate the total number of undetected errors in software systems. This method also helps them validate their testing efforts by allowing them to determine the total number of faults present in a software program.



<figure class="wp-block-image"><img src="https://lh3.googleusercontent.com/MfpG7dtDvbEnIvO5fsn1CvzIGY-PPDviHW_MdWkxxujyB6MmNEk-znIGCjLUPpWb9y9sFkugBvWcT1sboRZeS7M5Ty2_cAqtBwpEYvY9HZNUfNRzK9CqpdBWLgfs2pdBuON3wzVDrok9S54MwqTnVPnTj1TNHAjGhsz7tNY26bmP2xq00Q-litHb_w" alt="Defect Leakage in Software Testing"/></figure>







Defect leakage is the metric that confirms the significance of the QA testing procedure. It considers the number of problems found throughout the ongoing process. In the brief term, it is a type of defect that, when put into use, surpasses all team tests and leads to a product that instantaneously affects users.



With a compound annual growth rate (CAGR) of 6.1%, the global market for leak detection and repairs is anticipated to increase from <a href="https://www.businesswire.com/news/home/20220819005138/en/Leak-Detection-and-Repair-Global-Market-Report-2022---ResearchAndMarkets.com" target="_blank" rel="noreferrer noopener nofollow">$14.63 billion in 2021 to $15.52 billion in 2022</a>. At a CAGR of 7.2%, the leak detection and repair market is predicted to reach $20.5 billion in 2026.



<div id="toc_container" class="no_bullets">Table Of Contents<ul class="toc_list"><li><a href="#A_Quick_Overview_of_Defect_Leakage">1 A Quick Overview of Defect Leakage</a></li><li><a href="#Testing_Error_in_Software">2 Testing Error in Software</a></li><li><a href="#How_to_determine_defect_leakage">3 How to determine defect leakage</a></li><li><a href="#Reasons_for_Defect_Leakage">4 Reasons for Defect Leakage</a></li><li><a href="#Strategies_to_Control_Defect_Leakage">5 Strategies to Control Defect Leakage</a></li><li><a href="#Steps_to_fix_the_defects">6 Steps to fix the defects:</a></li><li><a href="#Validation">7 Validation :</a></li><li><a href="#Conclusion">8 Conclusion:</a></li></ul></div>
<h2 id="h-a-quick-overview-of-defect-leakage">A Quick Overview of Defect Leakage</h2>



Software engineers use a method called &#8220;Defect Leakage&#8221; to determine the total extent of mistakes and flaws that go unnoticed to decide on the overall number of faults in the software application. This further helps them validate their test coverage.&nbsp;



It is the ratio of faults attributable to a step but only discovered in later phases compared to the total of defects found in that step plus all defects discovered attributable to a step but only discovered in the last stages. Additional elements of defect leaking include:



<ul><li>Following the delivery of the application, it happens at the end-user or customer end.</li><li>They are used to calculate the defect leakage rate for subsequent.</li><li>It may be computed at the initial level, the overall project level, or both.</li><li>It is expressed as a percentage.</li></ul>



<h2 id="h-testing-error-in-software">Testing Error in Software</h2>



A software application bug is a variance or diversion from the intended user&#8217;s needs or the initial business needs. A software bug results in inaccurate or unexpected outcomes from a software program that doesn&#8217;t adhere to the specifications as intended. While running the test cases, testers could encounter such flaws.



These two names are similar and are sometimes used indiscriminately by testing teams because both represent defects that need to be rectified in the business.



Testers can encounter test findings contrary to what was anticipated when they run the test cases. A software defect is known as this variation in test findings.



<h2 id="h-how-to-determine-defect-leakage">How to determine defect leakage</h2>



<figure class="wp-block-image"><img src="https://lh5.googleusercontent.com/r1iE1ZkREQVBsEKDIMnfvRv7CoIw9VXOGpEgJT92J-q6uRCkuwZr6E4KuyMA_ZuPQiJNxqLGrZBAI0cG4AKLAACHyfpoTvbCLB1D78_dmK6fCQY0I8XlbBT5I-aMhF0SrkShp4h-w1CCzpOZKESmFNk5fLMhy4bqCRF5BIBSlkJuhJ1PHA2_TL7Dvw" alt="How to determine defect leakage"/></figure>







Defect leakage in software testing is a measurement that assesses the proportion of bugs that pass from one testing stage to the next while also demonstrating the efficacy of software testers&#8217; testing. The value of the test team is shown only, though, when there is little to no fault leaking.



This formula is used to determine the defect leakage rate: #Defect discovered during next phase/(# Defects found during testing + #Defects found during next phase) * 100



For instance, end users found 42 faults at the UAT manufacturing unit, while 140 defects were found during the whole quality process, comprising both the testing facility and the production site. Defect leakage would thus be as follows:



= (42/140) * 100



= 30%



Therefore, 30% is the defect leakage percentage.



Maintain a record of the location of the defect and make repairs before it is released, check the development process, and keep a reasonable defect with an efficient repair.



Along with discovery and repair, software fault disclosure is also crucial. Additionally, for solutions and validation, transparency concerning software flaws is vital.



<h2 id="h-reasons-for-defect-leakage">Reasons for Defect Leakage</h2>



<figure class="wp-block-image"><img src="https://lh6.googleusercontent.com/uO04BbJqF782dHZdb_yNzLMo5vE9kuGyqhviQ95q7LabyCfvNS-KKqPNl4KfG0di2l6W4M48jgMAfCjywuFcIffal8GGhgWMVrOB8Psjv_PNZlnFMaQqqjckgG9AU8-LmlQ7OoY1QvilcRUEYPQd2XMYvc9sqFopww0wE-WQEmppTEU6bZYEuRz5rA" alt="Reasons for Defect Leakage"/></figure>







Since software development involves several different activities, there are many possibilities as to why a defect could go unnoticed despite extensive testing. The causes of defect leaking might range from a minor mistake in the software&#8217;s coding or scripting to a lack of product or industry understanding. Therefore, a few of these causes, which might result in excessive defect leakage, are listed here.



<ol><li>Communication issues: Defects may go undetected and unreported if there is poor or absent communication during the software development process (from requirement collection to interpretation/documentation or stage).</li><li>Human error: Since people make mistakes, it would be absurd to expect the items they create to be perfect and free of flaws. That explains how software flaws and defects might appear. However, notwithstanding the probability of human-caused errors, humans still manage to produce goods that are superior to those made by any non-human entity. Therefore, we must rely on human intelligence and thus run the danger of mistakes unless we find one that can perform the task better than humans.</li><li>Unachievable deployment timelines: Scarce or limited resources and due dates are among the problems that software developers frequently have to deal with. They may have to make some sacrifices as a result (such as not allocating enough time for designing and not validating their code before delivering it to the quality assurance team), which can raise the likelihood of faults and errors.</li><li>Faulty design logic: Finding a dependable solution requires both R&amp;D and some level of conceptualizing as software applications become complex. However, a strong desire to do the project quickly, lousy use of expertise (i.e., products, components, processes), and poor knowledge of technological viability before creating the architecture are all factors that might cause errors or bugs to appear.</li><li>Poor coding: This includes bad coding techniques like unhandled failures, missing deviations, and incorrect input validations, as well as the use of inadequate tools (like poor compilers, debugging tools, and validators that some software developers are using). All of these can introduce bugs in the code that may be difficult to troubleshoot. Sometimes, problems in the code may be the result of poor programming.</li><li>Not using version control: Examine the version monitoring system (if there is one). If the tester experiences frequent regression errors, trace every change made to a collection of code bases using parallel version systems.</li><li>Defects in third-party tools: During software creation, third-party tools like debuggers, HTML builders, shared DLLs, and add-ons/plug-ins (such as shopping cart connectors and map navigator APIs) are frequently required. However, these third-party tools may have defects that get transferred to the product.</li><li>Lack of experienced testing: Subpar testing is frequently the norm in many companies. This could involve a shortage of skilled testers, flaws in the testing procedure, testing treated carelessly, and the method is carried out without consideration. All of these have the potential to lead to software flaws and failures.</li><li>Excessive reliance on automation testing could result in a manual tester missing a bug or fault since automated testing lacks human perception and experience.</li></ol>



<h2 id="h-strategies-to-control-defect-leakage">Strategies to Control Defect Leakage</h2>



Software engineers are engaged in an ongoing conflict that will never be ultimately won. Defects do occur. As a result of deadlines or constraints, software engineers may even intentionally add flaws to their products. However, how can unwanted vulnerabilities that make the application challenging to use and damage reputation be fixed?



As the project&#8217;s relevance rises, more effort should be spent managing production-site issues. Defects may be significantly reduced by using sound test recording, reporting, customer interaction, and product openness. Even the most significant log in the world is partly useless if the flaws are not corrected.



Program developers and testers must employ several approaches to avoid defect leakage, guarantee that it is managed and does not remain in the software, and certify the quality of the finished output. This reduces their overall engineering and testing resources and enables them to prevent any significant problems during the software development cycle. So, the following are some methods to stop excessive defect leakage in software testing:



<ul><li>Pick a locus, then do extensive testing and analysis.</li><li>Create a simple, concise report that may be utilized in interactions with and among the business and corporate leadership to assess the general health of a quest application quickly.</li><li>Automatically record production-related flaws. This method might get complicated very fast, so have a separate area to document faults and add pertinent concerns.</li><li>Set up a small SWAT squad or fast reaction team that can respond rapidly to crises if the group is large enough or the project is vital enough.</li><li>Additionally, as a general rule, each developer should be attentive to the state of their product, actively involved, and accountable for their code.</li><li>Look for components susceptible to significant defect leakage and critical content and locations.</li><li>Test the product thoroughly on the minor components before using a real-world simulation.</li><li>If issues are terrible, think about rewriting them and look more closely at the entire system.</li></ul>



A suitable fault extraction efficiency and maintaining track of problems discovered and fixed before release are indicators of healthy software development. Keeping track of any issues found after deployment and reporting them to the product, engineering, and quality teams are vital so that test cases can be upgraded and procedures may be changed as needed. Since most consumers want to understand taking responsibility for the issues and striving to find solutions, visibility concerning software errors is just as crucial as discovery and correction.



<h2 id="h-steps-to-fix-the-defects">Steps to fix the defects:</h2>



Software engineers and QA testers can resolve the issues by following the instructions below.



<ul><li>Assign to someone: The task is delegated to a developer or specialist, and the status is changed to responding.</li><li>Setting the schedule: This step is handled by the development side. They will design a timeline to resolve these issues depending on the fault priority.</li><li>Repair the bug: While the project team resolves the flaws, the Testing Team monitors the procedure and compares it to the timetable.</li><li>Submit the solution: When bugs are fixed, request a resolution report from the developers.</li></ul>



<h2 id="h-validation">Validation :</h2>



The testing team confirms that the flaws are rectified after the design team fixes and documents the problem.



For instance, in the situation above, once the development team reports they have addressed 71 flaws, the team needs to retest to see whether these bugs have been resolved.&nbsp;



A defect is converted to closed status after it has been fixed and validated. If not, then the team notify devs to recheck the fault and consider the following:



<ul><li>Appropriately calculate the defect percentage.</li><li>Calculate the overall project and phase levels.</li><li>Openness for the product.</li><li>Reliable test logging.</li><li>Include engagement from the client.</li></ul>



<div class="cta-banner-v2">
<div class="title-with-description ">
Reduce your defect leakage by automating your end-to-end UI tests for web, mobile, desktop and APIs, from the same place, 5x faster with Testsigma.
</div>
<a href="https://testsigma.com/signup" target="_blank" class="cta-btn-v1" rel="noopener">Try for free</a>
</div>



<h2 id="h-conclusion">Conclusion:</h2>



Although finding bugs and defects is essential for software&#8217;s correct and efficient development, doing so at a crucial time or in large quantities can have fatal results. Software testers and the Quality Assurance (QA) team are responsible for swiftly detecting any flaws, errors, bugs, and other problems in a system. Doing so will allow them to produce successful software or applications with high standards for quality, performance, functionality, and other aspects. Defect leakage testing is straightforward, thanks to Testsigma&#8217;s intuitive interface.



Since everything is already configured, the initial setup requires little time or effort. You can do defect leakage testing quickly and maintain automated tests quickly with Testsigma. The best method for evaluating test coverage is defect leakage. They may also calculate the percentage of flaws that leak to a later stage and obtain the total number of concealed and unrecoverable faults with the help of the matrix defect leakage. Furthermore, defect leakage is significant since software testing is more effective when defect leaking is minimal.

What is Defect Leakage in Software Testing?

What is Entry and Exit Criteria in Software Testing Life Cycle?

Unit Testing vs End-To-End Testing - Key Differences cover

Unit Testing vs End-To-End Testing – Key Differences

Everything you need to know about Simulator vs. Emulator vs. Real Device - Mobile Testing cover

Simulator vs Emulator: 6 Top Key Differences

Unit Testing Vs Integration Testing - Important Differences cover

Unit Testing Vs Integration Testing – Important Differences

30 Tricky QA Interview Questions and Answers in 2022

30 Tricky QA Interview Questions and Answers

Uncaught TypeError: Cannot Read Property of Undefined in JavaScript cover

Uncaught TypeError: Cannot Read Property of Undefined in JavaScript

George Ukkuru is a seasoned technocrat and AVP of quality engineering, DevOps, and SRE @Marlabs Inc. Over the course of two decades, he has helped Fortune 500 companies implement Agile testing practices. He has also authored a number of books on quality engineering and test automation. 



In this QnA, Ukkuru lays out the scope and depth of his experience without even trying. He makes the points that non-functional testing should be higher up in your priority, that manual test data provisioning keeps you from truly reaping the rewards of automation, and that you must never miss an opportunity to celebrate good work. 



<div id="toc_container" class="no_bullets">Table Of Contents<ul class="toc_list"><li><a href="#Q1_What_changes_have_you_seen_in_SDLC_and_QAs_role_in_it_over_the_course_of_two_decades">1 Q1: What changes have you seen in SDLC and QA’s role in it over the course of two decades?</a></li><li><a href="#Q2_Whats_your_battle-tested_process_for_finding_and_resolving_bugs_in_Productionnbsp">2 Q2: What’s your battle-tested process for finding and resolving bugs in Production?&nbsp;</a></li><li><a href="#Q3_What_are_some_testing_anti-patterns_you_wish_never_existed">3 Q3: What are some testing anti-patterns you wish never existed?</a></li><li><a href="#Q4_If_you_had_to_restart_your_career_today_what_key_lessons_would_you_take_from_the_past">4 Q4: If you had to restart your career today, what key lessons would you take from the past?</a></li><li><a href="#Q5_To_aspiring_leaders_what_is_your_advice_on_how_to_be_a_good_manager">5 Q5: To aspiring leaders, what is your advice on how to be a good manager?</a></li></ul></div>
<h3 id="q1-what-changes-have-you-seen-in-sdlc-and-qa-s-role-in-it-over-the-course-of-two-decades">Q1: What changes have you seen in SDLC and QA’s role in it over the course of two decades?</h3>



In the last two decades, I have seen:



1. The emergence and dismantlement of the TCOE model, aka Independent Verification and Validation. It started in the early 2000s. Today, TCOEs have been converted to a hybrid model as teams adopt Agile &amp; DevOps. 2. Automation used to be a nice-to-have skill. When I started my career, automation was used for automating UI-based regression testing. Today, automation is a must-have skill, and the focus has moved from regression testing to complete test lifecycle automation.



The type of applications that are being tested has changed as well, from (now) legacy client server-based applications to microservice-based or cloud-based architectures. This changes how teams test for quality. 



The focus has shifted to non-functional testing, including running security tests, API &amp; workflow-based performance testing, Chaos Engineering, compatibility testing, etc. As technology advancement continues, we’ll see newer, more nuanced types of testing.



<h3 id="q2-what-s-your-battle-tested-process-for-finding-and-resolving-bugs-in-production">Q2: What’s your battle-tested process for finding and resolving bugs in Production?&nbsp;</h3>



Once a bug&#8217;s been found on production, I have several practices to fast-track its resolution:&nbsp;



1. Continuously review production tickets and identify defect trends, in collaboration with the Operations Team.2. Use an algorithm that identifies the best developers for determining the root cause and fixing the defect.3. Organize regression packs based on the type of fixes going into production and define when to use them.4. Monitor social media feedback, application logs, Mobil App Store feedback to identify the issues faced by the end users and take proactive actions to identify patterns.



<h3 id="q3-what-are-some-testing-anti-patterns-you-wish-never-existed">Q3: What are some testing anti-patterns you wish never existed?</h3>



I see several anti-patterns in software testing. But the ones that peeve me the most are:



1. Heavy focus on UI Automation. The effort and cost to maintain UI automation is disproportionately higher than the rewards, I think. UI changes frequently as the products evolve. Teams need to strike a fine balance between UI and API-based tests. API Tests are faster to design, execute and maintain.



2. Manual test data provisioning. The test data is ported to test environments after manually masking data from obfuscation. That is slow. You can&#8217;t truly automate for DevOps using this approach. Instead, teams should use synthetic data provisioning and self-service mechanisms to accelerate and automate data provisioning.



3. Late Identification of Non-Functional Defects. This is usually a result of a lack of clarity around non-functional testing requirements. Performance or security tests are seen as a part of &#8216;hardening&#8217; or release-level sprints. Unfortunately, performance and security bugs often need architectural changes to fix, and keeping non-functional testing for the end of the cycle can cause schedule and cost overruns.



I advise teams to look at behavior-driven testing techniques to document security and performance requirements. Engineers should also integrate and execute API-based performance tests and SAST/DAST scans to the DevOps pipeline.



<h3 id="q4-if-you-had-to-restart-your-career-today-what-key-lessons-would-you-take-from-the-past">Q4: If you had to restart your career today, what key lessons would you take from the past?</h3>



Master at least one programming language, preferably Java, Python, or C#, so that you can design and create scripted tests.



Focus on taking up courses around test automation, either with open source or commercial tools.&nbsp;Or both.



Spend time learning about practices and concepts in software testing. ISTQB Foundation syllabus should be a good starting point.&nbsp;



Learn about Cloud, Agile, and DevOps principles and practices. Learn the basics of tools like Jira, Azure DevOps, Jenkins, etc.



Your communication skills matter more than you think.&nbsp;Work towards improving them. 



<h3 id="q5-to-aspiring-leaders-what-is-your-advice-on-how-to-be-a-good-manager">Q5: To aspiring leaders, what is your advice on how to be a good manager?</h3>



Take up formal courses on Agile or Project Management. Refresh your skills regularly to stay relevant.



This is my style, but I advise new managers to get actively involved in the project. Remember that you are not a people manager. Understand what the project objectives are and how it is going to impact a business or end-user. Work from there.



Understand the technologies involved so you can grasp the nuances of the project. This will help you make decisions and manage risks.



Learn the art of remote management. Here are some practices that work for me:-



<ul class="list_style_disc"><li>Have frequent meetings with your direct reports, preferably over video.</li><li>Do NOT micro-manage and follow-up every hour. Trust your team. Move away from a task-based and adopt a Goal-based approach while assigning work.</li><li>Spend time with your team to understand their strengths, passions, and weaknesses. Assign work based on their strengths and provide training and mentoring to help employees overcome their weaknesses.</li><li>Keep your team in the loop about the happenings in your department and the larger organization. This will help take care of rumors and avoid perceptions.</li><li>Provide feedback on the work assigned without delays. Don&#8217;t be a bottleneck.</li><li>Never miss an opportunity to appreciate and celebrate good work.</li></ul>



For more experience-led insights from George Ukkuru, check his book on software testing estimation on Kindle.

Quality Engineering Discussions 5 Questions with George Ukkuru

Quality Engineering Discussions: 5 Questions with George Ukkuru

Rahul Parwal is a software engineer, speaker, mentor, and writer out of Jaipur, Rajasthan. He has dabbled in software development, testing, and automation, and often shares his learnings in <a href="https://testingtitbits.blogspot.com/" target="_blank" rel="noreferrer noopener nofollow">his blog</a>.



In this QnA, Rahul makes the point that a randomly failing test is always worth investigating and that assumptions are dangerous in testing.



<div id="toc_container" class="no_bullets">Table Of Contents<ul class="toc_list"><li><a href="#Q1_What_are_your_most_and_least_favorite_things_about_test_automationnbsp">1 Q1: What are your most and least favorite things about test automation?&nbsp;</a></li><li><a href="#Q2_It_sounds_great_on_paper_but_what_would_it_really_take_for_a_mid-sized_org_to_incorporate_continuous_testing_in_their_release_cyclenbspnbsp">2 Q2: It sounds great on paper, but what would it really take for a mid-sized org to incorporate continuous testing in their release cycle?&nbsp;&nbsp;</a></li><li><a href="#Q3_What_are_some_Severity_1_bugs_that_ALMOST_slipped_past_you_and_how_did_you_make_sure_they_never_did_so_again">3 Q3: What are some Severity 1 bugs that ALMOST slipped past you — and how did you make sure they never did so again?</a></li><li><a href="#Q4_How_do_you_manage_failed_tests_and_tests_that_fail_randomly">4 Q4: How do you manage failed tests and tests that fail randomly?</a></li><li><a href="#Q5_Whats_your_most_memorable_deployment_andor_release_day_Good_OR_bad_just_as_long_as_no_one_dies_at_the_end8230">5 Q5: What’s your most memorable deployment and/or release day? (Good OR bad, just as long as no one dies at the end&#8230;)</a></li><li><a href="#Bonus_If_you_could_give_just_ONE_piece_of_advice_to_fledgling_software_testers_what_would_it_be">6 Bonus: If you could give just ONE piece of advice to fledgling software testers, what would it be?</a></li></ul></div>
<h3 id="q1-what-are-your-most-and-least-favorite-things-about-test-automation">Q1: What are your most and least favorite things about test automation?&nbsp;</h3>



One of the things I like about test automation is that it can be scaled over multiple platforms, devices, interfaces, environments, etc. quickly and reliably. Test automation, if planned and executed correctly, can be a great service to testing and QA.



There is, however, The Silver Bullet Syndrome, where everyone wants to ascribe the responsibility of succeeding with test automation success to a tool. “Let’s find the one tool to solve all of our problems.” It doesn&#8217;t work.



<figure class="wp-block-image is-resized"><img src="https://lh4.googleusercontent.com/ghN79ATI0DLYh5CNL3-LxlBUzyTg_fCE011vqAikrZkvyJqUZWPufXB3-U_BQNUtUCnw_qjdmjD0g4OSQGM_kurFoNBWGnPFVwH-dpYhyrWL36RWBwbVm4P-ILV8z8KCIp6Q_--H" alt="Definition" width="600" /></figure>



The concept of automation extends well beyond a tool. Teams attempting test automation should consider a tool’s capabilities and limitations. But first, they should establish realistic expectations, sort out people constraints, and have the support of management. Without all three, adopting test automation will just be an uphill battle.



<h3 id="q2-it-sounds-great-on-paper-but-what-would-it-really-take-for-a-mid-sized-org-to-incorporate-continuous-testing-in-their-release-cycle">Q2: It sounds great on paper, but what would it really take for a mid-sized org to incorporate continuous testing in their release cycle?&nbsp;&nbsp;</h3>



The best way to start is by evaluating and understanding your context, team, and environment.



&#8220;No matter how they phrase it, it&#8217;s always a people problem,&#8221; as Sherbie&#8217;s Law says.&nbsp;CI/CD and consequently, continuous testing, needs a shift in the team&#8217;s mindset. If you push a whole bunch of processes and tools on people without getting them on board, you are setting them all up for failure.&nbsp;



In practice, my advice is to start with small experiments and do one thing at a time. Don&#8217;t expect overnight results, and <ul class="list_style_disc"><li>Make it a team sport. Establish channels of collaboration. Hold knowledge-sharing sessions. Try Pair and mob testing to reduce knowledge silos within the team.</li><li>Plan before you execute. At each stage of the product life cycle, plan what and how you&#8217;ll test.</li></ul> 





<div class="wp-block-image"><figure class="aligncenter is-resized"><img src="https://lh6.googleusercontent.com/k81_BbjtH20lB1vpqnVsN9Sij_GDLcaZa6KtTE9P6hAF17sur2tq9Xj81j2CmxqWgPDEiMy3hrjeHj6x0ftLAlMia_XmvetYDw_WDirOJ3O5WbQPBHdPgkzVj4R9MG9rsfFRSw-M" alt="Plan before you execute" width="600" /></figure></div>



<h3 id="q3-what-are-some-severity-1-bugs-that-almost-slipped-past-you-and-how-did-you-make-sure-they-never-did-so-again">Q3: What are some Severity 1 bugs that ALMOST slipped past you — and how did you make sure they never did so again?</h3>



I have had two such incidents. I’ll share both, along with the lessons I learned from them:



<ul class="list_style_disc"><li>Software loading was failing if a specific application is running in parallel. Lesson: Test your software in real user conditions. Remember to test how your app works with shared resources such as memory, space, network resources, etc.</li> <li>The application gave a timeout if the form submission exceeded 15 minutes. Lesson: Actual users are not as fast as an automation bot/script. Users will take will never perform a form submission as quickly as a script, so use waits judiciously.</li></ul>



<h3 id="q4-how-do-you-manage-failed-tests-and-tests-that-fail-randomly">Q4: How do you manage failed tests and tests that fail randomly?</h3>



A failing test establishes my confidence in a test I’ve designed. The amazing Angie Jones once tweeted something which sums up my feelings on failed tests.



<figure class="wp-block-image is-resized"><img src="https://lh5.googleusercontent.com/0SG95qwUYRPHWIFFupruMFOcQE4y1wgMeyTfDrUNOwAO7sHAERCa3PC7e_SEGVzhCbnRKyOxrHyizTYGGGv3cd5OpLg8LYL0E3yTlkVrTb5mQuJLLrXEWSrwhfRaC0ckYHeCUAy8" alt="How do you manage failed tests and tests that fail randomly" width="600" /></figure>



Randomly failing tests are interesting. They give me a reason to go sleuthing, to find and uncover variables that might be affecting my product and its functionality. My bug analysis and exploration skills have greatly improved as a result of investigating such bugs. Whenever I see a randomly failing test, I triangulate failure conditions by varying:



<ul class="list_style_disc"><li>Data</li><li>Behavior</li><li>Options &amp; Settings</li><li>Software &amp; Hardware Environment</li><li>Configuration &amp; Dependencies, etc.</li></ul>



A randomly failing test is usually a symptom of a much larger problem. Sometimes, developers refer to such cases as corner cases, but I&#8217;ve learned to never ignore a random failure without investigating it. It might just be the tip of the iceberg of a whole load of flaky tests.



<h3 id="q5-what-s-your-most-memorable-deployment-and-or-release-day-good-or-bad-just-as-long-as-no-one-dies-at-the-end">Q5: What’s your most memorable deployment and/or release day? (Good OR bad, just as long as no one dies at the end&#8230;)</h3>



In my first project as a software tester, I was testing for a product release of a large enterprise financial application. The stakes were very high since this product was developed to sunset a legacy system that had been in place for decades.



During testing, we were going through all the flows on a mocked simulated data set that was providing data as per our testing layer. After months of rigorous testing, on the release day, we started getting errors from the monitoring system.&nbsp;



There were gaps in the mocked simulated data and the actual production data. We hadn’t questioned the authenticity of the test data during the testing cycle. We ended up with a release rollback.



Some lessons that I learned that day:



<ul class="list_style_disc"><li>Never assume anything &#8211; What if the data is wrong?</li><li>Learn how to create your own testing data. This way, you understand the sources, flows, and formats of the data.</li><li>If you use mock/simulated data for testing, be sure to run a significant number of tests using real data as well.</li></ul>



<h3 id="bonus-if-you-could-give-just-one-piece-of-advice-to-fledgling-software-testers-what-would-it-be">Bonus: If you could give just ONE piece of advice to fledgling software testers, what would it be?</h3>



Like Paul Muad’Dib of Dune, “Learn how to learn.” Testing is a continuous search for information: Both about your product and the tests that you run it through. None of us are born with knowledge. Trust that you can learn new ways to test. Be a continuous learner.

Quality Engineering Discussions: 5 Questions with Rahul Parwal