Real Life & Framework Flashcards

1
Q
  1. Tell me about the D2D activity?
A

D2D activities:
● Check emails
● Check Jenkins reports to get smoke or regression status. If there are any failures, I will need to rerun the smoke test and see if the actual environment is down or there is an issue with my script or if there is an actual bug.
● Check user stories status in Jira, bug status reports.
● Attend Daily Stand Up to discuss what I did yesterday, what I am going to do today and if there are any issues.
● Analyze user stories, create manual test cases and prepare test data if needed.
● Execute manual test cases, talk to developers, report any found bugs in JIRA
● Automate and execute test cases.
● Update Status in JIRA (Move stories from In Testing to Done)
● Framework enhancement
● Execute Regression before each project release (could every sprint or every other sprint)

Meetings:
➔ if it is the beginning of the sprint after Daily Stand Up you are attending Sprint Planning
➔ in the middle of Sprint you will have a Sprint Grooming session for upcoming sprints or any future sprints.
➔ if it the end of the sprint you will attend Sprint Demo and then Sprint Retro
➔ we have weekly meetings (on Mondays or can be on Fridays) with the entire QA team (QA Manager Test Leads and all testers from different projects that work in the company)
➔ code review (once during the sprint)- meetings where you will review each other’s code, learn and improve and make sure everyone follows framework structure and coding standards.
➔ Ensure that all test related work is carried out as per the defined standards and procedures.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is your role as a QA Automation Engineer?

A

Roles and Responsibilities:
● As a QA Automation Engineer my responsibilities are to Design, Develop and Maintain Test Automation Framework for the application I am supporting.
● Understand requirements/user stories and create Test Cases based on the acceptance criteria.
● Automate and execute Regression and Smoke test cases.
● Maintain and execute automated smoke tests every morning to verify stability of the environment.
● Actively participate in all agile scrum meetings and provide feedback to the team.
● Find bugs and report it in JIRA for the development team to fix it.
● Analyze the changes in the new build and update it accordingly.
● Attend any urgent troubleshooting triage or meetings
● Help Team members in understanding any requirements whenever needed

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q
  1. Tell me about your team and your scrum structure
A

Every company is unique and will have a different number of team members.
Below are just examples from one of the projects.
We are totally 6/9 or more members within the team:

Scrum Team
1 Product Owner
1 Scrum Master
5 Developers: 2 full stack and 3 frontend
2 Automation Engineers including me
The rest of the team
2 Business Analyst
2 UI UX
1 Architect
1 PM

Our sprints are ___ weeks long and starts on _____
We have our sprint ceremonies that held on different days during the week:
● Sprint Planning - first day of the sprint at 10 AM (can last 2-4 hours depend on the team size and how long is the sprint)
● Daily Stand Up - everyday at 10:15 AM
● Sprint Demo/Review - last day of the Sprint at 11 AM (usually last between 30 mins - 1 hour)
● Sprint Retrospective - last day of the sprint at 1 PM (usually after the Sprint Demo)
● Sprint Grooming/Story Refinement - once a week at 1 PM (usually can be for 1-2 hours to discuss stories for upcoming sprints)
Please make sure to have your numbers of team members and times of the meetings!

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q
  1. What type of tests have you automated? How many test cases have you automated per day? When do you do automation in your sprint?
A

Mostly I have automated functional regression tests (including smoke and regression, database and API testing) and we do in-sprint automation of user stories. When developers are done with development of the user story and code is deployed to a QA environment, I test the user story manually and then do automation.

There is no right or wrong answer on the automation of test cases per day:
● It all depends on the functionality and complexity of the scenario.
● I always follow coding standards and focus on the quality of my scripts not quantity. Sometimes just find a right locator and specify dynamic xpath takes time
● Since I work in an Agile environment some days will be spent attending sprint meetings.
● When developers fix any bugs, I jump on retesting that bug based on its priority and severity. On top of that, when some of the team members have any challenges and need my help, I always try to help them.

Ask them how they do automation in their company.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q
  1. What is smoke testing and how do you run it in your project? How many test cases are there and how often do you perform smoke testing?
A

