General Inverview Questions

Responsibilities of the Test Lead ?

Role of QA Lead includes-

1. Manage project from initiation through closure
2. Test planning
3. Obtain customer acceptance of the deliverables
4. Approve intermediate deliverables and patch releases to the client
5. Submit effort inputs for billing
6. Issue Management
7. Mentoring, coaching and off-shore team management
8. Submit reports for weekly status to the test coordinators
9. Participating in weekly review meetings
10. Publish KPIs for all testing projects on a weekly basis
11. Resource mobilization for projects

What people skills should a Test Lead have?

1. Effective and clear communication
2. Should build good relationship with team members
3. Good listening skills and emotional intelligence
4. Motivate team members
5. Resolve conflicts and ethical issues.

What makes a good test lead?

I think a good test lead is someone adaptable, detail-oriented and a good problem solver. 

1. Adaptability can help them respond to new project requirements or navigate client requests.
2. Attention to detail makes it easier to spot errors and ensure quality delivery.
3. Problem-solving can help them respond to QA concerns quickly and effectively, making it possible to complete their assignments within the estimated time frame.

What will be your criteria for hiring team members?

The criteria for hiring team members are

1. His/her technical strength is as per project requirements.
2. His/her attitude towards the profile he will be hiring for.
3. will he/she be a good fit with the rest of the team members

What is PDCA model?

The PDCA model stands for

1. Plan: Identify improvements and set targets
2. Do: Implement improvements
3. Check: Check result of improvements
4. Act: Learn from results

It is a Test Process Improvement (TPI) method.

PDCA is a TPI method that stands for plan, do, correct and act. 

1. In the first stage, testers need to plan improvements and incorporate client requests into their set targets. 
2. Then, in Do phase, they have to execute their plan, focusing on improving implementation and timeline management. 
3. In the correct phase, testers must determine the effectiveness of their improvements by checking results and evaluating the success of their efforts. 
4. Finally, in the act stage, testers learn from their results so they can improve their future processes and implementation strategies as they repeat the cycle.

What are some key challenges in a Testing Project ?

Key challenges of software testing include

1. Testing phase us usually under a time constraint
2. Understanding the requirements can sometimes be a challenge
3. Application should be stable enough to be tested
4. Setting priorities for testing
5. Lack of skilled testers
6. Regression Testing
7. Frequent Requirements changing
8. Lack of tools, resource, and training

 What are some risks you might encounter when testing a project?

In testing, we often encounter risks that can affect our timelines, resources, strategies and understanding of project requirements. These can create concerns, and it's important to consider them at the beginning of a project. Timeline risks can affect the project's schedule, so it's always important to be aware of potential delays. Resource risks might come from team concerns like the team's skills, experience or individual workload capabilities. Strategy risks can affect budgets and client relationships. And project requirement risks might include challenges concerning the project's scope or desired outcomes.

How do you ensure quality estimations on tests?

To ensure quality test estimations, I usually try to consider every potential factor. This includes resources, team capabilities and potential risks. I almost always give myself some extra time, that way I can exceed expectations and represent the company well to clients. Now that I'm more experienced, I have an adept sense of how long certain processes take. By considering team capabilities and needs, and always staying flexible and receptive to new information, I can ensure my estimates remain as accurate as possible.

Have you ever disagreed with a team member? How did you resolve the disagreement?

When I first started at my last company, I had a coworker who routinely approved defective work, then blamed me for the errors if the client noticed. I presented a new testing strategy to my manager, so both of our work would undergo one more approval step before we delivered it to the client. By implementing the final QA step, we could catch the errors and document their source. This helped me correct the placement of blame and, as an added benefit, it improved our ability to deliver quality work to our clients.

How would you select a Testing tool for your project ?

1. Identify features required in an automation testing tool as per the project needs
2. Evaluate commercial and noncommercial tools that meet the requirements
3. Estimate cost and benefit of the tool. Cost could include licenses and training.
4. Make the final decision in consultation with team members.

What is a Test Plan?

The Test Plan is a document describing the activities and the testing scope. It is the basic requirement for testing any software product.

What are types of the test plan?

There are three main types of Test Plan

1. Master Test Plan
2. Testing level specific Test Plan
3. Testing type specific test plans

What is the Requirement Traceability Matrix ?

Requirement Traceability Matrix is linking of requirement documents to test cases. It is used for the following reason

