QA Methodology Real Test

Question 1

What distinguishes Quality Assurace from Testing

Answer 1

QA and Testing are two different aspects of the software development process. Testing is product oriented, focusing on identifying defects in a specific product or system. QA on the other hand it is about imporving the testing and development processes to prevent defects from occuring in the first place. QA is a broader concept than testing

Question 2

Can you explain the Front End and Back End of application

Answer 2

The Front End is the interface that user interact with. It is visually oriented, and hence also referred to as the Graphical User Interface (GUI). The back end involves the server where information is processed and the database where data is stored. Its the part of the system that users dont see.

Question 3

Whats is SDLC

Answer 3

Software Development Life Cycle, refers to the complete process involved in the development of a system, from start to finish. It includes 6 stages
Requirment Gathering
System Design
Development
Testing
Deployment
Maintenance

Question 4

What are the Requirment documentation in Waterfall and Agile

Answer 4

In the Waterdall model requirement documentation typically include thr Business Requirement Document (BRD) which is high level functional document, Functional Requirement Document (FRD), a low level functional document, and the System Requirements Specification (SRS) a technical document

Question 5

What are the different flows in a Use Case

Answer 5

3 different flows
1) Basic Flow this is happy path where everything goes as expected.
2) Alternative Flow this is another valid path to achieve the same goal when the conditions are no the same as basic flow.
3) Exceptional flow this flow occurs when something goes wrong.

Question 6

Positive Testing

Answer 6

It is where functionality behaves as expected with valid data also called happy path testing. For ex: login with correct email and password

Example sentence: login with correct email and password

Question 7

Negative Testing

Answer 7

It is where functionality behaves as expected with invalid data by throwing warning/error message. For ex: login functionality with invalid User ID and Password

Example sentence: login functionality with invalid User ID and Password

Question 8

Functional Testing

Answer 8

Testing the purpose of the functionality. What it is supposed to do. If compose button opens a popup window with To, Subject, Body. Then clicking compose opens popup window or not is called a functional testing.

Question 9

Non-Functional Testing

Answer 9

Nonfunctional testing is testing technical part of the functionality. Answers question on how does it do that functionality. For example: If compose button opens a pop-up window, then how long does it take to open that window is non-functional testing. Or How many people can open compose window at the same time.

Question 10

Smoke Testing

Answer 10

Is high level testing that ensures most important functions work. The result of this testing is used to decide if a build is stable enough to proceed with further testing. For ex: high level testing functionalities to see if it behaves as expected and app doesn’t crash once the build is deployed

Question 11

GUI

Answer 11

Testing what you see on UI, buttons, toolbar, icons, drop downs, color, feel, location displayed as expected.

Question 12

End-to-end testing

Answer 12

Is a technique used to test whether the flow of an application right from start to finish is behaving as expected. The purpose of performing end-to-end testing is to identify system dependencies and to ensure that the data integrity is maintained between various system components and systems. For ex: Let’s take positive scenario of login functionality, First i test the behavior in UI with valid credentials, then I will go and try to authenticate with token in services with the same credentials, then I will go to Credentials table in Database and query for the username I used and see if it exists and compare password as well

Question 13

Ad-Hoc Testing

Answer 13

Without having any requirements documentation. User browses through the system, learns and tests at the same time. Ad-hoc testing is done without any knowledge of application. Ad-hoc testing does not need test cases to follow. For ex: Let’s take password field, if we don’t have any requirements I would start with small/large cap chars, number and special chars

Question 14

Exploratory Testing

Answer 14

Is done when there is no requirements documentation. It is more about learning the applications workflow then testing it.

Question 15

What is Regression Testing?

Answer 15

Regression Testing: is rerunning functional test cases to ensure that recent code change has not impacted existing functionalities and behaving per requirement. For ex: I usually perform regression test by re-running my functional test cases after bug fix or enhancement in the build.

