How much testing should a developer do

On the other side there are many developers who rigorously test their code using coded tests. Pride, is should be noted is seen as one of the sins of developers :. Personally, I don't enjoy testing because i find it boring and repetitive. And i know many who think the same but we need to ensure that developer testing can be a productive part of your QA. QA-based testing On the QA side I have a lot of respect for QA tests because it takes balls to question a developer's work and deal with any defensiveness that can come back.

There are some very good QA testers out there doing a great job but the best ones need to be confident when reporting bugs to the dev team. They also tend to have much more knowledge of the application in its entirety with all its nuances, including regression history. I think they also help to ensure the developers are honest and hard working, because in some ways they are covering the work on a dev manager testing and providing oversight of the entire development process. As their job is based on finding faults, QA testers push an application harder than a developer.

A simple test and success will not be enough as they seek ways creatively to execute tests that may not occur to the developer. Developers and QA testers should, of course, work in conjunction with each other.

Code testing works well but a QA tester can run more human tests that are unexpected and ensure the application is more robust. Based on their knowledge they can think of many different ways to test an application and compare to previous testing. Documentation created from testing is super useful for training and even in some cases for client usage.

So which is better? The answer is neither, a combination of both approaches works best. With many Dev teams constantly and quickly releasing code there is a need for QA to play its part.

Many of these losses could likely have been avoided if more thorough and robust quality assurance procedures had been implemented. Quality assurance engineers don't just carry out tests, although this is a large part of their role. They also document the testing process, suggest the best solutions to issues they find, identify KPIs for product quality, create and institute overall QA strategies, and much, much more besides. There are many different types of tests that QA testers may perform.

End-to-end known as e2e testing is a large part of what QA testers do. This involves mimicking real-world use of a piece of software from beginning to end to ensure everything is working as it should.

They may also perform many other different types of tests, such as load testing, which involves checking to see how much workload a system can handle at once, or usability testing, which establishes the user-friendliness of a new product.

The aim of a QA tester is always to identify any possible issues or bugs the software might have, then find the best way to correct them so that by the time it gets to the user, it can provide them with nothing but the best experience possible.

This involves testing specific components of a piece of software, and as it requires detailed knowledge of the code used to create it, developers often perform this task. Now let's look at why, in almost all other scenarios, developers testing code is not a good idea. They Don't Have Time We've already illustrated all of the time-consuming and painstaking work that goes into being a successful QA tester. It requires hard work, laser-sharp focus, and most of all, dedicated time. Now, consider all that a software developer has to do in their role.

Use static code analysis tools to enforce coding standards, and configure those tools to run automatically as part of the build. Developers will write unit tests to make sure that the unit be it a method, class, or component is working as expected and test across a range of valid and invalid inputs.

In a continuous integration environment, unit tests should run every time you commit a change to the source code repository, and you should run them on your development machine as well. Some teams have coverage goals for their unit tests and will fail a build if the unit tests aren't extensive enough.

Developers also work with mock objects and virtualized services to make sure their units can be tested independently. If your unit tests fail, fix them before letting someone else use your code. If for any reason you can't fix them right now, let the other person know what has failed, so it won't come as a surprise when they come across the problem. Some teams have load and performance testing baked into their continuous integration process and run load tests as soon as code is checked in.

This is particularly true for back-end code. But developers should also be looking at single-user performance on the front end and making sure the software is responsive when only they are using the system. If it's taking more than a few seconds to display a web page taken from a local or emulated and therefore responsive web server, find out what client-side code is slowing things down and fix it before you let someone else see it.

Make time to run as many of these tests as possible before you hand your code over to anyone else, because leaving obvious bugs in the code is a waste of your time and your colleagues' time. Of course, you'll need to find the balance between writing code vs. I'm also a firm believer in the idea of developers peer review. Since adopting this methodology at my place of work the quality of work has significantly increased.

The new set of eyes provided by peer review are frequently finding more efficient ways to write code or picking up errors that would have otherwise been missed. Additionally as obvious as this sounds I would encourage you to clearly inform your testers of all changes that you make to your code no matter how small. There have been countless times when new features have been implemented but because the relevant work items were never updated with specific enough details I never knew the new feature existed; until I stumbled across it by accident during exploratory testing that is.

This is even more important if your testers have a large amount of automated tests as the smallest change can cause these tests to begin to fail. This really depends on the complexity of the project, the size of the team and the difficulty of integration. Those should normally deliver good builds to QA, which tends to improve the working relationship, among its other advantages.

In my organization, we try to have a developer and a tester sit down before writing any code to have exactly that discussion - because the answer will probably be different for each feature you implement.

Unit testing is a given in my team - but more often than not, the tester and developer will also automate GUI tests up front too. That way the core business logic is tested when the feature is passed to QA - leaving testers to conduct exploratory testing.

The development process should include as part of the deliverable, well written unit tests that accompany the software into the QA cycle. Preferably, a Continuous Integration server would be configured to run the unit tests after QA test build completion. It depends. If your process is lightweight e. Scrum , then continuous build, automated tests, etc. If your process is heavyweight e.

In addition to automated tests unit, integration, UI automation if possible , you should deploy the software in a production-like environment using your production deployment process. Then, have each developer verify their bug fix es and feature add s. Better yet, have developer B test developer A's work and vice versa. We have Developers test their code by doing a build and deploying it to the Development environment, and verify what they can in the new environment.

If there are other changes in the build they need to coordinate with others to make sure testing is done. In other environments Developers would write out simple plans and switch them with each other, so each Developer is testing code they did not write.

I'd check with your QA team and see what they would need, at a minimum what you should have done is enough to verify that the build will not crash when started in the QA environment so they don't waste time installing a build that will not work. All of these suggestions are great. I have only thing to add. When a bug is fixed in 1 platform, since code is sometimes shared with other platforms, please test the other platform s too to see if the bug exists there. Especially with customer bugs. Also, you may want to have an automated "smoke test" that runs through the basic functionality and verifies that there are no major errors when taking all the common paths through the system.

If a smoke test of this kind exists, it would also make sense for it to be run before handing the build off to the QA team. There are plenty of things a developer should be concerned with other than functionality but make sure you do test functionality. Each and every one of us is a QA, whether we be a developer, business analyst, product owner or end user.

Quality control is required at every level of product development, from every single person involved. Learn what you can from the QA team; educate yourself about it from online articles and courses Unit testing, by the way, comes nowhere close to what end users actually do in the real world. You have to treat the final build you send to the QA team as though it were the final build for production, and with full responsibility for it. In addition to your unit tests, please check that your feature meets any written requirements.

If the written requirements are out of date, make sure your product manager and your QA are aware of it. There is nothing more annoying than checking software against the agreed requirements, only to find out that those requirements were not correct or straight-up ignored and abandoned. If the developer is just going to build what she wants and the product manager is just going to go along with it, why bother having QA manually test it? I would prefer to spend my time automating regression tests.

If there are no written requirements, For the Love of Linux, write some down somewhere. You could express them verbally to a QA engineer, but you might end up repeating yourself.