Team Lead Interview Questions

Q #1   How you distribute your work ?
Ans :

• 60 % Testing [ which includes manual as well as automation ]
• 10%  coordination
• 20% reviews
• 10%  communication to dev /Release/delivery management

Q #2 Whats your main roles & responsibility

Lead the testing team

Requirement gathering & Estimate for testing projects.

Test leaders tend to be involved in the planning, monitoring, and control of the testing activities and tasks.

Deploying and managing the appropriate testing framework to meet the testing mandate.

Plan and organize the knowledge transfer to the Software Test Engineers and self

Communication to all stake holders

Keeping official records of team activities

Review of test plans and test cases.

Q #3 Whats are the steps you follow from start?

How to follow this software testing course series?

Step#1: Introduction and SRS Walk-through 

Step #2: SRS review and test scenario preparation.

Step #3: Test Plan – complete process of creating a test plan from the scratch.

Step #4: Test Cases – complete test cases writing process with some sample test cases.  We may use any test management tool or spreadsheet for writing test cases.

Step #5: Application walkthrough and test execution – how to execute test cases and record the test results.

Steps #6: Defect reporting

Step #7: Defect verification, regressing testing process

Steps #8: QA Sign-off

Q #4. How do you resolve team member issues?

Informally, first. Ask them out for coffee individually and listen to each one’s side of the issue. If it’s a simple misunderstanding, ask them to resolve it within themselves mutually. If need be, call for a meeting and talk to them without letting things escalate. Tolerate until things do not impact work. When they start to cascade and effect project, warn and if necessary, escalate to human resources 

Q #5 What are test objectives?

Testing Objectives are

1. To find Uncovered Errors based on Requirement.

2. Ensure to make software more reliable and easily maintainable.

3. 'Quality is Ensured';

Also The test Objectives provide a prioritized list of verification or validation objectives for the project

Q #6 What a Test Plan consists of?

• Test Plan Identifier
• Introduction
• Test Items
• Scope
• Pass/Fail Criteria
• Suspension / Resumption criteria
• Test deliverable
• Test Tasks
• Environmental needs
• Training required
• Schedule
• Risks
• Approvals

Q #7. How do you provide feedback to a team member who isn’t doing very well?

First and foremost, set guidelines for all team members of what is expected of them and in what time frame. In short, define the parameters of success. For example, if it’s a new team member, let them know what you expect from them:

• What module they will be working on?
• Time lines
• Deliverables
• Formats of deliverables
• Updating/managing work on tools (such as QC, Rally, JIRA, etc.)
• Timesheets and so on…

Set a period of time after which to evaluate, such as 30 days or so. Once done, collect statistics-

• How many times has the timesheet not been filled?
• Negative review comments received on work
• Deliverable not been done on time…etc

Based on the statistics, if the performance isn’t satisfactory, follow the below steps:

• Discuss the results with the team member
• Seek approval or confirmation that they understand what hasn’t been working
• Set up a new plan, new attributes of success and a new performance review timeline
• Think of measures to fix it or provide help

Q #8. How do you handle induction of new team members? OR What do you do to train new team members?

• Set aside time for knowledge transfer and orientation
• Share all the information regarding who to get in touch with in case of questions regarding different areas of the system and their email addresses or physical introductions (For example: BA, networking team, tool admins, help desk, Dev team etc.)
• Provide tool accesses
• Share documentation, templates, previous artifacts, test plans, test cases, etc
• Share the expectations in terms of their performance (refer to the answer to questions number: 8)
• When possible, assign a team member to work with them closely for a brief amount of time
• Keep the channels of communication open to stay in touch and understand their progress

Q #9. How much is your involvement in reviews of test cases, defects and status reports?

It is very easy to say that you check each and every document that is ever created and we might feel really good about saying that we do it all. However, that might not always be seen as a positive thing. Team leads have to establish process so that teams run efficiently by them, therefore make sure that you make your teams “self-sustaining” with minimum hand-holding.

This would be my answer:

I am involved in the test case reviews just as any other team member is. We do periodic peer reviews. I do not review every one’s work; however we review each other’s work. There are very strict processes established before this process begins so all of us can share work and make sure this goes on smoothly.

All the defects are re-checked by me to make sure they are valid, not duplicates and complete in their description. This is more of a task in the beginning of the test cycles, however as we get more into testing, this step reduces as the teams are more comfortable with the process and can do this effectively. All status reports are consolidated and sent by me as this is a team lead’s job as per the company’s process.

Q #10. How do you analyze risks and overcome them?

Risk analysis is a mandatory activity for every test plan stage. Later on, if there is not enough time or any other unfavorable situations arise, we do another round of risk analysis.

Smoke Testing Vs. Sanity Testing

     

Smoke Testing 

Vs. 

Sanity Testing

Example

a) Taking a test ride to test the basic features (functionalities) of a Car be compared to “Smoke Testing” a product. Test Drive helps in determining if the basic features of the bike were stable and acceptable. In a typical testing environment, when a build is received for testing, a smoke test is run to determine if the build is stable and can be considered for further testing. Testers usually do a Smoke Testing before accepting the build for further testing. The tester "touches" all areas of the application without getting too deep into the functionality.

b) Testing the Car performance in detail after bringing it home can be compared to “Sanity Testing” a product. Testing those features in detail was not possible in the showroom or while taking test ride. In a typical testing environment, when a new build is received with minor modifications, instead of running a thorough regression test suite, a sanity test is performed so as to determine that the build has actually fixed the issues and no further issue has been introduced by the fixes. Sanity testing is generally a subset of regression testing and a group of test cases are executed that are related with the changes made to the product.

Security Testing using Burp Suite

                  Security Testing using Burp Suite