Example sentence: I usually perform regression test by re-running my functional test cases after bug fix or enhancement in the build.

Question 16

What is Targeted Regression Testing?

Answer 16

Targeted Regression Testing is rerunning certain subset of regression test cases instead of all of them by defining impacted area. For ex: If change is isolated, we can pick certain test cases to rerun as a targeted regression

Example sentence: If change is isolated, we can pick certain test cases to rerun as a targeted regression.

Question 17

What is Retesting?

Answer 17

Retesting is done on failed test cases to make sure that the original defect has been fixed. For ex: If the submit button was not working and after it got fixed, I have to retest to make sure submit button is working per requirements.

Example sentence: If the submit button was not working and after it got fixed, I have to retest to make sure submit button is working per requirements.

Question 18

What is Backend Testing?

Answer 18

Backend Testing: is making sure that data in Ul and Database is matching. For ex: Account balance in Ul and Database should be the same, I will query database for that user’s account balance in account Balance table then compare it with Ul

Example sentence: Account balance in Ul and Database should be the same, I will query database for that user’s account balance in account Balance table then compare it with Ul.

Question 19

What is Performance Testing?

Answer 19

Performance Testing: is performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It tests Throughput - how much data you can download in a minute for example. Latency - if you click how long does it take for the app to respond. Memory utilization - how much space it is taking up on the computer or server. CPU utilization - how much CPU is consumed. For ex: when you overload or stress the application with large size of data or large number of users simultaneously

Example sentence: when you overload or stress the application with large size of data or large number of users simultaneously.

Question 20

What is Load Testing?

Answer 20

Load Testing: is performed to determine a system’s behavior under both normal and at peak conditions by overloading the app with large size of data. For ex: loading large size of data to see how app behaves

Example sentence: loading large size of data to see how app behaves.

Question 21

What is Integration Testing?

Answer 21

Integration Testing: is performed to validate the integration between components meaning modules are interacting as expected. For ex: when Ul and DB are integrated, i have to validate the data is matching in both sources.

Example sentence: when Ul and DB are integrated, i have to validate the data is matching in both sources.

Question 22

What is ETL Testing?

Answer 22

ETL Testing done to ensure that the data that has been loaded from a source to the destination and making sure that data matches both in source and destination. For ex: If data is loaded from the first database to the second then I will query both of them and compare the data to make sure it is matching

Example sentence: If data is loaded from the first database to the second then I will query both of them and compare the data to make sure it is matching.

Question 23

What distinguishes Ul, GUI, and UX from each other?

Answer 23

Ul, or User Interface, refers to any platform that presents information to the user. A GUI, or Graphical User Interface, is a type of Ul that includes graphical elements. A terminal without graphics, like a UNIX terminal, is also a Ul but not a GUI. UX, or User Experience, pertains to the user’s overall interaction and satisfaction with the application.

Example sentence: Ul, or User Interface, refers to any platform that presents information to the user.

Question 24

How is User Experience (UX) tested?

Answer 24

While UX is often evaluated by specialized UX teams or professionals who understand user behavior, Quality Assurance (QA) engineers can contribute by conducting Usability Testing. This process doesn’t

Example sentence: Quality Assurance (QA) engineers can contribute by conducting Usability Testing.

Question 25

What is Ergonomics Testing?

Answer 25

Ergonomics Testing evaluates the usability of a device, including its ease of use, hold, reach, and operation. QA can propose usability and ergonomics improvements for a better user experience.

Question 26

How do you create a Test Case?

Answer 26

Test cases are created through requirement analysis, formulating positive and negative test scenarios, and then developing the test cases from these scenarios.

Question 27

How many test cases do you write a day?

Answer 27

The number of test cases written daily varies from 15 to 30, depending on the complexity of the features.

Question 28

What are the components of a Test Case?

Answer 28

