Insights from a Software Test Engineer: Sanju Kumbar's Journey in Testing and Java Programming

The mock interview begins with the interviewer welcoming Sanju and explaining that the session will be recorded for YouTube. Sanju is reassured that it's okay to skip questions if he doesn't know the answers.

Sanju Kumbar introduces himself as being from Karnataka. He graduated in 2014 from Government Engineering College in Hari and completed his postgraduation at AR Institute of Technology in Bangalore. He has three years of experience as a software test engineer.

Sanju describes his testing process, which follows the Agile methodology. He participates in Sprint meetings with the Scrum Master, developers, and clients to understand Sprint planning. User stories are assigned by the team lead, and Sanju prepares test scenarios and test cases, which are reviewed with the team lead before testing begins.

After executing test cases, Sanju logs any defects found in JIRA. If developers fix the bugs, he conducts regression testing. If the bugs are not fixed, he reopens them. Defects identified during Sprint meetings are tracked for the upcoming Sprint.

Sanju emphasizes that the main purpose of software testing is to ensure the quality of the software before release. He explains that releasing software with numerous bugs can lead to customer dissatisfaction, hence thorough testing is essential to deliver a quality product.

Sanju explains that he writes test cases in Excel, starting with test scenarios followed by detailed test steps. He highlights the importance of validating bugs and ensuring comprehensive coverage in the test cases.

When asked about the prerequisites for writing test cases, Sanju mentions that user stories are crucial. He states that understanding user stories, which contain all application details, is essential for developing effective test scenarios and cases.

The discussion begins with a focus on ensuring that all test cases cover the necessary requirements and functionalities outlined in user stories. The speaker mentions the use of Requirement Clarification Notes (RCM) to identify any missing elements in the application, emphasizing the importance of thorough documentation and review during the test case preparation phase.

The conversation shifts to the Traceability Matrix, which serves as a mapping tool to ensure that all test scenarios are accounted for in the test cases. This matrix provides clarity on whether all requirements are covered, reinforcing the need for meticulous tracking of test cases against user stories.

Before executing test cases, the speaker outlines the necessary steps, including waiting for a build release from developers. They clarify that execution does not commence immediately upon test case creation; instead, it follows a structured process that includes team reviews and approvals to ensure readiness.

The importance of review and approval processes is highlighted, with the speaker detailing that test cases undergo peer reviews and manager approvals before execution. This multi-tiered review process ensures that all test cases are validated and meet the required standards.

Upon discovering a bug during test execution, the speaker explains the protocol for reporting it. They mention updating the bug status in the tracking tool (Jira) and assigning it to the relevant developer or team lead. The speaker emphasizes the need to verify the bug multiple times before reporting, ensuring accuracy in the defect identification process.

The speaker emphasizes the importance of thoroughly checking various aspects before reporting a bug, including environmental factors and browser compatibility. They recommend checking the issue at least three times across different platforms and machines to ensure reproducibility. Once confirmed, it's crucial to consolidate all relevant information, such as log files and screenshots, before reporting the bug to the developer.

After reporting a bug, if the developer does not accept it as a bug, the speaker suggests that the developer will investigate the issue further. If the developer claims it is not reproducible in their environment, a conflict arises, especially if the tester believes it is a defect. The speaker highlights the need for clarification and communication among team members to resolve such conflicts.

In situations of conflict regarding bug acceptance, the speaker advises contacting team leads, scrum masters, and product owners. They stress the importance of discussing the issue with the product owner, who has a comprehensive understanding of the application's functionality and can provide a definitive judgment on whether it constitutes a bug.

The speaker explains the concepts of priority and severity in bug tracking. Priority refers to the urgency of addressing a bug based on its impact on business services, while severity relates to the seriousness of the defect and how soon it needs to be resolved. They clarify that priority is about timing, whereas severity concerns the functionality and importance of the feature to the customer.

In a scenario involving a logo with a color discrepancy or a spelling mistake, the speaker discusses how to assign priority and severity. They suggest that such a bug would receive medium priority since it does not critically affect functionality, but it still needs to be addressed. The speaker prompts further discussion on how to evaluate the severity of this particular issue.

