Job Opening

I got this call (actually e-mail + call) and would like to pass it on. I dont know how good/bad the position is, but its primararily VB.NET, ASP.NET, JavaScript, SQL server kind of position at ConnectXcite. Description Follows:

"Seeking an exceptional individual for a .NET programming position, based out of Metrowest, Boston. The ideal candidate will be interested in our company’s growth and their own by extension. Qualities we desire include taking initiative, getting work done no matter what, passion for what you are doing and the ability to handle pressure. You should be able to step up as we grow.

We are only seeking someone who is aligned with our company’s goals -- meaning a dedication to developing, enhancing and customizing the product for the clients. You will be partly responsible for taking our company to the next level and will also be given an equity stake in the company.

Requirements:

Experienced in .NET technologies- VB.NET, ASP.NET, JavaScript, SQL server. (Oracle would be a good addition, but not required)

Technically, extremely smart. You will need to troubleshoot on your own. Need to be hands-on and able to code systems on your own as soon as hired.

Ability to work closely with clients, requirements gathering, and develop throughout the software install life cycle

2-4 years industry experience

Passion, positive attitude, client-focused, team player

Hard worker, reliable, results-oriented

Ability to think in terms of software reuse, libraries and methodologies (process)"

If you want to apply, just send me an e-mail with your resume at apoorvajoshi@gmail.com and I would pass it on to the person responsible.

Note: This is not for the company I work for or in no way do I know any other information about this company. I got the above information due to my contacts/network. I have no other information about this company whatsoever. And yes, they will sponsor H1B visas for the right candidate.

Hey Specsy

Note: This Post is partly a repeat of my previous post, SDLC. Specs are the most important thing which a product team could come across, hence I have devoted this post to it.

Lets take the simple example where you plan to build a house. The whole process will require a lot of brainstorming before you lay the first brick. First, you look at the ideal location. Once you have that, you would look into the layout, internal arrangement of the house, how many rooms do you need, etc. You would probably hire an architect to do the planning. Next you would have a construction authority work on the type of material you would like to use, how many days you would like the house to be up and complete in etc. Once all these details are laid into place, the construction will finally begin. Before you begin the construction you would probably want to check every small thing possible, like the soil beneath (sometimes it could be the one in which the house might sink), weather conditions etc.

So be it with any product. Before you start coding, you check through the specs. Check through is a wrong choice of words. To put it mildly, you tear the specs apart. Think about every possibilty.

Lets go back to the house. Your architect lays out the entire plan and you start the construction. A few months down the line, the house is built and you move in. You love your new house but your master bedroom is on the eastern side of the house, which is right next to Interstate - I 95. Passing cars and trailors all night keep you awake. The guest bedroom on the other side of the house is perfectly soundproof and your visiting mother-in-law enjoys the perfect sleep! The guest bedroom is too small for you and your wife to move into... oh only if you had thought about this I-95 before!!

So is it with software. Having the specs does not mean the product is ready to code. Read the spec and start thinking outside the box.