Smoke Test is a process where the software build is deployed to the QA environment and is verified to ensure the stability of the application. All the critical functionalities would be put to test here.

Once the build clears the first state, it will be taken for further QA tests, and if the build fails the test, it would be rejected.

A major benefit of running a smoke test is that it provides quick feedback within a matter of a few minutes and testers don’t have to wait hours to get results. In simple terms, we are verifying whether the important features are working and there are no showstoppers in the build that is under testing.

We have a dedicated pipeline for our smoke test within our Jenkins and since Jenkins is a web-based application, anyone can access it by using its URL.

Provide the following arguments during the initial configuration:
● Environment in which we need do the smoke test
● Browser: IE is default
● Suite: smoke test. Suite

And then whenever there is a code push our smoke test pipeline is automatically triggered. In my smoke suite I have around 12-25 scenarios that are executed within 10-15 mins.Runner.exe also creates a nice result file with the test cases details execution. Jenkins sends the smoke test result to the entire team members and in case of issues, developers can look into that immediately.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q
  1. What is regression testing and how do you run it in your project? How many test cases are there and how often do you perform regression testing? How long does your regression suite run?
A

Regression testing is a type of software testing where testers verify whether the previous functionality of the application is working fine, and the new changes have not introduced any new bugs.

When we perform regression testing:
● Bug fix
● New feature added
● Changes in existing feature
● Performance issue fix

Every company release will be scheduled differently.

Example: in 1 project there could be only quarterly releases while in the other every other sprint or every 4 sprints.
Here we need to pick 1 number.

How is the regression executed?
Regression is triggered by Jenkins.
For Cucumber: whenever we write test cases in our feature files we add @Regression tags for each scenario and later through the Regression runner class we execute those tagged scenarios.
For TestNG: we have regression TestNG XML in that we add regression related test cases.

Meanwhile, I also perform manual test cases execution and on top of that I always try to perform ad hoc testing.

Once execution is done, I will analyze results for any failed test cases. I will identify whether test cases fail due to environment performance issues, script related issues or application issues. Once I know that the script failed due to the application issues, I will retest that particular test case and try to reproduce the bug and verify it against requirements. Once I confirm the bug, I will log it into the Jira application providing a description of the bug with severity and priority level, steps to recreate and appropriate screenshots.

Execution time of regression depends on how many test cases you will have, just do
not say 10 mins or 30 mins!
Example: 300 test case/scenarios can be executed in about 3 hours
750 tests of GUI and API about 5-6 hours
1200 test cases (UI, database, API) - 9 hours

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q
  1. How do you build an Object Repository in your project?
A

In our framework, we call objects as locators (such as ID, Name, Class Name, Tag Name, Link Text, Partial Link Text, XPath, and CSS).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q
  1. Please explain one of the most challenging situations you’ve ever had to resolve at work?
A

In this type of question, the best answer is to explain your starting workdays where you faced too many difficulties and how you made progress.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q
  1. Please tell me about the time you took the initiative on your project.
A

In this answer you should keep focus on yourself, however, don’t forget to give equal credit to your team members as well. Try to use examples where you went beyond your D2D role and took some additional responsibilities.

If you did anything for your colleague–for example offered to take their shift when they felt sick, or stayed overtime in work to help them with a heavy workload, you can definitely talk about this as an example of a time when you showed initiative.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q
  1. How do you approach issues and what’s your process?
A

explain how you prioritize and then break your task into smaller pieces and the approach you have followed to achieve one goal at a time.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q
  1. How would you handle unplanned changes?
A

Changes in the Agile environment are very common. This is the time you need to showcase your flexible mindset, attitude towards frequent changes and your willingness to embrace changes with an open mind.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q
  1. What is the difference between SDET & Software Testers?
A

