There is no such statement as ‘I am now prepared for the interview‘. When facing a Testing interview no matter how many interview questions and answers you have gone through – there is always more to read 🙂 Continuing on our Interview questions series, let’s see some more interesting FAQs …
In simple terms – “Testing is context driven”. It’s good if you already know the ‘context’ to be tested 🙂 anyone can ‘Check’ but not ‘Test’. The difference is same as a novice driver and an experienced one. Novice driver focus on just driving with the fear of road whereas experienced driver can gauge the air pressure, engine sound, music connections, rear-view, appropriate acceleration in traffic, etc.
- Suggestive: The job will be done anyway, but a domain expert can be suggestive. He / She can provide feedback, suggest for improvements, and be an active participant in a lot of decision-making meetings.
- Prioritize: A Domain expert can help prioritize the test areas most relevant to the application.
- Requirements: Quick understanding of requirements and thorough analysis.
- Effective: Better simulate the business flows and end-user actions, i.e. effective test scripts.
- Roles: Testers with domain expertise can play multiple roles like requirement analysis, client interaction, pitching for new business, training, etc.
- Defect Triage: Knowing how the application will be used and how it is expected to perform, will tell QA whether a given defect is trivial, significant, or critical.
- Client Relationship: Helps in building Client relationship since domain experts are likely to use business language while reporting & communication.
How will you test an e-commerce website if you don’t know about portfolio management, order management, payment gateways, user management, etc.? How will you test a banking application if you don’t know how a payment is processed end-to-end? When testing a healthcare product, it’s good to know about terms like provider, inpatient, outpatient, and anything involving medicine will require the user to be aware of ICD’s (International Classification of Diseases). Why do you think UAT team members are from the business team who have a thorough domain knowledge?
A Software requirements specification (SRS) or Functional Specification Document (FSD) is a description of features and functionalities of a software system to be developed. It lays out functional and non-functional requirements – instructions describing what functions the software is supposed to provide, what characteristics the software is supposed to have, and what goals the software is supposed to meet or to enable users to meet.
Use Case is one of the methodology to define system requirements / behavior. A use case defines a goal-oriented set of interactions (list of actions or event steps) between external actors and the system under consideration, i.e. how a user uses a system to accomplish a particular goal. Actors are parties outside the system that interact with the system. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal.
User Story is a tool used in Agile Software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
- Format: As a <role or user type>, I want <feature or goal> so that <some reason>
- Example – As an administrator, I want to approve comments before they are posted so that I can make sure they are appropriate.
Question-105. Is it important to learn automation testing for career growth?
The first & foremost! You need to understand that pure ‘Manual Testing’ is dead. If not dead, it won’t take you anywhere after 3 years of work experience. Currently the majority (& we mean literally) of jobs require ‘Automation’ as a must-have, even at managerial levels. Now-a-days Automation is the undeclared king of QA services and remains the best way to speed release cycles, quickly test fixes, and rapidly evolve code in order to catch defects and not delay deployment. The transition happened in the past years & 2017 will see a lot going this way. Mobile apps test automation has also grown in demand and this trend will likely keep gaining speed. So gear up guys & girls – don’t just sit satisfied with your ‘Manual Testing’ experience. Try & learn tools like Selenium, UFT, Load Runner, JMeter, SOAP UI, Appium, etc. via corporate trainings, online repositories, YouTube videos, etc.
Question-106. Any idea about SMAC testing?
SMAC stands for Social + Mobile + Analytics + Cloud. The emergence of SMAC has given a new outlook to application performance. And businesses are realizing the need to upgrade their IT strategy in order to meet the changed requirements of modern users. SMAC testing goes beyond individual testing methods for social, mobile, big data and cloud testing. It requires successfully combining different testing methods and techniques to address social, mobile, analytics and cloud applications individually as well as synergistically. Responsive testing service providers have developed new approaches, strategies and application testing folds to make applications market ready in the era of SMAC.
Kanban is a Japanese term for “signboard” or “Billboard”! For one, Kanban is NOT an Agile tool, framework or methodology – Kanban Agile is a popular workflow method for managing knowledge work which balances demands for work with the available capacity for new work. Work items are visualized to give team members a view of progress, from to-do to customer delivery. Agile software development teams today are able to leverage Kanban by matching the amount of work in progress (WIP) to the team’s capacity. Team members “pull” work as capacity permits, rather than work being “pushed” into the process. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.
A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end. Agile teams use visualization with a Kanban board, allowing a better understanding of work and workflow. It advises limiting work in progress, which reduces waste from multitasking and context switching, exposes operational problems and stimulates collaboration to improve the system. Kanban has six general practices,
- Visualization: Seeing the work in context
- Limiting work in progress: Don’t push the work. For every column (state) on your Kanban board you should define a “Work In Progress” – Limit (WIP Limit). If a state reaches its pre-defined WIP limit, no new work can enter that state. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents over-work and reveals bottlenecks dynamically so that you can address them before they get out of hand.
- Flow management: when something is finished, the next highest thing from the backlog is pulled
- Making Management policies explicit: keeping and amplifying useful changes, reversing and dampening the ineffective
- Feedback loops: learning from the retrospective
- Collaborative or experimental evolution: promote continuous collaboration and encourage active, ongoing learning and improvement
Simply stated – “For every element identification, tell Selenium to wait for a certain amount of time before throwing a “No Such Element Exception”. Please note that once implicit wait is set, it will be applicable until the WebDriver instance is destroyed, i.e. for every element identification. Implicit wait accepts 2 parameters,
- Time as an integer value
- Time measurement in terms of SECONDS, MINUTES, MILISECOND, MICROSECONDS, NANOSECONDS, DAYS, HOURS, etc.
WebDriver tries to locate the element >> say it does not find it >> it doesn’t try to identify the element again, instead it waits till the specified time (10 secs here) >> Before the end of 10 secs, it checks once again if element is present >> If not it throws the exception.
The explicit wait is an intelligent wait, i.e. used to tell the Web Driver to wait for certain conditions (Expected Conditions like element to be visible, clickable, etc.) or the maximum time before throwing an “ElementNotVisibleException” exception. Explicit wait gives better options than that of an implicit wait. WebDriver introduces classes like WebDriverWait and ExpectedConditions to enforce Explicit waits into the test scripts.
Once we declare explicit wait we can use “ExpectedCondtions” or we can configure how frequently we want to check the condition using Fluent Wait. Both Selenium WebDriver Wait commands – WebDriverWait and FluentWait are classes and implements the Wait interface.