The discussion revolves around the classification of issues based on severity and priority. The speaker argues that a logo issue, despite being visible on the homepage, should be classified as low severity because it does not block other functionalities. However, the importance of the logo from a customer perspective raises its priority, suggesting that it should be addressed promptly. The speaker emphasizes that while the logo's color and spelling mistakes are significant, they do not impede the overall testing process.

A scenario is presented where an application crashes on a specific page under rare conditions. The speaker contemplates the severity and priority of this issue, initially suggesting it could be low priority since it does not affect other functionalities. However, they acknowledge that if the crash occurs in a customer environment, it could have a significant impact, thus warranting high severity. The distinction is made that while the crash is severe, it may not need immediate attention if other functionalities remain unaffected.

The conversation shifts to the defect resolution process, where the speaker explains that upon reporting a defect, developers may accept or reject it based on their assessment. They may categorize the defect as a bug, enhancement, or even a duplicate. The speaker highlights that the developer's feedback can vary, and they may schedule the fix for a future release or decide not to address it at all. This reflects the complexities involved in defect management and the varying perspectives between testers and developers.

The discussion begins with the developer explaining the concept of resolution types, which are categorized into epic, story, and task. An epic is defined as a collection of user stories, representing a larger requirement that cannot be tested all at once, necessitating its division into smaller user stories.

The developer clarifies the differences between an epic, a story, and a task. An epic encompasses multiple user stories, while a story focuses on a single user requirement. Tasks are the specific actions or activities derived from a user story, which can include low-level requirements and customer needs.

As a QA tester, upon receiving a user story, one must take ownership and analyze the requirements thoroughly. The tasks involved in testing include writing and reviewing test cases, executing them on the build, and automating those test cases. These tasks are created during Sprint planning meetings, where estimations regarding the time required for completion are also provided.

The conversation shifts to Sprint meetings, specifically the Sprint review meeting, which occurs after the completion of a Sprint. During this meeting, the team discusses the Sprint backlogs, evaluates the number of bugs fixed, and reviews the scenarios addressed in the previous Sprint to plan for the upcoming one.

The developer introduces the concept of story points, which serve as a rough estimation of the effort required for Sprint planning. This estimation helps in assessing the workload and complexity of the tasks involved in the Sprint.

The discussion begins with an explanation of the Scrum board, which is essential for tracking project progress. It is emphasized that every story in Scrum is estimated in hours and represented in story points. The Scrum board serves as a dashboard where developers, testers, Scrum Masters, and project owners can visualize the status of various tasks, including epics and stories planned for the sprint.

The Scrum board allows teams to track the status of stories through various stages: planned, to-do, in progress, developed, tested, and completed. Each story has specific tasks assigned to both developers and testers, and until all tasks are completed, the story cannot be marked as completed. This tracking ensures that everyone is aware of the current status of each story.

Transitioning to programming, the speaker asks for a self-assessment rating on Java programming skills. The individual rates themselves at 6.5 out of 10, indicating a moderate level of confidence in their Java abilities.

The conversation shifts to comparing strings in Java. The speaker explains that to compare two strings, one can use the 'equals' method, which checks for equality while considering case sensitivity. If case insensitivity is required, the 'equalsIgnoreCase' method can be utilized. This highlights the importance of understanding string methods in Java.

The discussion includes the concept of method overloading in Java, where the same method name can be used with different parameters. The individual confirms their understanding of this concept and acknowledges that it is possible to overload the main method in Java.

The conversation briefly touches on method overriding, which involves redefining a method in a subclass that already exists in its superclass. This concept is crucial for understanding polymorphism in Java.

The discussion begins with a clarification of method overloading and overriding in programming. Overloading occurs when multiple methods share the same name but differ in parameters or data types, allowing for different implementations, such as adding two or three numbers. In contrast, overriding involves redefining a method in a child class that already exists in a parent class, maintaining the same method signature but altering its implementation. Overloading can occur within a single class or across multiple classes, while overriding is strictly tied to inheritance, requiring at least one parent and one child class.