● Test Engineer thinks only in the terms of pass or fail of a test case and how to break the software
● Test Engineer works only for test life cycle, like design of test cases, and execution
● No coding knowledge is required
● Test Engineers know where repetitive work or simple data entry is present, but they are not expected to minimize the repetitive tasks
● Test Engineers are not expected to reach up to code level and tune the performance
● SDET knows system functional objectives as well as quality objectives
● SDET is involved in Designing, development, and testing
● SDET has Dynamic skill sets, like knowledge of quality and testing and good in coding too
● SDET understands automation needs, they can code and provide a solution to the team where repetitive kind of work is killing the time.
● They can design a framework which can help the testing team to reduce repetitive test cycles or simple data entry tasks.
● SDET are Well aware of Performance tuning and security threats, they can suggest and reach to the code and suggest where application is poor in performance, plus they can optimize the code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q
  1. Tell me about your framework
A

Let me elaborate on the structure of my framework.

The current project that I’m working on has a hybrid framework which supports behavior driven development and data driven testing.

Maven: First, we have a Maven project that helps build project structure, manage project dependencies and execute automated scripts. In the Page Object Model file (or POM file) we add all dependencies that are required for the project. Some of these dependencies are Selenium, Cucumber, JUnit, JDBC, and Rest Assured.

Now my framework is organized into 2 main packages, first being resources where there’s no technical content and the second package is for Java which houses all code.

part of the resources is Config Reader: 
In this class we are extracting the value of our browser and url from properties file and using those values at the WebDriver initialization and navigating to the specific url.

Feature file:
here we are writing our test cases to test UI, Database and API. Our tests are written using the Gherkin language and its keyword Given, When, Then along with the Background keyword, Scenario and Scenario Outline. We also use tags in order to execute smoke and regression test cases in our feature files.

Now in our Java Package
Step Definitions:
In this we are actually implementing our automation scripts and logic using Selenium and Java and performing validations using JUnit assertions.

Pages:
My framework is built using a POM approach to eliminate code redundancy, improve code reusability and make it easy to maintain. In this we are storing information about pages, it’s elements and actions that need to be performed. We are using @FindBy annotation to locate the element and PageFactory to initialize all elements.

Common Methods:
In this we are going to outline the common reusable function for example mouse hover, handling alerts, frames and windows, taking screenshots, and javascript executor.

Constants: 
This class holds the information which is static final in nature and remains the same throughout the entire framework such as path to the configurations, reports, operating system type, implicit and explicit waits.

Cucumber Hooks:
using @Before and @After annotation we call the setup method that initializes our driver and we call the method to initialize all page elements. Also using the @After hook we are taking screenshots on every failed scenario.

Runner: 
It's the execution point of our framework. In our runner class using Cucumber options we specify configurations of our tests. We have separate smoke, regression and API runner classes.
DBUtility: 
In this class we store functions to open database connections, extract data from database and store in Java Data Structures, such as List, Map or List of Maps.
APIUtility:
Here we store the API Constants with the help of of REST Assured (a Java library) and the Payload Constants class with the help of JSON Object. Also, there's the APIWorkflow steps

Target:
The last component is the target folder where all Cucumber Html and advanced reports will be generated successfully in the target folder.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q
  1. Automation challenges and how did you solve them? What are the challenges you face when running automation scripts? Overall challenges?
A

Scenario 1: Maintenance of Web Elements
When I first joined the company, we faced issues with maintaining elements. Framework was not properly structured and maintenance of it was taking more time than automation of new features. With the help of my team, I implemented the POM concept in our framework. I gave a demo of the new design to the entire team and once it was approved, we continued our automation. As of now we have a complete robust framework that is easily maintainable and understandable by any automation engineer that joins the team.

Scenario 2: Dynamically changing elements on the web page
To resolve that issue, we can go for XPath, where I can use contains or start with:
//div[contains(@id,’post-body’)]
//div[starts-with(@id,’post-body’)]
Also, I can create my own custom XPath by using parents or preceding/followingsiblings:
//label[text()=’DateofBirth’]/following-sibling::img[@class=’ui-datepicker-trigger’]

Scenario 3: Stale Element Reference Exception:
In my current application sometimes, we get errors saying Stale Element Reference Exception for some specific elements. After analyzing failure issues, I implemented WebDriver waits and JavaScript executor to handle those errors.