Why Security Testing Required ?

Top Attacks

• SQL Injection
• Cross Site Scripting
• Authentication

Authentication

•Burp Suite is a Java application that can be used to penetrate web applications

Download : https://portswigger.net/burp/download.html

Also You need to add SwitchySharp chrome-extension  to handle the proxies

Test Plan vs Test Strategy vs Test Approach

                Test Plan vs Test Strategy vs Test Approach 

                                                                Test Plan

                                                                       |

                                                              Test Strategy

                                                                       |

                                                             Test Approach

    The above flow diagram illustrates that First Test Plan is created which includes test strategy &

test Strategy includes the test Approach

Theory Says – 

Test Plan - “A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort” 
The purpose of the Master Test Plan, as stated by the IEEE Std 829 is to provide an overall test planning and test management document for multiple levels of test (either within one project or across multiple projects). 
You can see the IEEE standard test plan is here. 

Test Strategy – Test Strategy or Test Approach is a set of guide lines that describes test design. Test strategy says - How testing is going to be performed? What will be the test architecture? 
Test Strategy can be at two levels – Company/Organization Level and Project Level. For e,g, If company is product based, then there can be a general test strategy for testing their software products. Same strategy can be implemented (with/without  some modifications) at project level whenever a new project comes. 
Might be these are OK for beginners, but actually this is not enough. 

Test approach -- "It's the way how do you do your testing." Test Approach is created by the individual tester/TestLead according to the module or application means his own views or approaches for that Module.

Example: Test plan gives the information of who is going to test at what time. For example: Module 1 is going to be tested by “X tester”. If tester Y replaces X for some reason, the test plan has to be updated.

On the contrary, test strategy is going to have details like – “Individual modules are to be tested by test team members & there should be more than 85% automation for each module“ In this case, it does not matter who is testing it- so it’s generic and the change in the team member does not have to be updated, keeping it static.

& test approach will be decided the by the test Lead/tester that which tool will be used for automation . Ex. for UI whether to use selenium or QTP... for API whether to use the restAssuerd or SOAPUI

From Testing School Basics : Test Plan

Test Plan

Test plan is in high demand. Ya it should be! Test plan reflects your entire project testing schedule and approach. This article is in response to those who have demanded sample test plan.

Making Test Plan has multiple benefits

• Test Plan helps us determine the effort needed to validate the quality of the application  under test
• Help people outside the test team such as developers, business managers, customers understand the details of testing.
• Test Plan guides our thinking. It is like a rule book, which needs to be followed.
• Important aspects like test estimation, test scope, test strategy are documented in Test Plan, so it can be reviewed by Management Team and re-used for other projects.

As per IEEE 829  test plan Consists of 

Test Plan Identifiers:

S.No.	Parameter	Description
1.	Test plan identifier	Unique identifying reference.
2.	Introduction	A brief introduction about the project and to the document.
3.	Test items	A test item is a software item that is the application under test.
4.	Features to be tested	A feature that needs to tested on the testware.
5.	Features not to be tested	Identify the features and the reasons for not including as part of testing.
6.	Approach	Details about the overall approach to testing.
7.	Item pass/fail criteria	Documented whether a software item has passed or failed its test.
8.	Test deliverables	The deliverables that are delivered as part of the testing process,such as test plans, test specifications and test summary reports.
9.	Testing tasks	All tasks for planning and executing the testing.
10.	Environmental needs	Defining the environmental requirements such as hardware, software, OS, network configurations, tools required.
11.	Responsibilities	Lists the roles and responsibilities of the team members.
12.	Staffing and training needs	Captures the actual staffing requirements and any specific skills and training requirements.
13.	Schedule	States the important project delivery dates and key milestones.
14.	Risks and Mitigation	High-level project risks and assumptions and a mitigating plan for each identified risk.
15.	Approvals	Captures all approvers of the document, their titles and the sign off date.

Decision table vs State transition

Decision table vs State transition

State Transition:

State or behavior of a system change upon interaction with other system/object, hence testing this transition between states of a system or objects is State Transition.

Ex :
Remember the state transition diagrams or sequence diagrams of UML.These two diagrams which are drafted along the HLD are to be referred to identify the objects, theirs states and transitions.
ATM money withdrawal :
User (Object) is validated for authorization and authentication. Change in state i.e. (inactive user is been activated).
check whether the user is activated or not upon valid and invalid A & A.
Advantages:
Very easy way to draft the test cases.
Transition issues which influence the business can be identified.

Disadvantages:
limited impact on business rules and test conditions.
Requires UML to be included in design phase i.e. in HLD.

Decision Tables:

Drafting a table which highlights the conditions between two objects where rows are denoted by one object and columns by another.

Ex:
Z = X + Y, X is cost price of a certain product, Y is the profit. Z is the selling price
Decision Table will be
Test Condition: sum of CP and Profit shall result as SP.
Row = X, Column = Y. both positive and negative permutations are to be considered.
Thus decision table is to be drafted.

Advantages:
In order to optimize the number of test cases required to ensure optimal test coverage these two design techniques are helpful.
Cover both positive and negative aspects of the test conditions.
Objects are tested, hence functionality i.e. behavior can be defect free.
Disadvantages:
Requires UML to be included in design phase i.e. in HLD.
Is not easy to implement initially.

Agile Test Design techniques

When you start your project, in the initial phase only you need to decide your Test Design technique
Based on my experience , I categorized them as

1) Dynamic Test Design techniques

•   Structured Based (White box)
•   Specification Based (Black box) 
•   Experience Based ( It depends how much experience you have & how well you can use that) 

2) Static Test Design techniques

• Informal Reviews
• Walkthroughs
• Static Analysis
• Technical Reviews
• Inspection