Talk:Shift-left testing

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

"many small Vs" is incorrect

Some statements in this article don't look right to me. E.g. "Agile/Scrum is many small Vs" sounds very incorrect.
-- preceding unsigned comment added by 210.9.30.170 00:20, 18 April 2018‎.

"Shift left testing" was coined earlier

Shift left testing was not coined in 2001. The term was in use at Dell Computer in the mid-1990s.
96.8.253.194 (talk) 20:41, 22 October 2020 (UTC)Rex Black[reply]

"Agile/DevOps shift-left testing" shows a waterfall diagram

According to the Agile Manifesto Principles "The best architectures, requirements, and designs emerge", but according the diagram shown, the architecture, requirements and designs are planned before (do not emerge).

And that is key of the *TDD methodologies: the design and architecture emerges after each test being implemented. Robert C. Martin (one of the authors of the agile manifesto) says that "The Web is a detail. The database is a detail." or here "Does this change if you are using a NoSql database? Of course not! You still focus on getting the use cases working and tested before you even think about the database; no matter what kind of database it ends up being.". That means that once you start coding, which database you need emerges, may be a simple plain file makes the job. Or you later refactor. Does not matter, what matters is that you do not design it upfront in waterfall fashion.

And the same for requirements. That is where BDD (or ATDD) focuses the most: using the product to explore and learn about the product. Liz Keogh says about this that "Part of the Deliberate Discovery ethos is that there is always something we don’t know we don’t know – second order ignorance. No matter how many scenarios we have, our understanding can still be wrong. The only way to discover this is to get feedback. Showcase what you’ve produced. Ask people to use the system and see how it feels. The earlier you can do this, the quicker you’ll discover that there’s no silver bullet. You will never get everything right – even if you analyse everything up-front, Waterfall style – and BDD is no exception." — Preceding unsigned comment added by 95.169.227.189 (talk) 07:40, 11 April 2021 (UTC)[reply]