BookOfTesting By Shailendra Trivedi

GivenWhenThen in BDD Given-When-Then is a style of representing tests - or as its advocates would say - specifying a system's behavior using SpecificationByExample. It's an approach developed by  Dan North  and Chris Matts as part of Behavior-Driven Development (BDD).  [1]  It appears as a structuring approach for many testing frameworks such as Cucumber. You can also look at it as a reformulation of the Four-Phase Test pattern. The essential idea is to break down writing a scenario (or test) into three sections: The  given  part describes the state of the world before you begin the behavior you're specifying in this scenario. You can think of it as the pre-conditions to the test. The  when  section is that behavior that you're specifying. Finally the  then  section describes the changes you expect due to the specified behavior. Feature: User trades stocks Scenario: User requests a sell...

Very specific scenario: Scenario: Error when the password and confirm password do not match Given I am on User Registration From When I fill the Form fields as follow: | Field | Value | | Name | myusrname| | Password| password123| |Confirm Password | passnotmatch234| And I click on the button “Save” Then the error message should be “Password and Confirm password do not match” End-to-end scenario: Scenario: New user with unique name can be registered in the system Given user with name “Uncle Bob” does not exists in the system When I create a new user with name “Uncle Bob” Then the registration should be successful In this case, there are the following checks behind the phrase “Then the registration should be successful”: 1. Registration form was saved without errors 2. The User has received a confirmation email 3. The user had clicked on the confirm link and the email confirmation was successful 4. User logged in to the system All those steps are impli...

It is really hard, or almost impossible, to form a two-way communication between groups of people that operate in different business spheres without stumbling upon situations where both sides use the same language and even words, but imply a different meaning. For example, if building a banking application, you might be asked to implement an ‘account’ feature in the next iteration. If you don’t have enough experience with this particular business or company, you may assume that this feature relates to ‘user accounts’ or ‘user management’ whereas it may refer to the introduction of ‘credit/debit accounts’ into the system. If this misunderstanding isn’t cleared in time by the development team, they could spend anywhere from a couple of weeks (using Agile) to years (using Waterfall) building an ‘account system’ that the client didn’t actually want or need. This problem is generally known as ‘the feedback delay’ or, in this particular case, ‘the cost of translation’. BDD attempts t...

Key benefits of BDD All development work can be traced back directly to business objectives. Software development meets user need. Satisfied users = good business. Efficient prioritization - business-critical features are delivered first. All parties have a shared understanding of the project and can be involved in the communication. A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression. Resulting software design that matches existing and supports upcoming business needs. Improved quality code reducing costs of maintenance and minimizing project risk. The BDD approach can largely be divided into two main parts. The first is the practice of using examples written in ubiquitous language to illustrate behaviors (how users will interact with the product). The second part is the practice of using those examples as the basis of automated tests. As well as checking functionality for the user, this ensures the system works a...

When launching a new digital project, there can be a disconnect between: the business being truly able to define the desired outcomes the developer’s understanding of what needs to be built, and the business’ understanding of the technical challenges their requirements may present. Behavior Driven Development (BDD) can help achieve all of the above and ultimately, helps a business and its technical team deliver software that fulfills business goals. The Beginner’s Guide to Behavior Driven Development is an introduction to BDD, an approach to development that improves communication between business and technical teams to create software with business value. This guide is for both technical and business professionals to learn about BDD, how it can benefit projects of all sizes, and how to implement it with confidence. The guide will be updated regularly by experienced BDD practitioners within Inviqa, as well as other external contributors, and is structured to refle...

BDD focuses on the behavioural aspect of the system rather than the implementation aspect of the system that TDD focuses on. BDD gives a clearer understanding as to what the system should do from the perspective of the developer and the customer. TDD only gives the developer an understanding of what the system should do. BDD allows both the developer and the customer to work together to on requirements analysis that is contained within the source code of the system.

Behavior Driven Development Behavior Driven testing is an extension of TDD. Like in TDD in BDD also we write tests first and the add application code. The major difference that we get to see here are ·          Tests are written in plain descriptive English type grammar ·          Tests are explained as behavior of application and are more user focused ·          Using examples to clarify requirements This difference brings in the need to have a language which can define, in an understandable format. Features of BDD 1.     Shifting from thinking in “tests” to thinking in “behavior” 2.     Collaboration between Business stakeholders, Business Analysts, QA Team and developers 3.     Ubiquitous language, it is easy to describe 4.     Driven by Business Value 5.     Exte...

The Data Flow Diagram gives us information of the flow of data within the application. - The DFD can be used to analyze the design of the application. - It is a graphical representation of the structure of the data. - A developer draws context level DFD first showing interaction between the different components of the application. - DFD help in developing the software by clarifying the requirements and major functionalities. - DFDs show the flow of data through a system. - It is an important modeling tool that allows us to picture a system as a network of functional processes.

Bug Life Cycle: - When a tester finds a bug .The bug is assigned with NEW or OPEN status, - The bug is assigned to development project manager who will analyze the bug .He will check whether it is a valid defect. If not valid bug is rejected then status is REJECTED. - If not, next the defect is checked whether it is in scope. When bug is not part of the current release .Such defects are POSTPONED - Now, Tester checks whether a similar defect was raised earlier. If yes defect is assigned a status DUPLICATE - When bug is assigned to developer. During this stage bug is assigned a status IN-PROGRESS - Once code is fixed. Defect is assigned a status FIXED - Next the tester will re-test the code. In case the test case passes the defect is CLOSED - If the test case fails again the bug is RE-OPENED and assigned to the developer. That’s all to Bug Life Cycle.