Scenario 4: Cross browser Testing issues
In every project it is required to perform multi-browser testing to make sure that the functionality is working as expected with every browser to give equal user experience to all of the wide range of Users. Our selenium test scripts were executed properly in Chrome Browser, but in Edge browser we faced so many issues like timeout problems/Synchronization problems…We found that Edge Browser is slower than Chrome browser in Test case execution, so we implemented both implicit and explicit wait for our scripts and also changed some of the locator from xpath into the CSS. On top of that since we work in agile, and we work closely with developers whenever they are working on new features, I asked them to provide ids for the elements.

Scenario 5: Working with dynamic values in WebTable
Data in Web Table mostly is always dynamic, so we cannot hardcode any cells or rows elements. Every time we work with WebTable we will have to loop through each row and cell

Scenario 6: Validation of Data from UI, Database, API
In my current application we support ui, database and API automation. Data that has been returned from those parts of the application is in different formats. I have developed functions to retrieve data from UI, JSON object and ResultSet Object into a Java data structure which is a List of Maps.

Scenario 7: Selenium works only for Web Based applications and does not provide any reports. Selenium cannot automate captcha and barcodes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q
  1. What have you done to improve the performance of your framework?
A

● Create reusable component
● Write optimize function with precise logic
● Follow coding standard
● Write locators to handle dynamic elements
● Provide data in external files such as excel, txt, property files

Please give some examples of common methods, Excel, DB or API utility when answering this question.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q
  1. How many changes do you need to make to manage your automation scripts? How do you maintain your test scripts and how frequently do you have to modify them?
A

It all depends on types of changes. As an example, if any web element changes since we are maintaining POM design, we only need to update that 1 web element in that particular class page. However, if existing functionality changes, then whatever functions we have created that we need to update as per new changes.

Whenever we get new changes, and a test fails that time we refine & modify test scripts.

17
Q
  1. How did you conduct Batch Testing in your project?
A

When we run multiple scripts, with Automation Tool, that is called batch testing.

We conducted Batch Testing using TestNG Testing Framework using @groups.

In Cucumber we are using the @Tags options for running the batch of test cases.

18
Q
  1. What drivers do you use in your framework?
A

ChromeDriver
Edge
Safari

Mostly we perform our execution in edge and chrome browser

19
Q
  1. How would you handle test data in your framework? How do you run tests using excel data?
A

Cucumber framework:
Using Scenario Outline (Inbuilt mechanism to retrieve data), DataTable (Developed logic to retrieve data in a form of List), and Excel (Reading using Apache POI and store it in the List)

20
Q
  1. Tell me about your reporting systems? Where do you store the test results/reports?
A

We use Cucumber Reports. Reporting plays a key role in any project. At the end of the day everyone is interested to see your reports, not the code.

Cucumber provides default HTML report, and, in my project, we are using Maven Cucumber plugin which provides following benefits:
● Graphical representation: It will convey the statistical results like % passed / failure status
● Consolidated view: Detailed execution status in numbers will be displayed.
● Error Analysis: It will help the user to analyze and debug the issue. Users can access the test data and Test evidence from reports, which are the most important aspects while fixing the bugs.

21
Q
  1. If I hire you and ask you to come and start automation, how would you do it?
A

● Analyze application
● Choose and Find Automation tool experts
● Create and Execute Manual Test Cases
● Analyzing test cases to determine those which are best suited for automation
● Create Smoke Test and present to the team
● Creating the test automation Framework
● Writing Scripts
● Reporting
● Maintenance of Scripts

Automation Life Cycle:
Simply we can say as:
Analyze the Application -> Select the tool -> Identify the scenarios -> Design test scripts -> Modify test scripts -> Run the test scripts -> Report defects

22
Q
  1. What type of test cases you won’t pick up to automate?
A

Before picking up the test cases to automate, I do check whether the application is stable or not. So based on this, I don’t pick up test cases when the AUT changes frequently and the test cases which I run rarely and run only one time.

23
Q
  1. Why is Automation Testing required?
A

It is required when we have a huge amount of regression test cases.
It is required to save time & money
It is required to increase the test coverage
It is required to run tests anywhere & anytime
It is required to generate robust reports
It is required to test non-functional aspects of an application
It is required when we run tests with multiple sets of data
It is required when testing manually is impossible
It is required to test on several different hardware or software platforms and configurations