Lets pick a small part of a spec as an example. In this case, lets suppose you are building a product for Company XYZ. XYZ has its small team of technical staff which pens down the specifications document and sends it to your company (usually in house projects have PM's or Dev Teams take up the spec writing respobsibilities). Now, if you belong to a company which believes in good development/testing practices, your first task will be to review the specs. So lets take the following as an example:

Specification version 1.0

1.Shall read from a database file at startup if one is defined. On process termination, it shall save any entered data to the opened file.

First off, company XYZ has provided you with specs, which puts you in a better position than many other people I know (yes, sometimes specs are not provided). If you take every spec and start coding, you have missed an important step. An ideal practice at this stage would be the dev. team starts a lot of designing (on paper) and prototyping. Some prototype code is a common practice. The test team starts working on determining test cases and reviewing the specs (the dev does this too, but somehow they always manage to finish the review much much earlier than test and are knocking to tests door to ask when they can start coding). I shall get into the mentality of these two teams later. For now, being part of the test team, your focus is the specs.

Lets look at no. 1. Shall read from a database file at startup if one is defined. Great! Works for me. Sounds simple! Here is the problem. What if one is not defined? What if the one defined does not exist? Is not accessible (locked?)? What will the program do then? The spec does not state that. Rather than making your own assumptions with what the product should do, go ahead to Company XYZ and ask them what they expect it to do. Provide some options:Option 1: "Should we say - File not found, enter another file"Option 2: We could say, "File did not exist, taking demo file and displaying results to show functionality of product"

You have an ambigious spec clarified. A potential flaw has been averted! Imagine if you had taken your own decision, displayed Option 1 and during qualification (demo) XYZ says they wanted Option 2. The change in this case might take a few hours but imagine something huge for critical systems? Also imagine if this chage you make breaks something somewhere else? Wouldn't you rather spend a few extra weeks on the specs and get them clarified than have clarifications after the product has been developed?

Lets go back to the house. You finally cant bear the vehicle noise on I-95 and you break a few walls, make the guest room bigger and move in there. In this process you are set back by a few thousand dollars and possibilty of maing your house structure weak.

So will it be with any product. A bug fixed towards the end of the product development cycle not only costs more to fix, but could break the software in some other area, making the whole product weak in its structure.

So irrespective of you being a test or a dev or a PM, just forget what you are, think you are a team, and work with each other to produce a brilliant spec. You will be doing everyone around you and yourself a huge favor and missing out a few sleepless nights.

My OS... on the Web!

A thought which crossed my mind (ok, I admit it was triggered off by something I read) but somewhere in the future, gone are the days of your desktop having an Operating System. How about having an OS on the web? All I do is push in an internet cable into my PC and it connects to my web-OS. Anywhere I go, I have access to my OS. I can log onto my PC from India, I can log onto my PC from Alaska. It doesnt matter if I log in on a P-4 or a P-1. My speed wont be affected since my OS runs off a server and not off my desktop. Windows, are you in trouble? Or do I see a Longhorn - Web come up few years down the line? If not... Google, are you listening?? For that matter, any other startup, are you listening? I have a brilliant idea...!!

I think its going to happen (who had thought of 1 GB e-mail space few years ago?). Its just a matter of time!

Talking about Google, here is an excellent move by them to make comment spams redundant!

SDLC

Pete had previously asked, "You had mentioned that this blog would also be for those new to the field of software testing. I would fit in the "New" category which also gives me the excuse of asking basic questions. What is the Software Development Cycle and how does Testing fit into this Development?"

Good question. Like Pete many might not be aware of what exactly does System Development Life Cycle (SDLC) exactly mean in the software world.

Lets take the simple example where you plan to build a house. The whole process will require a whole lot of brainstorming before you lay the first brick. First, you look at the ideal location. Once you have that, you would look into the layout, internal arrangement of the house, how many rooms do you need, etc. You would probably hire an architect to do the planning. Next you would have a construction authority work on the type of material you would like to use, how many days you would like the house to be up and complete in etc. Once all these details are laid into place, the construction will finally begin. So everything goes by a particular method or process.

Lets get to the definition of SDLC provided at http://www.webopedia.com/TERM/S/SDLC.html It states:

(quote)

SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. SDLC is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps:

• The software concept - identifies and defines a need for the new system
• A requirements analysis - analyzes the information needs of the end users
• The architectural design - creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources
• Coding and debugging - creates and programs the final system
• System testing - evaluates the system's actual functionality in relation to expected or intended functionality.

(unquote)

Lets take a case where a company decides to develope a new product. First, they need to identify the need for this product. Why would it be required in the market. Next, how the end user would use this product. What would they want out of this product and what the market lacks right now which this product will provide.

Once these have been identified, we would probably have the Pragram Manager write down the specifications of the product. This is a document which has details of every small requirement that the product should meet. Right from the kind of platform it should work on to how its final output should look.

Once the specifications are up, the Development team starts putting them down into code and test team starts testing the code written by the development team.

Did anyone spot an ambiguity? Anyone?

Lets go back to the house. Your architect lays out the entire plan and you start the construction. A few months down the line, the house is built and you move in. You love your new house but your master bedroom is on the eastern side of the house, which is right next to Interstate - I 95. Passing cars and trailors all night keep you awake. The guest bedroom on the other side of the house is perfectly soundproof and your visiting mother-in-law enjoys the perfect sleep! The guest bedroom is too small for you and your wife to move into... Oh!! Only if you had thought about this I-95 before!!

So is it with software. Having the specs does not mean the product is ready to code. Read the spec and start thinking outside the box. First point of the spec says "Client shall take as input a file using the file dialogue open window" (this is a lame way of writing a spec, I am just trying to provide an on the spot example). Anyone try to think what will happen if I choose a file and before I hit open, someone from another machine with access to the server deletes that file? How should the system behave? What if I enter a filename which is not present? How will the system behave? Rip that spec apart.

Lets go back to the house. You finally cant bear the vehicle noise on I-95 and you break a few walls, make the guest room bigger and move in there. In this process you are set back by a few thousand dollars.

The same goes for software, a bug in the spec is much cheaper to correct rather than a bug in the product once the code is up and running.

A good tester would not only find bugs in the product, but would find bugs in the spec. This is where testers come in. I would also like to mention here that developers also go through specs and try to identify bugs, but testers are more concentrated on developing test cases for the spec, developers for design prototypes for the specs.

Back to SDLC. And once a lot of reviews and discussions and prototyping is done, the dev team starts coding and test team continues testing till the final product is complete.

During this entire process the management team oversees the progress, makes decisions about new hires, deadlines, addition/deletion of new features etc.

I think I am going to add a new post of why its important to analyze specs before we start coding + some other stuff.