A Test Case consists of several key components. The most crucial ones include: 1. Test Description: This provides a detailed explanation of what the test is aiming to accomplish. 2. Test Data: This refers to the sample data used specifically for testing this particular case. 3. Test Steps: These are the steps followed to execute the test on this particular issue. 4. Expected Results: These are the conditions that, once met, signify the completion of testing for this issue. 5. Actual Results: These represent the outcomes of the test execution. 6. Status: This indicates whether the test was a pass or fail. 7. Notes: These may include additional information, such as which server or database to use. 8. Author: The Quality Assurance (QA) professional who created this test case.

Question 29

What is STLC?

Answer 29

STLC stands for Software Testing Life Cycle, which encompasses all processes of testing: Requirements Analysis, Test Planning, Test Case/RTM Creation, Environment Setup, Test Execution, Defect Management, Test Analysis Reporting, and Sign Off.

Question 30

What do you do at work?

Answer 30

Day-to-day activities include requirements analysis, test planning, creating test scenarios, cases, and RTM documents, setting up the environment, conducting various testing types, logging and tracking bugs, performing full regression testing, and finally signing off.

Question 31

Explain me your day to day activities ? or give me full STLC process

Answer 31

At work i start with Requirment analysis. I take the requirments documantation from BA and start analyzing it for Testability by uncovering anything Vague, Incorrect or Contradictory. If i have any questions, inrequest to have a walkthrough Meeting with BA to get answers to my questions. Then i will start planning my testing process. What is the scope kf Testing, in which environment i will do testing. What Software and Hardware do i need for the Environment Setup, what are the schedules for this testing, who will be working on this project, QA, DEV, BA, PM etc, Afterwards i start creating my Test Scenarios, Test Cases and RTM documentations. Then i will follow the requirements for Environment Setup and i prepare my environment. Once developers finish coding and unit testing, they do the code drop and i start testing with smoke tsstung. Then i proceed with my other testing such as Functional, End to end, System, Backend Testinf types. When i find bug i reproduce it twice to make sure it is reproducible and chekc the jira for any duplicates. If no duplicates then i log the bug and assign to the Developer. If the bug i high priority, i truck thr bug closelsy till it is fixed. Once i execute all my test cases for this release, verify all high pirofity bugs fixed, i perform full regression testing, After regression testing is successful. I Sign off.

Question 32

How often do you report TAR and who do you report it to?

Answer 32

I report to my manager daily. My report will have all the knfo about the number of open, in progress and closed defects, list of high priority defects with its defectID and name, number of test cases created, executed, pass and fail, Project and release timelines and deadlines as well.

Question 33

What are included in the Test plan

Answer 33

Test plan is a document that outlines whole testing process of the product. It shows what/how/where/when will be tested and who will be working on it. Table of Content Introduction Scope Test strategy Environmental Test Schedule Control procedure Function Resources and Responsibility Deliverables Entry/Exit Criteria Dependencies Risks and Mitigation Tos Approvals Appendix

Question 34

How is the testing effort estimated?

Answer 34

The estimation involves a review of the Requirements Documentation and approximating time for various phases: 1. Requirements Analysis and Test Creation: For example, if there are 60 test cases and you can create 20 per day, it would take around 3 days. 2. Test Execution: Assuming an average execution of 15 test cases per day, for 60 cases it would be 3. Bug Life Cycle: The number of defects could range from 10% to 50%. Assuming a 25% defect rate, you might spend approximately 1 day reproducing, logging, and retesting defects. 4. Regression Testing: Depending on the scope, this could involve full or targeted regression testing, which might take, for example, 3 days. In this case, the total estimated testing effort would be 11 days. ## Footnote Example sentence: The testing effort for this project is estimated to be 11 days.

Question 35

What tools have you used in your last projects?

Answer 35

I used wide sets of testing tools in my last project. Among them, the most used ones were: - UNIX to track log file and analyze log file - PUTTY to log in to several QA servers at the same time - FileZilla to copy files from servers to local machine - TOAD to connect to Oracle database and perform backend testing using SQL commands - Notepad++ to open and view FIXML message - JIRA for issue and workflow management - GIT to store and retrieve automation scripts ## Footnote Example sentence: In my last project, I used a variety of tools such as UNIX, PUTTY, and JIRA.