• To ensure that all the application requirements are tested in the verification process
• To check Test Coverage

TBox Start Program

We can run any program via this module, suppose i want to start the firefox in private mode along with some additional properties. These properties can be defined in the arguments attribute. 

The official definition says this module can open an application or an executable file. Environment variables can also be used to open any applicatin.

NOTE - You cannot run or execute any program or process out of Windows OS

This Module allows you to open an application or an executable file stored in a Microsoft Windows® file system.

Path -- 

The folder TBox Automation Tools->Process Operations in the Standard subset contains the Module TBox Start Program.

TBox Start Program has the following ModuleAttributes:

Path -- Path to the application that you want to open. You can also use environment variables.This entry is mandatory.

Directory --  Specify a working directory for the program. By default, Tricentis Tosca uses the home directory of the registered user: C:\Documents and Settings\<user name>.

Arguments -- If you want to start the application via arguments, specify arguments. By default, Tosca Commander uses ActionMode Select.

Arguments->Argument -- Define an argument. You can specify several arguments, one per sub-ModuleAttribute.

WaitforExit -- You can instruct Tricentis Tosca to wait until the application has been exited. To do so, set the value True and use ActionMode Select.

Optionally, specify StandardOutputFile, TimeoutForExit, and ExitCode.

WaitforExit->StandardOutputFile -- If you want Tricentis Tosca to create a log, specify the path and name of the log file.The log includes standard output (stdout) and standard error (stderr).

WaitforExit->TimeoutForExit -- Specify the maximum time in seconds that Tricentis Tosca should wait before exiting the application.

WaitforExit->ExitCode -- Verify your application's exit code. To do so, enter the code into the Value column and use ActionMode Verify

Run as -- Define which domain or local user credentials Tricentis Tosca should use to open the application. By default, Tosca Commander chooses ActionMode Select.

Run as->Username -- User Principal Name (UPN) format of the user name that should open the application.For example: jdoe@company.com.

Run as->Password -  If needed, specify the password of the user.

Opening the application Notepad.exe, which is located at C:\Windows.

Note - Credentional are optional

Opening the  file Test01.xml, which is located at D:\, with the program notepad.exe, which is located at C:\Windows. The defined working directory is C:\Temp.

Opening the www.tricentis.com in Internet Explorer  private mode

How to clear your Temporary Internet Cache

 To clear the temporary Internet files from your system, you can use TBox Start Program with following values:

TDM, TDS and TCD

TDM

The Test data Management(TDM) components are used to managing the test data which are required for test execution. The data are stored same as shared database repository which is used to create the workspace, through the TDM which will be assigned to test cases during the execution. In case of SQLite, the separate instance of database is required for TDM. It enables you to view all records in your test data repositories and modify or delete selected ones. It is automatically installed as part of the Test Data Service component in the Tricentis Tosca Server setup. TDM combines Test Data Service (TDS) and test data management to allow teams to design, locate, manage, and provide test data, even in complex and hard-to-manage scenarios. The TDM component is available with the standard Tosca installation. 

TDS

TDS stands for Test Data Service, which is used for test data management in Tosca. Using TDS, we can store the dynamic test data in a shared location which is easy to read/ update by the test case. As the data stored in a shared location, it is useful to share the same dynamic data across multiple test cases. Also, we can update it without opening Tosca as it’s treated as a separate component.

TCD

In Tosca TestCase-Design section is an AddIn that enables to isolate the test data from the technical sections of test cases. So, the data and test cases are kept separately. The Tosca Test Case Design section has the capability to break our test cases into a logical structure. It is also help us to plan and design the testcases in a efficient and structured way to reduce the development and maintenance efforts.

Objects:

• Folder – The test case design folder is used to group the test sheets or classes in a logical way.
• TestSheet – TestSheet is a list of data for all possible combinations of Tosca test cases. Each data set represents one unique test case.
• Attribute – It’s referred to as the different data parameters corresponding to each application field.
• Attribute(not business-relevant) – It’s used for comment or description purposes.
• Attribute(result) – It’s used for result purposes.
• Instances Collection – It holds the Instances i.e., all possible values available for particular attribute.
• Instances – This is the value of each attribute/parameter. It can be created TestSheets, Attributes, or Class level. Instances of Testsheets are basically a test case name.
• Class – This is similar to testsheets, but it’s used for the reusable purpose. All the common data are stored here, which can be reused in multiple testsheets.
• Class reference – It’s acting as a link of Classes from Testsheets. We can create it with the drag-drop method.

