Having recently read a post on the UTest blog, I decided to think back about my developer days. What challenges did I remember from my experience as a Developer? Did I test my code or not?
1. Sometimes, it required a huge effort on my part just to know the correct set of requirements. Sometimes, the requirements would be given by a business person who would be focused on the promises already made out to the customers. The product manager/ business analyst would rarely verify the technical feasibility of implementing the requirements before committing to the customers. In such a situation, it became a matter of identifying the design alternatives available and exploring the promising ones in detail. As a developer, I used to take such situations as intellectual challenges. This resulted in me saying Yes, even when a simple No would save me a lot of work.
2. At other times, I was handed over source code that had been written, changed and enhanced (all these in different orders) by at least 3 or 4 developers before me. These developers were now either busy with other projects or no longer available in the company. I found this source code riddled with problems. There would be sections of the code that were incomplete, the sections would work with some input values but not with others, were partial duplicates of other sections or had logical problems. Getting such code to work was challenging. It involved plowing through the code (reading a section, unit testing it, resolving the problems, unit testing it again, refactoring it to make it more understandable, unit testing it and so on).
3. The other thing I recall is the sheer number of problems I had to face in order to implement a single requirement. Examples of these problems were:
a. The design was either non-existent or did not cover the particular requirement. This meant that my task doubled in scope. I first had to create a good design and then implement it.
b. The base components were not present or had defects. So, I had to decide either to re-write the base components from scratch or debug them before using them.
c. A similar requirement was already implemented in the application. The trouble was that I was either not able to understand that implementation or suspected hidden defects in that implementation.
d. The underlying development or run-time environment had issues (meaning defects or constraints) in certain conditions. This meant that I had to either somehow circumvent those limitations or break down my implementation into multiple parts in such a way that I did not run into these issues.
4. The next thing that I remember is how tight the schedules were. There were two reasons for this. The first reason was that the development effort was routinely under-estimated. Maybe my project manager (who estimated the development effort) wanted to increase my productivity constantly. Or maybe s/he estimated the effort considering the simplest development possible. The second reason was that I wanted my code to be perfect (in some cases, more than perfect). This meant that I would write the code implementing a requirement and run it repeatedly looking for problems. Once I had code running without problems, I would refactor it to make it leaner and strictly according to the coding standards (for example, naming the variables according to the specified nomenclature, adding comments every few lines and so on). If time permitted, I would even attempt to enhance the design or add extra functionality (though I stopped adding any extra functionality quite early on). My worries about how my code may not work under specific conditions led me to test it, modify it and again test it repeatedly. Given the tight schedule and my worries about the quality of my code meant that I was under stress.
It is not that as a Developer, I hated testing. Quite the reverse actually, I always wanted my code to be perfect and tested constantly. It was the sheer number of problems that I had to solve in a tight schedule that allowed some defects to fall through the cracks. And the defects discovered by the testers were only small fraction of all the defects that originally existed in the code.
Though I tested my code constantly looking for defects, there was only so much I could do given the tight schedule. In fact, I found that in internal projects (where the delivery deadlines were relaxed), I was able to submit code in which the testers could hardly find any defects.
Software testing involves a lot of work. The tight schedules do not help because it is very common for the development scope to increase during development. If the schedules are more realistic, I am confident that developers would test their code better and there would be a lot less defects in their applications.
1. Sometimes, it required a huge effort on my part just to know the correct set of requirements. Sometimes, the requirements would be given by a business person who would be focused on the promises already made out to the customers. The product manager/ business analyst would rarely verify the technical feasibility of implementing the requirements before committing to the customers. In such a situation, it became a matter of identifying the design alternatives available and exploring the promising ones in detail. As a developer, I used to take such situations as intellectual challenges. This resulted in me saying Yes, even when a simple No would save me a lot of work.
2. At other times, I was handed over source code that had been written, changed and enhanced (all these in different orders) by at least 3 or 4 developers before me. These developers were now either busy with other projects or no longer available in the company. I found this source code riddled with problems. There would be sections of the code that were incomplete, the sections would work with some input values but not with others, were partial duplicates of other sections or had logical problems. Getting such code to work was challenging. It involved plowing through the code (reading a section, unit testing it, resolving the problems, unit testing it again, refactoring it to make it more understandable, unit testing it and so on).
3. The other thing I recall is the sheer number of problems I had to face in order to implement a single requirement. Examples of these problems were:
a. The design was either non-existent or did not cover the particular requirement. This meant that my task doubled in scope. I first had to create a good design and then implement it.
b. The base components were not present or had defects. So, I had to decide either to re-write the base components from scratch or debug them before using them.
c. A similar requirement was already implemented in the application. The trouble was that I was either not able to understand that implementation or suspected hidden defects in that implementation.
d. The underlying development or run-time environment had issues (meaning defects or constraints) in certain conditions. This meant that I had to either somehow circumvent those limitations or break down my implementation into multiple parts in such a way that I did not run into these issues.
4. The next thing that I remember is how tight the schedules were. There were two reasons for this. The first reason was that the development effort was routinely under-estimated. Maybe my project manager (who estimated the development effort) wanted to increase my productivity constantly. Or maybe s/he estimated the effort considering the simplest development possible. The second reason was that I wanted my code to be perfect (in some cases, more than perfect). This meant that I would write the code implementing a requirement and run it repeatedly looking for problems. Once I had code running without problems, I would refactor it to make it leaner and strictly according to the coding standards (for example, naming the variables according to the specified nomenclature, adding comments every few lines and so on). If time permitted, I would even attempt to enhance the design or add extra functionality (though I stopped adding any extra functionality quite early on). My worries about how my code may not work under specific conditions led me to test it, modify it and again test it repeatedly. Given the tight schedule and my worries about the quality of my code meant that I was under stress.
It is not that as a Developer, I hated testing. Quite the reverse actually, I always wanted my code to be perfect and tested constantly. It was the sheer number of problems that I had to solve in a tight schedule that allowed some defects to fall through the cracks. And the defects discovered by the testers were only small fraction of all the defects that originally existed in the code.
Though I tested my code constantly looking for defects, there was only so much I could do given the tight schedule. In fact, I found that in internal projects (where the delivery deadlines were relaxed), I was able to submit code in which the testers could hardly find any defects.
Software testing involves a lot of work. The tight schedules do not help because it is very common for the development scope to increase during development. If the schedules are more realistic, I am confident that developers would test their code better and there would be a lot less defects in their applications.
Hi Inder,
ReplyDeleteThis is a really nice article. You have given real and true situations.
In my opinion Dev and QC team should work in collaboration to deliver high quality products, need to complement each other and work together as one team. I have seen that most of the products where there are lot of problems and issues, it is due to lack of collaboration between Dev and QC teams. Most of the successful organizations encourage this practice.