Question 36

Where can you get test data?

Answer 36

Test data can be obtained from a variety of sources: 1. Test Plan: The Test Plan might include the required test data. 2. Development Team: - Developers might attach the necessary test data to the JIRA ticket. - They may extract data from the Production Environment and send it to the QA team via email. - Alternatively, they might provide 'insert' SQL statements which the QA team can use to populate new data into the database schema. 3. Senior QA Team Member: A senior QA professional who has been on the project for a considerable time might have stored test data that can be used. None of these sources provide the needed data, the A team can create is Own test data based or the requirements detailed in the JIRA ticket. ## Footnote Example sentence: If test data is not available from the Test Plan or Development Team, the QA team can create their own test data.

Question 37

What is a bug

Answer 37

when actual result doesnt match expected result then it is a bug.

Question 38

What is a bug life cycle?

Answer 38

Bug tickets life from creation till closing. New Open Fixed Closed

Question 39

Who can open and who can close the bug?

Answer 39

Anyone can open a Bug, QA BA and DEV. Verification and closing the bug is QAs job

Question 40

What do you do when you find a bug?

Answer 40

Reproduce the bug twice to make sure it is reproducible ## Footnote See if there are any duplicates logged by others Then log the bug

Question 41

What goes in to bug ticket/defect?

Answer 41

It depends on defect management tool and the project. Actually, there are many things that go in to bug ticket but the most important ones are: 1. Bug title 2. Project 3. Environment 4. Versions (Version Bug found, and Version bug was Fixed) 5. Bug description/Steps to reproduce 6. Priority/Severity 7. Assignee/Reporter 8. Attachments

Question 42

What is Bug Severity and how is it determined?

Answer 42

Bug Severity is assessed by the QA team when a bug is discovered. It is categorized into: 1. Showstopper: These are bugs that prevent QA from verifying other functionalities, such as a non- functional login page or a page crash. 2. High: These are major issues causing functional disruption, data loss, or crashes. 3. Normal: These bugs result in a partial function breakdown without causing a crash or data loss. An alternative workflow is available. 4. Low: These are minor or cosmetic issues, such as UI problems, misspellings, or color mismatches.

Question 43

What is Bug Priority and how is it determined?

Answer 43

Bug Priority is typically determined by a Business Analyst, although in some companies, QA may assign it as well. It is categorized into: 1. High: Bugs that affect the company's reputation, major customers, or a large user base. 2. Normal: issue that disrupt and alternative workflow 3. Low: bugs that dont impact revenue or reputation.

Question 44

What steps would you take if you're uncertain whether an issue is a bug after replicating it?

Answer 44

In such a case, I would adopt the following approach: 1. Review the Requirements: I'd revisit the requirements for the test case in question to ensure I fully understand the intended functionality. ## Footnote Example sentence: Reviewing the requirements helped me identify a misunderstanding in the expected behavior.

Question 45

What steps would you take if you're uncertain whether an issue is a bug after replicating it?

Answer 45

2. Troubleshoot: I'd continue to investigate the issue, trying different scenarios and approaches to better understand its nature. ## Footnote Additional information: Sometimes, the issue may not be a bug but a result of incorrect usage or setup.

Question 46

What steps would you take if you're uncertain whether an issue is a bug after replicating it?

Answer 46

3. Collaborate with the Team: I'd discuss my observations and findings with the Business Analyst and Developers to gain more insights and to clarify any doubts or ambiguities. ## Footnote Additional information: Collaboration with the team can lead to a better understanding of the issue and potential solutions.

Question 47

What is Boundary Testing?

Answer 47

