Xjyuk

In my experience as software developer I found work situations where you have to deliver a project in a very short time and with a very small number of resources (included team members). Your boss doesn't really care and understand importance of testing (especially automated) and other quality aspects (or he may understand the importance of those, but may be he is being pushed by his manager to ignore it). Apart from "quitting the job", which actions would you take? shortcuts and which ones? other?

Yes, the real world is a lot different to what you are taught at university.

When you work for a business, the job is to make a profit, not deliver software according to an idealised software development process. A lot of the time these things overlap, but not always.

It is perfectly legitimate to "cut corners" from time to time.

While you may lament that you boss doesn't understand the importance of software testing, he may lament that you are unaware of the business pressures that impact the business that mean things need to be shipped without automated testing. I don't think it's fair to categorize your boss as ignoring the importance of testing, he obviously just assigns it a different degree of importance to you.

Your role in this situation is to highlight the risks associated with not having automated testing to your manager, and allow them to make a judgement call with all information.

(Of course, this answer will get lots of down-votes, because the mere suggestion that software quality isn't the only factor that is important to a business offends the sensibilities of a lot of people.)

Software development is about managing risk in unknown or uncertain environments while frequently doing novel work. Making tradeoffs about time, scope, and quality happen all the time. The important thing to do is to help stakeholders understand the impact of their decisions on the project. To me, responses of "quit the job" or "blow the whistle" would be reserved for cases where the decisions made for the project would have severe consequences for life and safety, privacy or confidentiality, security, or some other 'critical factor' (which would vary depending on what you are building).

Unfortunately, there are no best practices or algorithms for making these decisions. Learning comes with time and experience. You can study the experiences of others, but the best experiences are yours and working through these trade-offs with your colleagues to understand the rationale for the decision making process. Decisions like this are highly context-sensitive.

Yes, tech debt is a perfectly valid desicion in many cases; just like taking out real debt is a valid business decision in many cases to advance the business goals. (We'll make $$$ if we had $ capital to invest in the business, so getting a loan for $ and paying $$ back still puts us ahead in the long run)

But in my opinion skipping automated tests is never a good loan to take. The time saved is often used up, not in years or months, but weeks. (And it gets exponentially harder to pay down) Unless the due date is today, don't skip tests, it won't be worth it.

This is one reason to follow TDD IMHO. Because we are then never in a situation where we can say a feature is "done" but "still needs to be tested". Its just too tempting for a non technical manager to lop off the tests and call it done. They now only have the much better options of cutting scope, rescheduling delivery, or when really necessary using other types of tech debt (abusing state management, skipping robust architectures, etc.)

What actions to take: The first is to explain to your manager what cost the shortcut is likely to make to the company. Worst case the shortcut means endangering and possibly killing people. Most harmless case is that you fix the problem next week and no harm is done. Your manager needs to know what it is to make an educated decision.

The next action is to take steps that "fix" the shortcut if needed. Sometimes it's not needed. Sometimes you write software for a single use, and it either works or it doesn't, and you can see whether it worked. In that case, if the software worked, then it doesn't matter what shortcuts you took.

Sometimes shortcuts are justified. Say you are the only developer, and software must be ready at date X. If you are ready at date X, the company makes a lot of money, enough to hire two more developers. If you are not ready at date X, the company makes no money and you lose your job. Clearly you take the shortcut. If everything works fine, the two extra developers can more than clean up all the mess that was created to be fast.

What is good is if you can educate your manager that if your software is in a good state, then you can take shortcuts sometimes. You may be able to do a job that should take four weeks in one week (but now the software is all messed up). But you can do that only once, then you need to spend three weeks to clean up. If you don't clean up, then the next four weeks worth of work either takes seven weeks including cleanup, or four weeks leaving even more mess, and after that you are in trouble.