Some of the choice ones i have noticed, a continuation of prior post i wrote.
Someone did testing on some code, ironically not QA but another developer, of the curry descent. They decided to test malformed json by passing a string with a value of "null", not to be confused with a null value to the request. Confusing arose because i was expected to know which was which. Why not use garbled text or something instead of using a value which is historically known to have a certain expectation?
All environments are open to developers, from DEV all the way to pre prod. To get around the approval issue, everyone has access to self approve their own deployments. This has lead to many, many issues as there is no mechanism to stop bad builds from being promoted, since the dev can promote through an override.
Per my manager, all the coding was done in a week and thrown into a production environment, and the idea was to go back and fix it later. I added a very small change to some endpoints, which is what eventually caused complete system failure when the experimental functional testing started running its test cases. See the functional testing framework was just created in tandem, and it is now noticing issues with the code, except my changes didn't actually touch the code logic, they simply exposed the functionality
Some of the choice ones i have noticed, a continuation of prior post i wrote.
* Someone did testing on some code, ironically not QA but another developer, of the curry descent. They decided to test malformed json by passing a string with a value of "null", not to be confused with a null value to the request. Confusing arose because i was expected to know which was which. Why not use garbled text or something instead of using a value which is historically known to have a certain expectation?
* All environments are open to developers, from DEV all the way to pre prod. To get around the approval issue, everyone has access to self approve their own deployments. This has lead to many, many issues as there is no mechanism to stop bad builds from being promoted, since the dev can promote through an override.
* Per my manager, all the coding was done in a week and thrown into a production environment, and the idea was to go back and fix it later. I added a very small change to some endpoints, which is what eventually caused complete system failure when the experimental functional testing started running its test cases. See the functional testing framework was just created in tandem, and it is now noticing issues with the code, except my changes didn't actually touch the code logic, they simply exposed the functionality
(post is archived)