Testing extreme ends and beginnings. For ex: password should be from 6 to 12 characters. Then testing with 6 and 12 is Positive and testing with 5 and 13 negative testing. ## Footnote Example sentence: Testing the boundary values of a password field.

Question 48

What is Risk Based Testing?

Answer 48

Prioritizing testing. Testing most important and most vulnerable functionalities first Functionalities that have highest impact on business needs, money and reputation Vulnerable functionalities we know often breaks Most used parts of the application Areas of complex design; interrelated functionalities ## Footnote No additional information provided.

Question 49

Why might a developer reject a bug?

Answer 49

A developer might reject a bug for several reasons: 1. They are unable to reproduce it: this could be due to incorrect or missed steps to reproduce. 2. Misunderstanding of requirements: The developer or QA might have misinterpreted the requirements. 3. They consider it a feature, not a bug: 4. They identify it as a know issue: The bug might be low priority, low severity defe t scheduled for a future fix.

Question 50

What types of bugs do you typically encounter

Answer 50

I typically encounter backend, functional, and non functional bugs.

Question 51

Can you provide expamples lf yoi encountered bugs

Answer 51

Examples of bugs i encountered include discrepancies in responses compared to expected result,

Question 52

What is a Showstopper Defect?

Answer 52

A showstopper defect prevents further testing because it makes the application inoperable. For example, a non-functional login button that prevents access even with valid credentials. ## Footnote Example sentence: A showstopper defect in our recent release was a critical crash that occurred whenever users tried to save their progress.

Question 53

How do you identify which bugs need to be fixed within the release?

Answer 53

Through a Bug Triage meeting with the Business Analyst and Developers, we prioritize the bugs that need to be fixed before going live. I ensure these are addressed in time by coordinating with the Developers. ## Footnote No additional information.

Question 54

How many bugs do you typically find in a sprint?

Answer 54

The number of bugs found in a sprint can vary, but it's typically between 3 to 10, depending on the release. ## Footnote No additional information.

Question 55

What did you work on lately? What recent releases have you worked on and what enhancements can you test?

Answer 55

I recently worked on a release that introduced a new feature for on-demand report generation, accessible directly via the user interface. This feature allows users to request customized reports that directly extract data from our databases. My testing for this enhancement involved validating that all necessary fields were populated correctly, confirming that the data accurately mirrored the backend data, and checking the smooth operation of this functionality. ## Footnote No additional information.

Question 56

How do you create test data?

Answer 56

Test data creation is based on the specific requirements. One of the quickest methods is to examine data from the production environment to obtain sample data or comparison files. ## Footnote Example sentence: When creating test data for the new feature, I looked at the production database to generate sample data.

Question 57

Have you performed testing in a production environment?

Answer 57

Yes, I have conducted smoke testing in the production environment during deployments to ensure application stability and expected behavior. Full QA testing, including functional and non-functional, isn't conducted in production due to potential unintended consequences. ## Footnote Example sentence: During the last deployment, I conducted smoke testing in the production environment to verify the critical functionalities.

Question 58

Have you collaborated with offshore teams?

Answer 58

Yes, I have regularly collaborated with an offshore team in Moldova, which included providing demos of new features, sharing functional test cases, and answering their questions. I've also communicated daily with an offshore development team regarding sprint stories. ## Footnote Example sentence: Collaborating with the offshore team in Moldova has been a great experience, as we work together seamlessly despite the time zone difference.

Question 59

How do you communicate within your team?

Answer 59

I utilize various communication methods with both onsite and offshore team members, which include Skype messaging, emails through MS Outlook, phone calls, face-to-face meetings, and conference calls. ## Footnote Example sentence: Communication within the team is essential, so I make sure to have regular Skype meetings with the offshore team to discuss project updates.

Question 60

How do you handle uncertainties in requirements?

Answer 60

When I encounter uncertainties in requirements, I schedule an informal walkthrough meeting to ask clarifying questions. ## Footnote Example sentence: To address the uncertainties in the project requirements, I organized a walkthrough meeting with the stakeholders to gather more information.