24
Q
  1. What is Automation Testing? What are the benefits of Automation Testing?
A

Automation Testing means using an automation tool to execute your test case suite. The automation software can also enter test data into the System Under Test, compare expected and actual results and generate detailed test reports.

Faster Feedback: Automated testing comes as a relief for validation during various phases of a software project. This improves communication among coders, designers and product owners, and allows potential glitches to be immediately rectified. Automated testing assures higher efficiency of the development team.

Accelerated Results: Due to the quick implementation of automated testing, plenty of time is saved even for intricate and enormous systems. This allows for the testing to be carried out repeatedly, delivering faster results each time with lesser effort and time.

Reduced Business Expenses: While the initial investment may be on the higher side, automated testing saves companies many a penny. This is predominantly due to the sharp drop in the amount of time required to run tests. It contributes to a higher quality of work, thereby decreasing the necessity for fixing glitches after release and reduces project costs.

Testing Efficiency Improvement: Testing takes up a significant portion of the overall application development lifecycle. This goes to show that even the slightest improvement of the overall efficiency can make an enormous difference to the overall timeframe of the project. Although the setup time takes longer initially, automated tests eventually take up a significantly lesser amount of time. They can be run virtually unattended, leaving the results to be monitored towards the end of the process.

Higher Overall Test Coverage: Through the implementation of automated tests, more tests can be executed pertaining to an application. This leads to a higher coverage that in a manual testing approach, would imply a massive team limited heavily with their amount of time. An increased test coverage leads to testing more features and a higher quality of application.

Reusability of Automated Tests: Due to the repetitive nature of test automation test cases, in addition to the relatively easy configuration of their setup, software developers have the opportunity to assess program reaction. Automated test cases are reusable and can hence be utilized through different approaches.

25
Q
  1. Why does manual testing still exist, even though automation has been proven to be more efficient?
A
  1. When a new feature is implemented, initially running a manual test is essential to ensure functionality meets acceptance criteria. In order for a test script to be properly automated, the exact test steps need to be manually executed and documented.
  2. Manual testing also includes exploratory testing which enables testers to find weaknesses, and risks. This enables testers to determine which part of the application needs more testing. Manual testing is less expensive in the short-term. If you’re only testing a simple application once, and don’t expect lots of updates, manual testing doesn’t require you to invest in expensive tools or software. This is considered flexible and on-the-fly testing. Automation testing requires you to write, program, and review test cases for your software. But, if you really only need to test one small change, you can manually test it faster than it would take to automate. This is beneficial when a high priority bug fix needs to go out to production immediately.
  3. Manual testing provides the human element to make sure the feature is user-friendly. A manual tester could tell you that the contrast between a button and the background is too light, which makes it hard to see the button and understand what action needs to be taken. This type of user interface (UI) feedback is something automated testing wouldn’t find, making manual testing closer to the sort of feedback you might hear from actual customers. Manual testing is valuable early in the development of features and user interfaces because layout and controls are often changing (almost daily) in response to design considerations and user feedback. Being able to predict what your users will or won’t like—things a computer can’t give feedback on—ahead of time can influence your design and make it better from the bottom up.
  4. Manual testing identifies bugs that can be found in areas users wouldn’t expect. Typically, these bugs are found by quality assurance teams who were looking for something other than the issue they found. Automation will not find errors it wasn’t scripted to find. It’s impossible to catch all bugs on the first round of testing, so manual testing is a faster “catch-all” for what could possibly be missed.
  5. Manual testing is used to reproduce customer-found defects. This enables the quality assurance engineer to duplicate the steps and provide detailed information to the developer about browser related issues or data issues that might not be found by automation.
  6. Often, in an agile environment, things are changing, and features are being enhanced. This requires constant rewrites to the automation scripts and creates additional tasks for the team. Manual testing does not need increased work to be able to adapt to any new changes.

Automation testing is a benefit to any company, but manual testing should never be replaced. Manual testing is always going to find things automation won’t find.