1. Bad Mental models:

a. Everything can be tested? As developers, you are more used to building stuff, while testing needs more of a searching mindset. Stop looking at testing as a brute force problem. Don't look at testing each and every scenario. It is not possible to test everything. The focus and attention which you need to give across different areas would vary. It is also tough to define all test cases at the start. Testing involves learning a lot of new things earlier and then approaching it based on the importance required.

How can you get better: Have an interview mindset. Whenever you interview candidates you will learn about the candidate and then frame your questions around the answers you get. Similarly, while testing pick a starting point and learn about the product. You will learn more about the product and discover more scenarios. You can then focus your testing on the cases which you feel are important.

b. Over-reliance on the code: Don't look at the code to solve all the testing problem. We have seen this happen quite often when developers start testing. Code is of course required if there are some repeatable stuff. But you need to keep in mind that code cannot help you test faster in many cases.

How can you get better: You need to look more at how the users are going to use the application. Don't repeat yourself (DRY) principle doesn't apply. You may feel that your unit tests may have already covered this scenario, but you will be surprised to find many bugs which get unraveled when you test the scenario again with different approaches. Use the application, be patient and things would get better.

2. Difficult work culture:

a. Poor coordination among team: You have given up worrying about the Integration of your code. You would have tried aligning your work to gel with other team but would have failed. So now you think more about getting your work done well rather than integrating with other teams.

How can you get better: Communicate better but there is no silver bullet here. Bring this issue with the management team and definitely don't bash the other teams while doing this.

b. Bad code reviews: Code reviews are considered as a trivial work. We believe the other person would have done his work and neglect the reviews. This would ultimately lead to bad code which impacts the application.

How can you get better: Take code reviews more seriously. Have some guideline of the standards to be followed.

c. Inherited badly written code: This is a problem which is tough to solve. You would have got badly written code and code without proper documentation.

How can you get better: Don't shy away from pointing at badly written code. Fight for refactoring the code and make changes whenever you can. We are not sure how to solve this but we recently came across this article with lot of developers giving their views.

d. Don't report your work well: You focus more on getting your work completed and don't spend enough time thinking on how to report it to your managers and peers.

How can you get better: Socialize your work better. Add your implementation and testing notes. Be verbose when something is reported or fixed.

e. Stigma: You think that testing is inferior work and won't look at testing unless something breaks. Some junior developers or interns or a separate team is assigned of testing responsibility and they are responsible for the quality of the product. In some cases, testing is seen as a punishment. Also, the focus is more on building new stuff rather than bettering your work.

How can you get better: Look at testing with priority. Quality is the responsibility of each one in the team. Make your senior developers test and don't pay attention to testing only when something goes bad.

3. Out of your control:

a. You want your code to work: The developers will always have parental feeling towards their own code. The focus is more on getting your functionality working and you fail to notice some errors around it. This is more of a human tendency, we don't know how to solve this.

b. Bad management: You work in a management structure that punishes occurrence of bug and doesn't reward for non-occurrence of bugs. Software engineering is treated like a manufacturing hub in some places though the two activities are fundamentally different. Again we are not sure how can we handle this issue. Any suggestion is welcome.