Why? Because I do assert-driven testing. My test code is integrated into the actual business logic. So no need to contrive scenarios.
That's totally different from an organisation that doesn't do tests at all (yes they exist).
so maybe the takeaway is if people don't do what you expect, maybe digging a little deeper before running away screaming ;)
of course, asserts should not crash the app once it's in production. instead they should be channeled to a log that gets sent back to the production support team for analysis.
but during development, I'd say crashing during small errors is a great thing.
A simple example can be done by writing a single function in the root scope or some global function (javascript)
function assert(assertion, description) { if(!assertion) { console.log(description); //could also have other application error handling code } }
Then in a function in your application:
function myFunc() { var x = 1; assert(x == 1, "x does not equal 1 in myFunc()“);
\\Continue code... }
This is obviously a very simple example and can definitely be iterated upon, but it gets the basic point across and I'm on my phone so writing code isn't the easiest :-P
Some systems have something like this built in, such as node which has more features.
so I'm not saying there are no scenarios, but they all end up being the customer facing scenarios, and verifying those meet expectations. Also just developers making sure the functionality "works" naturally catches the technical bugs (because asserts in production code would cause the app to crash)
You might also want to explore QuickCheck, which helps to generate these scenarios.
You appear to be making your own questionable assumption, which is that the techniques mentioned before necessarily imply a more mature software development process. If a development team didn't use automated testing, I'd certainly be interested to know why, but I can immediately think of multiple plausible alternatives that might have proven to be more effective for that team depending on the circumstances. Unlike the use of brain teasers and popular psychology to assess applicants' value as employees in technical fields, there is a significant body of empirical data to back up the effectiveness of some of those alternative testing strategies.
All three have a strong track record of finding bugs when implemented well. All three also add significant overheads, so there is a cost/benefit ratio to be determined. The relative costs of implementing each strategy will surely vary a lot depending on the nature of any given project. The benefit for any of them would likely be significant for a project that didn't have robust quality controls in place, but you'd get diminishing returns using more than one at once.
I could easily believe that skilled developers had evaluated their options and determined that for their project some other strategy or combination of strategies provided good results without routine use of automated testing and that the additional overhead of adding the automation as well wasn't justified.
Aside from obvious questions about the kinds of projects you'd be working on and the skills and technologies involved, I used to rely on a few simple tests:
1. What is the employee turnover like, and if people have left recently, why? [This is a reasonably objective proxy for what the rank and file staff really think, and they collectively know this potential employer much better than me.]
2. Did they ask brain teaser type questions or do a pop-psych personality test in the interview? [Do their hiring practices suck, in which case even if they hired me, would I want to work with anyone else they hired? Also tends to indicate an unhealthy assumption of superiority and desire to conduct one-sided interviews, which is a red flag in its own right.]
3. Will they show me a sample of their production code and of the related documentation, and if so, what is it like? [If they won't and don't have a very good reason, my assumption is that they aren't confident their code will impress, which is not a good sign. If they will, what I see is about as good a marker for whether they're any good technically as any benchmark you can fit into an interview.]
4. What does the car park look like on the way in? [Far from scientific, but a handful of executive cars in reserved spaces and then nothing but old models in the few remaining spaces is rarely a good sign.]
5. Does the contract impose on my life outside of work? For example, would I need permission from the employer to take on an unrelated side job that had no bearing on my ability to work properly for them? Would they be claiming IP rights to any work I did unrelated to that employment, so that for example I couldn't release a hobby project as Open Source if I wanted to? [Any attempt to control life completely outside work is a fairly reliable red flag for a generally over-controlling attitude and/or a show run by HR/legal rather than sensible management or the people I'd actually be working with.]