The conversation shifts to the 'final' keyword in Java, which serves a security purpose. When a variable is declared as final, its value becomes constant and cannot be changed, regardless of the method context. If a method is marked as final, it cannot be overridden in any child class, ensuring that its implementation remains intact. Similarly, a final class cannot be inherited, preventing any subclassing. This use of the final keyword is emphasized as a means to maintain control over variable values, method behaviors, and class structures.

The discussion begins with the explanation of the 'final' keyword in programming, indicating that a class marked as final cannot be extended or inherited by another class, thus ensuring its immutability.

The speaker prompts the participant to write a simple program to reverse a string, specifically using 'welcome' as the example string. The participant is encouraged to use any text editor or IDE to write the code.

The participant explains their approach to reversing the string using a for loop. They describe starting from the first character and iterating through the string's length, storing characters in a variable to build the reversed string. The speaker emphasizes the importance of using a semicolon in the for loop syntax.

The participant mentions an alternative method for reversing a string using the StringBuffer class, which has a built-in reverse method, simplifying the process of string reversal.

The speaker challenges the participant to write a program that calculates the sum of an array containing five elements. The participant is encouraged to choose any five numbers, and the speaker offers guidance on the logic needed to sum the array elements, suggesting the use of a loop to iterate through the values.

The speaker explains a high-level logic for reading individual values from an array. They describe the process of extracting values using an index in a loop, adding each value to a temporary variable, and repeating this until all values are processed. The final result is stored in a variable, which contains the total sum of the values.

The discussion shifts to Java collections, where the speaker is asked to name different types. They mention three primary types: List, Set, and Queue, highlighting that collections are used to store multiple values in a single entity. The speaker emphasizes that collections can hold both primitive types (like integers and strings) and objects (like instances of employee or animal classes).

The speaker elaborates on the differences between List and Set collections. They clarify that Lists allow for both insertion and deletion, and can contain duplicate values, while Sets do not allow duplicates and do not maintain insertion order. The speaker also explains that in Lists, elements can be accessed by their index using the 'get' method, whereas Sets do not support this method due to the lack of index maintenance.

When discussing how to extract specific elements from collections, the speaker notes that in a List, one can retrieve an element by its index using the 'get' method. However, in a Set, this is not possible as Sets do not have a 'get' method, reflecting the unordered nature of Set collections. The speaker reiterates that Lists maintain the order of insertion, allowing for indexed access.

The speaker explains the difference between list and set collections in programming. While lists maintain the order of elements and allow for index-based access, sets do not preserve insertion order and lack an index concept. To extract a specific element from a set, one must convert it back into a list.

The discussion shifts to automation scripts, specifically focusing on Selenium locators. The speaker lists various types of locators used in their project, including ID, class ID, name, class name, link text, partial link text, tag name, XPath, and CSS selectors. They clarify the difference between link text and partial link text, noting that link text requires the full string of the element, while partial link text allows for a substring.

The speaker elaborates on the two types of XPath: absolute and relative. Absolute XPath starts from the root node and traverses through every node to reach the target element, making it lengthy and prone to breakage if the structure changes. In contrast, relative XPath begins from a specified node and directly targets the desired element based on attributes, making it more stable and efficient for dynamic web applications.

The speaker expresses a clear preference for using relative XPath over absolute XPath due to its resilience against changes in the web application's structure. They explain that since absolute XPath is lengthy and dependent on every tag, any modification by developers can lead to instability. Relative XPath, however, can adapt to changes without being affected, making it the preferred choice in most scenarios.

The discussion begins with the explanation of a button's ID in HTML, initially set to 'start'. Upon clicking, the button's ID changes to 'stop'. This dynamic change in the button's attribute is crucial for the functionality being discussed.

The speaker emphasizes the need to write a single XPath that can match the button element regardless of its changing ID. The challenge lies in creating an XPath that can handle both 'start' and 'stop' states effectively.