Test Case Design section is performing the below activities – 

1. Create the testsheets, which is a combination of all possible test cases for any particular scenario or template. Basically, testsheets are holding the data for different combinations.
2. The concept of class in test case design approach, helps to reuse the common data across the test cases which reduce the efforts of data management.
3. With the help of instances, we can create the specific data for TestSheets, TCD Attributes, or TCD classes.
4. Create TestCase Templates and assign the Testsheets.
5. We need to instantiate or re-instantiate Templates to generate the instance test cases as per the testsheets.
6. Manage test data in testsheets and execute the instance test cases

Object hierarchies in Test Case Design:

1. A TestSheet may have Attributes, Instances, TestSteps, and class references.
2. A class may be the combinations of class Attributes and Instances.
3. Again, an Attribute can keeps further Attributes and Instances.
4. A Step can keeps more Steps and Attributes.

What is the purpose of ActionMode Constraint

The ActionMode value “Constraint” is used to search for the specified values. 

For example – we can search a specific column value in a table with the help of “Constraint” easily.

How to launch more than one browser in Tricentis TOSCA?

Launching multiple browsers is not possible in TOSCA. But the user can achieve cross-browser execution. 

To perform cross-browser execution, users need to follow the below steps: 

1. A Test Configuration Parameter “Browser” should be designed either at TestCase or its Parent Levels.
2. Users can choose the value as InternetExplorer, Firefox, Chrome.
3. The individual browsers will trigger executions. 

Test Mandates in Tosca

The Execution section contains the following important items:

1. ExecutionLists
2. BusinessExecutionLists
3. ExploratoryTesting
4. TestMandates
5. Configurations(Multiuser environment)
6. TestEvents (multiuser environment)

Configurations and TestEvents are available in multiuser environments and are used for running ExecutionLists with distributed execution.

Test Mandates in Tosca

The test mandate allows to execute different parts of execution list parallelly with out locking the main execution list.

In a multiuser workspace, several testers should be able to execute the same tests simultaneously. They should also be able to execute these tests independently, so as to not overwrite other testers' results. Here each tester creates a TestMandate in their own workspace and links it to a test object:

• ExecutionList folders

• ExecutionLists

• ExecutionEntry folders

• ExecutionEntries

Once testers have done so, they execute the TestMandate and not the original test object. Tosca Commander then writes the results to the ActualLog of the TestMandate and the ActualLog of the test object.

The ActualLog of the test object consolidates the results of all linked TestMandates once testers checkin their workspace.

NOTE - Once you have created a TestMandate and linked it to a test object, you no longer have to checkout the test object to execute it.

Creating TestMandates

To create a TestMandate, right-click an  ExecutionLists folder and select Create TestMandate from the mini toolbar.

To delete a TestMandate, select the respective TestMandate and press the Delete key.

Link test objects to a TestMandate

To link our test object to a TestMandate, drag and drop the respective test object onto theTestMandate.

Tosca Commander performs the following actions:

• It marks the ActualLog of the test object with a blue arrow to indicate a linked TestMandate.

• It creates a copy of the test object in the TestMandate.

When we execute our TestMandate, the ExecutionLogs of the linked test object also show the blue arrow:

We can jump from an ExecutionEntry of the test object to the corresponding ExecutionEntry of the TestMandate.

To do so, right-click the test object ExecutionEntry and select Jump to TestMandateEntry from the context menu.

Configure the results view

If you have a folder that contains several TestMandates, you can configure Tosca Commander to display the accumulated results of all TestMandates on the parent folder level.

To do so, set the TestMandate property IncludeForAccumulation to True for all TestMandates whose results you want to include.

Delete the link between test object and TestMandate

If we no longer want to transfer results to the ActualLog of the test object, but you want to keep the TestMandate, you can disable the link between the two.

To delete the link between TestMandate and test object, right-click the ActualLog of the test object and select Clear AutoMerge-List from the context menu.

CleanUp Scenarios

