Vinay Krishna explains why agile development includes testing and coding concurrently, which is also what test-driven development emphasizes. The transformation from coder to developer to tester is needed in all agile software development projects.
I started my IT journey as a coder. I worked on many small- and medium-sized software projects and products. First few years, as a coder, I always put more effort into writing code or implementing required functionality. I tried to write code as per my best, but most of the time I faced difficult times during and after production/QA releases. As a result I started stretching my working hours along with my teams at the office and struggling to fix the never ending bugs. The whole team was spending day and night, including weekends, and output was horrible. Mostly after any release, pressure was very high directed at the development team. During that time as a team member I was thinking it was as a result of bad estimates and poor planning. I raised this concern and next time I got time as per my estimation. To my surprise I felt very little difference or improvement. Eventually I was stretching my working hours and ruined my personal life as most of us do.
I am not trying to say here that estimation and planning don’t play a major role in the success and failure of a project, but even though in the case of proper estimation and planning without a “developer” (not coder) mentality your adoption of an agile product development approach will fall way short. In this article I will highlight what I have learned about testing and coding from the point-of-view of an agile product developer.
In my early days I was doing only positive testing after writing the code. By positive testing I mean to say testing of any functionality which met customer requirements. So all the time I was providing only correct values in all required fields and checking whether the new system gave correct result or not. It looks funny now when I look back on this.
Those days I was not able to understand why someone would test by entering incorrect values or would use different steps which are not possible or supported by the system. As a result I tried to spend more time on providing training to users or providing more detailed training material.
But very soon I realized that only positive testing was not the correct approach as lots of factors are there to violate the rules, like users may change at client end. Also, one cannot always read and follow the steps from the user manual because the actual way of working is different than the implementation and users are comfortable with some old/legacy application and last but not least plain old human error is always possible.
Ad hoc Testing
I started using ad hoc testing which was nothing but just a small addition to positive testing. I was doing some negative or extra testing around some functionality that I was finding complex while implementing. It was bit better than positive testing. However still I was struggling a lot during integration of different modules or components and releasing it to QA and production.
I found “whole part” testing was missing or not proper. I had improved my testing approach a little but only in case of “part testing.”
I added another aspect in my testing approach to cover the “whole part” testing. I started navigating through various screens and was checking for the functionality with some dummy, unformatted and random inputs and finding defects/bugs.
Basically it was just testing here and there evaluating the application and trying to see whether accessing different functionalities is in adherence or going to cause any abnormalities. In fact it was nothing but getting a feel of the whole application by jumping here and there.
Later I came to know I was doing Monkey Testing wow :). Whether sometimes it was dumb or smart monkey testing, I found it better than my previous approach.