The conversation shifts to the use of the 'contains' method in XPath. The speaker suggests that by using the first two characters 'St', the XPath can match both 'start' and 'stop', thus allowing for a more flexible identification of the button.

The speaker inquires about alternative methods to identify the button without using 'contains' or 'starts-with'. The discussion reveals that multiple attributes can be specified in XPath using the 'or' operator, allowing for a match with either 'start' or 'stop'.

The session concludes with a summary of how to write a dynamic XPath that accommodates changing attributes, highlighting the importance of flexibility in automation scripts.

The speaker transitions to discussing weight statements in Selenium, specifically the differences between implicit and explicit weights. Implicit weights apply to all test cases from the moment the driver is created until it is closed, while explicit weights are used for specific elements.

The discussion begins with the distinction between implicit and explicit weights. Implicit weight is available for all statements, while explicit weight is specific to individual elements, determined by certain conditions.

To capture text from a web element, the 'get text' method is utilized. By calling 'web element.get text', one can retrieve the text value of the element, which can then be compared to an expected value for validation.

To retrieve attribute values from a web element, the 'get attribute' method is employed. For instance, to get the value of an ID or name attribute, one would use 'web element.get attribute('ID')' or 'web element.get attribute('name')'.

To check if an element, such as a logo, is displayed on a webpage, the 'is displayed' method is used. This method returns true if the element is present and false if it is not.

Handling dropdowns involves using the 'select' class. To select a country from a dropdown containing multiple options, one must first pass the dropdown as a web element into the 'select' class. Methods like 'get options', 'get visible text', and 'get index' can then be used to interact with the dropdown options.

Assertions are crucial for validating elements in test cases. They allow for comparisons between expected and actual values, ensuring that the elements behave as intended. There are two main types of assertions, which serve the purpose of verifying the correctness of elements.

The discussion begins with a clarification of hard and soft assertions. Hard assertions throw an exception immediately if an expected element is not found, halting further execution. In contrast, soft assertions allow the test to continue even if an expected element is missing, thus not throwing an exception. This distinction is crucial for understanding how assertions function in testing frameworks.

The speaker elaborates on their role in a testing framework, which includes writing and executing test scripts, as well as comparing expected and actual results. They mention using the Page Object Model combined with a data-driven framework, indicating a structured approach to test automation.

In terms of reporting, the speaker states that they generated Extent Reports, which are HTML-based, providing a visual representation of test results. This suggests a focus on clear and accessible reporting in their testing process.

When asked about reusable components, the speaker admits to a lack of knowledge but understands that reusable methods are essential for efficiency. They emphasize that the main purpose of creating a framework is to enhance reusability and maintainability, allowing for better organization of various files such as page object classes, utility scripts, and reports.

The speaker explains that the framework's design focuses on reusability and maintainability. By creating page object classes, they can manage page-related elements in one location, which can then be reused across multiple test cases. This approach minimizes redundancy and simplifies the identification of elements.

The speaker acknowledges facing challenges while writing automation scripts, particularly encountering exceptions during execution. They indicate that these issues can disrupt the testing process, highlighting the complexities involved in automation.

The interviewer provided feedback on the candidate's performance, noting that while the candidate answered questions related to manual testing well, there was a need for improvement in Java and automation skills. With over three years of experience, the candidate is expected to demonstrate a deeper understanding and ability to write original logic rather than relying on memorized code. The interviewer emphasized the importance of preparing for a variety of programming problems, not just the commonly asked ones, to enhance problem-solving skills.

The interviewer advised the candidate to prepare thoroughly for practical questions, especially in Selenium, highlighting the importance of understanding frameworks, writing automation scripts, and utilizing TestNG for parallel testing. The candidate was encouraged to learn about maintaining page object classes and to enhance their overall knowledge in automation testing, as their experience level positions them as a senior engineer.

The interviewer concluded the session by thanking the candidate for attending the interview and mentioned that the interview feedback would be uploaded soon. They expressed the possibility of conducting another mock interview in the near future, encouraging the candidate to prepare further.