Question 61

What attributes define a good test case?

Answer 61

A good test case should cover the requirement comprehensively, be succinct, easy to understand and follow, reusable, and storable for future use or transfer. ## Footnote Example sentence: I always strive to create good test cases that are clear, concise, and cover all aspects of the requirement.

Question 62

What makes requirements document effective?

Answer 62

An effective requirements document contains detailed, clear, and concise explanations of requirements, complemented by diagrams or illustrations that demonstrate the functionality. ## Footnote Example sentence: The effectiveness of a requirements document lies in its clarity and completeness, which helps in guiding the development process smoothly.

Question 63

Which test cases are given high priority

Answer 63

High priority is given to test cases concering core workflows or functionslities and those involving user interface or files that impact busienss reputation

Question 64

How do you determine the priority of regression test cases?

Answer 64

The priority for regression testing, also known as risk-based testing, is determined based on factors like the functions most used by users, complex areas of the architecture/code, high priority business functionalities, and functions that are prone to breaking.

Question 65

What criteria do you use to prioritize test cases for automation?

Answer 65

Test cases for automation are prioritized based on their repetitive nature, stability of functionalities, business priority, and a cost-benefit analysis where the benefits of automation exceed the time and effort required to automate.

Question 66

What is the entry criterion for test case creation?

Answer 66

The entry criteria for test case creation include analyzing requirements and generating both positive and negative test scenarios.

Question 67

What are the entry criteria for testing?

Answer 67

The entry criteria for testing generally includes the following prerequisites: 1. Completion of Test Cases: All test cases relevant to the functionality to be tested should be written and reviewed. 2. Setup of the Testing Environment: The appropriate testing environment should be set up and ready for use. 3. Completion of Unit Testing by Developers: Developers should have completed unit testing of their code, ensuring basic functionality is working as expected. 4. Successful Code Deployment to the QA Environment: The code to be tested should have been successfully deployed to the Quality Assurance (QA) environment.

Question 68

What is the entry criterion for deployment?

Answer 68

Deployment can begin once all test cases have been executed, all high-priority bugs have been fixed and verified, and all regression tests have been successfully executed without finding further high-priority bugs.

Question 69

What are the exit criteria from testing? Or What is the entry criteria for sign-off?

Answer 69

Sign-off can occur when all test cases have been executed, all high-priority bugs have been fixed and verified, and regression testing has been successful with no further high-priority bugs found.

Question 70

What is the entry criterion for smoke testing?

Answer 70

Smoke testing can start once smoke test cases have been created, the environment is set up, unit testing is completed, and the new application version has been deployed in the QA environment.

Question 71

Did you set up your own QA environment in your last project?

Answer 71

Yes, when I joined the company, I spent my initial days downloading required software, requesting access to internal QA servers, and liaising with the database team to create my schema in the OA database. As the database size was substantial, I manually copied records from other schemas into my own empty schema.

Question 72

What is root cause analysis?

Answer 72

Root cause analysis involves identifying the source of a problem, determining which technology stack contains the bug — be it UI, server, or database —and pinpointing its location in the code, data, or configuration.

Question 73

What is an RTM?

Answer 73

An RTM, or Requirement Traceability Matrix, is a document that maps requirements to test cases to ensure that all requirements are covered.

Question 74

What is a test suite?

Answer 74

A test suite is a collection of test cases that are designed to validate a specific application's functionality.

Question 75

Which HP ALM modules have you used?

Answer 75

I've worked with the Test Plan module for writing test cases, the Test Lab module for executing them, and the Defects module for logging any defects.

Question 76

Could you describe your release or sprint process?

Answer 76