CleanUp Scenarios are important every time to keep the test environment clean before each test execution. If a test scenario fails, the collection of recovery scenario will trigger if created any. If the recovery scenario fails. The clean-up scenarios will be triggered, and it can include post execution steps like close the applications to make the next test case executable.

 CleanUp Scenarios are alternate scenarios that Tricentis Tosca executes if  Recovery fails, i.e. if the TestSteps in your Recovery Scenarios don't return a positive result.

The goal of Recovery is to fix failing TestStepValues or TestSteps by employing "corrective" TestSteps. CleanUp Scenarios, on the other hand, are geared towards resetting the environment so that the next TestStep has a chance of being successful.

For instance, if your Recovery Scenario closes a browser tab and reopens it, a possible CleanUp Scenario could be:

• log out of site

• close and reopen browser

• navigate to the page

• log in

Create a CleanUp Scenario

1. Right-click a *** Recovery Scenarios *** folder and select Create CleanUp Scenario(brush icon) from the mini toolbar.

2. Determine what Tricentis Tosca should do if Recovery fails. To do so, add TestSteps to your CleanUp Scenario. You can either use existing TestSteps, or create them via (TestCases, Folders within TestCases, TestSteps, TestStepValues, Reusable TestStepBlocks, Recovery Scenarios ).

CleanUp Scenarios during execution:  

You create your CleanUp Scenarios in the TestCases section. Tricentis Tosca automatically applies them during execution. A CleanUp Scenario is successful if all TestSteps therein return a positive result.

If a *** Recovery Scenarios *** folder contains more than  one CleanUp Scenario, Tricentis Tosca processes them top-to-bottom.

If none are successful, Tricentis Tosca processes the CleanUp Scenarios on the next-higher level. If there are none, or if none are successful, Tricentis Tosca moves on to the next-higher level until there are no more levels left.

Recovery Scenarios during execution

Create your Recovery Scenarios in the TestCases section. Tricentis Tosca automatically applies them during execution. A Recovery Scenario is successful if all TestSteps therein return a positive result.

During execution, Tricentis Tosca looks for applicable scenarios on the closest level.

• If there are several applicable scenarios, Tricentis Tosca executes them top-to-bottom.

• If there is no applicable scenario, or if none are successful, Tricentis Tosca looks for applicable scenarios on the next-higher level. If there are none, or if none are successful, Tricentis Tosca moves on to the next-higher level until there are no more levels left.

• Then Tricentis Tosca moves back to the closest level and looks for the next-higher Recovery Scenario.

  For instance, if none of the TestStepValue Recovery Scenarios were successful, Tricentis Tosca moves on to TestStep Recovery Scenarios. First on the closest level, then on the next-higher level, etc.

This process continues until a Recovery Scenario is successful, or until there are no more Recovery Scenarios left.

If one of the Recovery Scenarios is successful, Tricentis Tosca resumes execution from the point specified in the Recovery Scenario property RetryLevel.

If no Recovery Scenario is successful, Tricentis Tosca reports the TestCase as failed.

Example

In the TestCase folder below, you have defined Recovery Scenarios on two levels:

• The Sub-folder level contains three scenarios for failed TestCases, one scenario for failed TestSteps, and one scenario for failed TestStepValues.

• The TestCase level contains three scenarios for failed TestSteps and three scenarios for failed TestStepValues.

If a TestStepValue fails, Tricentis Tosca performs the following actions:

• It searches the closest level, i.e. the TestCase level, for TestStepValue Recovery Scenarios and executes them: Recovery Scenario A for TestStepValues, Recovery Scenario B for TestStepValues, and Recovery Scenario C for TestStepValues.

• These scenarios are unsuccessful, so Tricentis Tosca moves on to the next-higher level, i.e. the Sub-folder level. On this level, it executes Recovery Scenario D for TestStepValues.

• This scenario is unsuccessful, so Tricentis Tosca moves back down to the TestCase level and on to the next-higher Recovery Scenarios, i.e. TestStep Recovery Scenarios.

• Tricentis Tosca executes Recovery Scenario (1) for TestSteps, Recovery Scenario (2) for TestSteps, and Recovery Scenario (3) for TestSteps.

• These scenarios are unsuccessful, so Tricentis Tosca moves on to the Sub-folder level. On this level, it executes Recovery Scenario (4) for TestSteps.

• This scenario is unsuccessful, so Tricentis Tosca moves on to the next-higher Recovery Scenarios, i.e. TestCase Recovery Scenarios.

