(About the author: Meghbartma Gautam is a 10 month old newbie in the corporate world as an SDE with Microsoft India. This is his second post on strat.in . Read his first post here. )
There have been many inquiries and some equally curious glances towards my job description. In this post I will aim to cross categorize job roles and what it is exactly that they are in the business of. Most often and it is not without reason that we have 3 portfolios – Dev/Test/PM. Lets take a closer look at these profiles:
Usually, there is a technical aspect to a team and then there is a business aspect. The business knows exactly what the customers want, to go from A to B. The Technical aspect is the matter of building the bridge that connects A to B. Usually these guys are not going to know too much about why the specific requirements are there in the first place but the functionality will be crystal clear and so will the implementation.
PM : The most often used/abused position in the history of software engineering. They can mean anything from People/Program/Product/Project/Pirate Manager to just merely a messenger who co-ordinates and keeps people posted about the timelines involved. They are in charge of getting everybody on-board to exactly what is happening. These guys are also the ones who will painstakingly chart out the path to follow en route to the development of the given product/service.
Dev : These guys/gals are the ones responsible for the implementation. They make sure that whatever is required gets implemented in the best way possible. They are far more concerned with the minute intricacies of the implementation than they are with the bigger picture. Their job is to make sure that a thing runs and looks pretty and in today’s neo-hip day and age, has a groovy use experience.
Test : With the briefs, we move over to, traditionally the most unwanted portfolio. The simple reason that there are so many brainwashing sessions/blogs and Separate career pathways for Tests is enough to convince you that this road used to be distinctly kachcha. The glory resided with the Dev folks. These are the guys who made the darn thing. They were the creators, they were the ones who made a concept take life. Indeed, they still are but we are looking at ‘Test’s in a much more different light these days. Traditionally the Test job description came with some routine housekeeping and work that was easier done on hire than to recruit specifically. There still is a widespread notion that we only have a job which is completely dependent on someone else’s work. However, this mentality has some major flaws.
The traditional SDLC (Software Development Life Cycle) didn’t really leave too much room for us to act. As is, our role came in much later than the actual work started. There was a very pronounced lack of opportunity to make our presence felt and an even lower threshold for driving initiatives. This was all due to the 1 – dimensional view that was widely held of Testing. Something is supposed to work a certain way, we were supposed to find ways in which it didn’t. This still is essentially the basic fabric of what is done in testing however the equations have changed with respect to how we are viewing the use of Test as a discipline and not as a process. Test is supposed to be on the same page as the developer, working simultaneously on ways to keep the functionality same while suggesting improvements to the Dev approach.
Essentially, if you are looking at your own work, there aren’t too many flaws that you are liable to find. This necessitates a pair of eyes that are wired to a brain which is constantly on the lookout for new methods to screw with what you have done. Thus the need for a Test. Also, the approach from a functionality perspective. There is a very pronounced need to better implement an idea. ‘N’ number of ideas may be good, but the better implementation comes up trumps. From a neutral standpoint, we are at a better stage to judge if the performance is satisfactory, or if indeed the User Experience works. Again, a discipline and not a process. Something that is so much a part of a product’s lifecycle that you cannot really contemplate letting it rip without subjecting it to the rigors of testing.
I hope that this, slightly pedagogical post will enlighten those of us who have always wanted to know what it is that a test does and why was it that a “Test” portfolio is something of a lesser God, or well at least used to be.
Thx for reading.
Post your comments below to take part in the Comment 2 Win contest!
Like what you read? Share in your network!