Sure, our sprints were three weeks long. Initially, I spent about two days analyzing requirements and writing test cases. Following this, I set up my testing environment and awaited the completion of unit testing and the code drop to the QA environment. After this, I started with smoke testing, then functional and non-functional testing. I logged any bugs found, prioritized high-priority bug fixes, and verified them once fixed. The final week was dedicated to regression testing of the application. The process concluded with the creation of a test report and my sign-off on the testing phase.

Question 77

Have you ever been involved in regression testing?

Answer 77

Yes, I have done regression testing at the end of every sprint to verify that all changes that our team and other teams made within that release did not affect the existing functionalities of the system.

Question 78

If there are multiple QAs how do you know which part of the work is yours?

Answer 78

QA Lead will distribute the work among the QAs. Work mostly divided up by the certain parts of the application.

Question 79

What was the composition and size of your team?

Answer 79

My team consisted of one business analyst (BA), eight developers, and three QA testers. The BA also acted as the scrum master.

Question 80

Could you discuss your experience with JIRA?

Answer 80

I have used JIRA extensively for project management and issue tracking. As a tester, I primarily used it to create defects, assign them to developers, monitor issues until they were resolved, and review project details to create deployment test plans.

Question 81

What is your approach to testing a web-based application?

Answer 81

Upon beginning the testing process for a web-based application, I initially connect to its UNIX Server and corresponding database. I then monitor the log files as I begin testing. First, I verify that the new code is running in the QA environment and that I can successfully log into the website, checking log files throughout for potential errors. I then continue testing based on the tickets assigned to me. If I am performing regression testing, I prioritize the most crucial functionalities. While conducting UI tests, I also validate the database to ensure it's generating the expected data. If the application runs smoothly on my current browser and version, I test it on different browsers and versions to evaluate cross-browser and cross-version functionality. I continue this process until all functionalities have been verified to work as per requirements.

Question 82

Can you walk through bug life cycle, please?

Answer 82

Bug life cycle has several sequential steps and they are called differently in HP ALM, JIRA or Bugzilla. But usually when bug is found and reported, it is called NEW. After developer accepts the bug, then the status changes to OPEN. After Developer finishes the fix, the status changes to FIXED. So, it is tested and if it was fixed, the ticket is closed and status changes to CLOSED. There some more scenarios throughout bug life cycle. When bug is low priority, it can be postponed to future releases. In this case, the status of bug changes to DEFERRED. If the bug is a duplicate, the status is changed to DUPLICATE. And if the fix provided by developer did not solve the issue, the bug is reopened and status changes to REOPENED.

Question 83

Have you ever been involved in regression testing?

Answer 83

Yes, I have done regression testing at the end of every sprint to verify that all changes that our team and other teams made within that release did not affect the existing functionalities of the system.

Question 84

If there are multiple QAs how do you know which part of the work is yours?

Answer 84

QA Lead will distribute the work among the QAs. Work mostly divided up by the certain parts of the application.

Question 85

What was the composition and size of your team?

Answer 85

My team consisted of one business analyst (BA), eight developers, and three QA testers. The BA also acted as the scrum master.

Question 86

Could you discuss your experience with JIRA?

Answer 86

I have used JIRA extensively for project management and issue tracking. As a tester, I primarily used it to create defects, assign them to developers, monitor issues until they were resolved, and review project details to create deployment test plans.

Question 87

What is your approach to testing a web-based application?

Answer 87

Upon beginning the testing process for a web-based application, I initially connect to its UNIX Server and corresponding database. I then monitor the log files as I begin testing. First, I verify that the new code is running in the QA environment and that I can successfully log into the website, checking log files throughout for potential errors. I then continue testing based on the tickets assigned to me. If I am performing regression testing, I prioritize the most crucial functionalities. While conducting UI tests, I also validate the database to ensure it's generating the expected data. If the application runs smoothly on my current browser and version, I test it on different browsers and versions to evaluate cross-browser and cross-version functionality. I continue this process until all functionalities have been verified to work as per requirements.

Question 88

Can you walk through bug life cycle, please?

Answer 88

