And how do you deal with the fact that programmers do not check the result?

Question

Software testing

A question about situations when a programmer did something, uploaded it and didn’t see / didn’t check / didn’t click that what he did didn’t really work

Answer 1

We dismiss.

Answer 2

A code review was introduced, the number of “fixes” curves that were not checked by the author for performance at all decreased sharply. But it's certainly not a silver bullet.

Answer 3

Just double-check all the time. I confess, sometimes it happens, too, and I have no excuse.

Answer 4

Call your parents!
In general, there should be a tester + a normal manager for control.

Answer 5

Beta testing, demonstration of ready-made features - nothing else.
If, of course, you approach the matter in the style of “fix that thing quickly, you should have uploaded it yesterday” - then the quality of the product will be appropriate, and the fault is not bad programmers.

Answer 6

Code review
Smoke test
Regression test
And you should also try to track the number of fixes after reporting on the execution. For low rates, hold conversations about the reasons. Maybe a person is tired of your tasks, he wants something else. Etc.
Everyone mows, some more, some less. The main thing is when it becomes critical for the project. Did not close the div - not a strong bug. But if the features are not constantly completed, but are closed as ready-made, this needs to be dug.

Answer 7

TDD/BDD + beta server.

Answer 8

Tasks can only be closed by PM.
Just because the task is not closed, at the end of the task there should be a reason why it can be closed. If the task was: “The avatar is not displayed in the profile if it was made from the camera”, then at the end of the task there should be the phrase: “I fixed it and checked it, now the avatar appears if it was made from the camera.” It is also advisable to attach a screenshot and any other evidence that it is now working.
PMs or testers always have access to the product version, where the result of the work performed in the closed task is present.
Therefore, a PM or tester can always check if the bug has been fixed for sure (usually this is done only with complex tasks), but can also close the task right away.
I would also like to add that we have 2 servers: a combat server for users and a development server for developers. Everything is first checked on the development server. Every 1-2-3 weeks a version is formed and the combat server is updated. If this is a critical bug fix, then a mini-version is formed on the same day when the bug was closed and the combat server is updated.
Developers can be penalized for sheer negligence. But I don't think that will help much.

Answer 9

A sore subject, but IMHO there is no reception against laziness.

Answer 10

Enter the rule "untested code = unwritten code".
Goonies can be assigned a tester.
If it turns into a system, fine according to the work done (there you can immediately see in numbers that you completed 4 tasks out of 20 for the current month)
If you relapse, fire the boobies.

Answer 11

The solution to this problem is very interestingly described www.ozon.ru/context/detail/id/7360633/ Every time a programmer should try to make the highest quality code

Answer 12

The main rule is that the committer does not merge its code. The code must be with the test. Accordingly, a colleague checks and reviews the code, runs tests and makes sure that the old ones do not fall.

Answer 13

It's not so scary when he doesn't check, it's scary when he writes x%: No. I'm tired of fighting in a company with how some code is written, tabulation is random, there are no comments at all, strange cycles, in general, horror.
We started using github and a pull request, there is a dev server, the code will not go to the pull on the stage until it definitely works and someone has not reviewed it.