📋
QASpace-CaseStudies
  • Home
  • Test Strategy
    • Vision of Quality
      • Good Test Coverage
      • ISO 29119 Certification
      • Date Internationalization Format
      • Localization Testing
      • Test Management
      • Creating TestCase
  • How to Test
    • How to write good TestCase?
      • Tips on Testing
      • Pair Testing
      • UserStory to TestCases
      • Optimising the development flow in a Scrum team
      • Rate/Prioritise bug tickets
  • Exploratory Testing
    • Exploratory Testing
      • Creating Test Charters
      • Test Charters
      • Velocity was too high
  • Agile
    • Implementing Scrumban
      • Breakdown Task
      • Common work across teams
      • Sustainable QA process in the organization
  • Philosophy of Testing
    • Brainstorming
  • Metrics
    • Risk Analysis
      • Testing Outsource
      • How to measure Quality?
  • Automation
    • AI-Automation
      • Software through the lens of AI
      • SAP/Salesforce Automation
      • Mobile Automation
      • Solve by automating the GUI?
      • Improve Skill-sets
      • Coding Skills
      • Working in BDD
      • Value of Test Automation
      • UI/API automation asset
      • TDD VS BDD
      • Selenium vs Cypress
      • An important consideration of Test Automation journey
      • Balance Test Automation Development
      • Automation is no longer providing value
      • Define AI in test automation
      • Unique Locators
      • Best Practices as QA, QA Lead, and Automation Engineer
      • Making friends with Imposters
  • Survey/Polls
    • Is QA really a Gatekeeper?
  • Performance
    • Performance Testing
      • Client-Side Performace
Powered by GitBook
On this page

Was this helpful?

  1. Automation
  2. AI-Automation

TDD VS BDD

PreviousUI/API automation assetNextSelenium vs Cypress

Last updated 4 years ago

Was this helpful?

Question: Perspective on TDD VS BDD?

Insights:

TDD is about writing tests alongside development, in fact, technically they should be written first. The idea is to have a mentality of what it could go wrong before even writing the code, to avoid as many issues as possible. BDD is more about communication. BDD without communication is a really really bad idea, it just adds a layer of complexity to writing tests. With BDD you try to communicate the features and criteria of "done" while planning in a way that's understandable to everyone involved, even if they don't know how to write code. BDD between SDEs and SDETs is also probably not needed.

But it would be great for a QA with an amazing testing capacity to share a test idea with a dev, for example. If that QA person does not know how to write code Or to tell a product owner that also doesn't know how to write code. The idea is still to try to think about testing as early as possible, but, it is all about communicating it and making it available for everyone in the team.

-- Noemi Ferrera

Insights:

I don't believe in BDD at all. Having worked with 5 other SOlutions Architects who have seen 1 or 2 successful implementations of BDD across the entire globe in our 75 years of automation experience, it makes me very skeptical. The creator of Cucumber, Aslak Hellesoy is amazing and can do BDD correctly. I have not seen anyone else that does that. I think that every Dev should do it. Not 100% TDD all the time. But definitely writing tests, and most of the time writing tests before the software.

I've actually written about this in-depth if you want a deep analysis:

-- Nikolay Advolodkin

Top 17 Automated Testing Best Practices (Supported By Data)Ultimate QA
Logo