Bug life cycle has several sequential steps and they are called differently in HP ALM, JIRA or Bugzilla. But usually when bug is found and reported, it is called NEW. After developer accepts the bug, then the status changes to OPEN. After Developer finishes the fix, the status changes to FIXED. So, it is tested and if it was fixed, the ticket is closed and status changes to CLOSED. There some more scenarios throughout bug life cycle. When bug is low priority, it can be postponed to future releases. In this case, the status of bug changes to DEFERRED. If the bug is a duplicate, the status is changed to DUPLICATE. And if the fix provided by developer did not solve the issue, the bug is reopened and status changes to REOPENED.

Question 89

How do you handle recurring bugs in production?

Answer 89

When faced with recurring bugs, I work collaboratively with developers to identify the root cause and address the issue. I explore alternative paths for the use case and report findings to the business analyst or product owner. I also prioritize the bug in my testing based on its business criticality, even working overtime if necessary. As a QA, I mark the affected code base or functionalities as risk areas and prioritize them during regression cycles. ## Footnote Example sentence: When a recurring bug was identified in the login functionality, I worked closely with the developers to fix the issue and conducted extensive testing to ensure it was resolved.

Question 90

Have you encountered recurring bugs in production?

Answer 90

No, all my tests have been successful, and I have not had any medium or high-priority operational incident reports (OIRs) related to my testing. ## Footnote Additional information: I have a track record of thorough testing that has prevented recurring bugs from occurring in production.

Question 91

Why do you prefer Agile methodology?

Answer 91

I prefer Agile methodology because it is flexible, encourages team collaboration and communication, and involves testers from the beginning of the sprint. ## Footnote Additional information: Agile methodology allows for quick adaptation to changes in requirements and promotes a continuous feedback loop.

Question 92

What are the meetings or ceremonies in Agile?

Answer 92

Agile involves five key ceremonies: Backlog Grooming, Sprint Planning, Daily Scrum Standups, Sprint Review, and the Retrospective Meeting. ## Footnote Additional information: These ceremonies help teams stay aligned, plan effectively, and continuously improve their processes.

Question 93

What are the artifacts in Scrum?

Answer 93

Scrum artifacts include the User Story, Use Cases, Sprint Backlog, Product Backlog, and Release Backlog. ## Footnote Additional information: These artifacts are essential for defining, planning, and tracking the progress of a Scrum project.

Question 94

Could you describe the testing artifacts you've created?

Answer 94

I assisted the QA Lead in creating a test plan, defining the testing scope, types of testing, and potential timeline at the sprint's start. I also prepared a test plan for deployment testing. I've created various test cases for functional testing and a Requirement Traceability Matrix to map these cases to business requirements. In my second project, I developed Acceptance Criteria and added it to JIRA tickets I worked on. ## Footnote Example sentence: For the last project, I created detailed test cases for each user story and maintained a traceability matrix to ensure all requirements were met during testing.

Question 95

Do you deploy code into QA environment?

Answer 95

No. I don't. There is a separate team that handles code deployment. After finishing coding, developer create a JIRA ticket requesting configuration management team to deploy new build/code into C Environment.

Question 96

How do you link Test Cases and Defects in HP ALM?

Answer 96

Step 1 - Go to Test Case and click on Linked Defect Step 2 - If it is new click the first icon Step 3 - Fill out the defect and click ok, done it will be linked ## Footnote Step 1 - Go to linked Defects in Test Case Step 2 - Click the second icon, link existing defect Step 3 - Enter Defect ID and click Link

Question 97

Have you done performance testing before?

Answer 97

Yes, I have done performance testing. I timed results by checking the log file times. Can load the by downloading/uploading huge data or querying for wide periods and large datasets.

Question 98

How do you manually conduct performance testing.

Answer 98

To manually stress test a system, I employ various methods, including Executing wide range of data search Initiating heavy server loads Uploading and downloading large volumes of data Using application while running other demanding tasks on the computer.