- The Stub is called from the software component to be tested. It is used in top down approach. - The driver calls a component to be tested. It is used in bottom up approach. - Both test stub and test driver are dummy software components. We need test stub and test driver because of following reason: - Suppose we want to test the interface between modules A and B and we have developed only module A. So we cannot test module A but if a dummy module is prepare, using that we can test module A. - Now module B cannot send or receive data from module A directly so, in these cases we have to transfer data from one module to another module by some external features. This external feature used is called Driver.

Monkey testing is a type of Black Box Testing used mostly at the Unit Level. In this tester enter the data in any format and check the software is not crashing. In this testing we use Smart monkey and Dumb monkey. Smart monkeys are used for load and stress testing, they will help in finding the bugs. They are very expensive to develop. Dumb monkey, are important for basic testing. They help in finding those bugs which are having high severity. Dumb monkey are less expensive as compare to Smart monkeys. Example: In phone number filed Symbols are entered.

Bug Leakage:   When customer or end user discovered a bug which can be detected by the testing team. Or when a bug is detected which can be detected in pervious build then this is called as Bug Leakage. Bug release:  is when a build is handed to testing team with knowing that defect is present in the release. The priority and severity of bug is low. It is done when customer want the application on the time. Customer can tolerate the bug in the released then the delay in getting the application and the cost involved in removing that bug. These bugs are mentioned in the Release Notes handed to client for the future improvement chances.

Priority:   concern with application from the business point of view. It answers: How quickly we need to fix the bug? Or how soon the bug should get fixed? Severity: concern with functionality of application.  How much the bug is affecting the functionality of the application? Ex. 1. High Priority and Low Severity: If a company logo is not properly displayed on their website. 2. High Priority and High Severity: Suppose you are doing online shopping and filled payment information, but after submitting the form, you get a message like "Order has been cancelled." 3. Low Priority and High Severity: If we have a typical scenario in which the application get crashed, but that scenario exists rarely. 4. Low Priority and Low Severity: There is a mistake like "You have registered success" instead of successfully, success is written.

The differences between Retesting and Regression testing are below: - Retesting is done to verify defect fix previous in now working correctly where as regression is perform to check if the defect fix have not impacted other functionality that was working fine before doing changes in the code. - Retesting is specific and is performed on the bug which is fixed where as in regression is not be always specific to any defect fix it is performed when any bug is fixed. - Retesting concern with executing those test cases that are failed earlier where as regression concern with executing test cases that was passed in earlier builds. - Retesting has higher priority over regression.

- Branch Coverage is testing performed in order to ensure that every branch of the software is executed atleast. To perform the Branch coverage testing we take the help of the Control Flow Graph.  - Decision coverage testing ensures that every decision taking statement is executed atleast once. - Both decision and branch coverage testing is done to ensure the tester that no branch and decision taking statement, will not lead to failure of the software. - To Calculate Branch Coverage: Branch Coverage = Tested Decision Outcomes / Total Decision Outcomes.

Verification:  process of evaluating work-products of a development phase to determine whether they meet the specified requirements for that phase. Validation:  process of evaluating software during or at the end of the development process to determine whether it specified requirements. Difference between Verification and Validation: - Verification is Static Testing where as Validations is Dynamic Testing. - Verification takes place before validation. - Verification evaluates plans, document, requirements and specification, where as Validation evaluates product. - Verification inputs are checklist, issues list, walkthroughs and inspection ,where as in Validation testing of actual product. - Verification output is set of document, plans, specification and requirement documents where as in Validation actual product is output.

1- The I found a bug bot:  This person stops at the first sign of a bug and directly files his bug report. Don’t get me wrong filing bug reports is very important – how else can bugs be fixed? But a little investigation into the own test or environment could make a big difference in filing VALID bug reports. 2- The I-am-not-a-programmer:  I don’t know how to code, I don’t want to know how to code, that is the programmers job. This person does not understand the technicalities of the software under test or the technical implications of the bugs he/she stumbles upon. At best the person behaves like a user functionally looking at the software, at worst the person revels at placing v’s in checkboxes. 3- The I-need-all-the-documentation-or-I-can’t-test:  Some people get stuck in the test basis intake steps. They have no imagination and can not just start testing based on the product, code and information from the programmer. This tester believes that the world (or at lea...

Q#1:   What is Selenium? A:  Selenium is a browser based functional test automation tool. It is basically a library which you can use in your program to test a web application. It is important to note that selenium is mainly used for browser automation. It is NOT used for unit testing or API testing. Selenium Webdriver has many language bindings, which means you can write your tests in your favorite programming language and using the respective selenium bindings. Q#2:   Another interesting selenium interview question is how many languages does selenium WebDriver support? A:  The main ones are: Java, C#, php, Ruby, Python Q#3: In Selenium WebDriver, how do you select an item from a drop-down menu? A: We can select an item from the drop-down menu by Value, by Index or by Visible Text. Example: 1 2 3 4 5 6 <select id = "cars" >    <option value = "vo" > Volvo </option>    <option value = ...