• It executes Recovery Scenario (I) for TestCases, Recovery Scenario (II) for TestCases, and Recovery Scenario (III) for TestCases on the Sub-folder level.

If one of the TestCase Recovery Scenarios is successful, Tricentis Tosca re-executes the TestCase from the beginning.

If none of the TestCase Recovery Scenarios are successful, Tricentis Tosca reports the TestCase as failed.

Recovery Scenario

A Recovery Scenario is a collection of TestSteps that Tricentis Tosca executes if particular tests fail.

Goal - The goal of Recovery is to fix failing test step values or test steps by employing “corrective” test steps.

Example - In the application, if search keyword is not provided as part of input data and when search button is clicked. A chrome alert pop-up appears with the message “Please enter some search keyword". 

Instead of using an “If statement” in the test case to handle the chrome alert pop up. A recover scenario can be created. The moment actual test case fails due to the pop up the recover scenario will be automatically triggered and once the recovery scenario returns a positive result status. The execution would continue with the test case. If the pop up does not appear and the test case doesn’t fail the recovery scenario will not be triggered.

Note: – Recovery scenario will apply only if the execution of the test case is done from the execution folder section. It will not apply if the test case is run in the scratch book.

Retry levels for the recovery scenario -- 

It is also important to specify the retry levels for the recovery scenario. Tosca supports the following three retry levels.

• Retry Level – Test case - The recovery scenario will jump in to handle the pop up and returns the positive result. The retry of the test case will be from its first test step “OpenUrl” as the retry level value test case is selected.
• Retry Level – Test step  - The recovery scenario will jump in to handle the pop up and returns the positive result. The retry will be from the failed test step "SearchButton". Note: It will not re-trigger from the "'OpenUrl" as the retry level selected is test step.
• Retry Level – Test step value - If the retry level is set to test step value. In this case, if the test step value “Booksearch” fails due to the Chrome alert pop up.  The recovery scenario will handle the pop up and the retry will continue from the failed test step value “Booksearch".

Prerequisite - The following settings must be updated.

• In project -> settings -> TBox-> Recover

We can create Recovery Scenarios for one of the following objects:

• TestCase folders

• TestCases

Creating Recovery Scenarios

---------------------------------------

1. Right-click the object and select Create Recovery Scenario Collection from the mini toolbar.

   The Recovery Scenario Collection applies to the following levels:

• the object for which you have created it

• all sub-items therein

2. Right-click the newly created folder *** Recovery Scenarios *** and select  Create Recovery Scenario from the mini toolbar. You can create several Recovery Scenarios in one folder.

2. Determine what Tricentis Tosca should do if tests fail. To do so, add TestSteps to your Recovery Scenario. You can either use existing TestSteps, or you can create them via Fuzzy Search.

Fuzzy Search. -  Tosca Fuzzy Search lets you search for Modules, XModules, and Reusable TestStepBlocks to create new TestSteps.

To launch the Fuzzy Search, right-click an object and select Search and Add TestStep from the context menu, or select the object and press Ctrl + T.

The Fuzzy Search searches all Module, XModule, and Reusable TestStepBlock names for the search term and for parts of it. Characters that match the search term are highlighted. The order of the search results depends on how many search term characters match the entry.

4. For instance, the TestStep Home - Select "Automobile" steers a control on a website. A possible Recovery Scenario could be to close and reopen the browser tab.

4. Specify when Tricentis Tosca should apply the scenario. Enter one of the following values for the Recovery Scenario property RetryLevel:

   • TestStepValue: apply this Recovery Scenario if a TestStepValue fails

   • TestStep: apply this Recovery Scenario if a TestStep fails

   • TestCase: apply this Recovery Scenario if the TestCase fails

   The RetryLevel property also defines the point from which Tricentis Tosca resumes execution after Recovery.

   For instance, if you specify the value TestCase and a TestStepValue fails, Tricentis Tosca performs all TestCase Recovery Scenarios. After Recovery, Tricentis Tosca re-executes the entire TestCase from scratch.

   If you specify TestStepValue and a TestStepValue fails, Tricentis Tosca performs all TestStepValue Recovery Scenarios. After Recovery, Tricentis Tosca resumes execution at the TestStepValue in question and continues from there.

NOTE -- If you created your TestStep from an XModule whose property InterfaceType is NonGUI, you can only recover on the TestCase level.