It is one of the best practices in software industry to adopt standard methodologies and approaches in every phase of SDLC. Development, being the most critical phase, should also be accompanied by standard and approved methodology. A standard methodology is based on some theme factor which drives the process for e.g. Document Driven Approach (where various documents are the driving factor for development process), Model Driven Approach a.k.a. MDA (where models typically UML models are the driving factor), Test Driven Approach (where test cases are the driving factor), Functional Points Driven Approach a.k.a. FPDA (where functional points are the driving factor) etc.
In this article I presented a new driving approach and called it Unit Test Driven Approach (UTDA). Although this may not be a known or standard term in software industry right now, I evolved and adopted the same in one of the projects recently and found extremely helpful in specific situations. In this article I tried to cover introduction and advantages of this approach along with specific scenarios where it could be proved exceedingly helpful.
- Suitable Scenarios
Unlike other articles, where the approach is defined and explained before depicting the amiable situations where it is suitable to use, I feel that it would be helpful to take the reverse route. Listing scenarios where UTDA is most suitable; will not only help in understanding the uniqueness of this approach but also avoid ambiguity involved in the some of the assumptions in the definition of this approach.
The UTDA suits best in the scenarios where part or whole UI/Code is ready. Although the section below explains elaborately the reason for this requirement, it is helpful to note here that in UTDA, the test plan is built by developers looking at the actual UI and code. In the view of this requirement few of the scenarios where UTDA suits best are listed below.
- Technology Migration Projects: UTDA may suits best in projects involving migration from one technology (typically legacy) to another technology where existing product is used as benchmark for requirements and functionalities of the new product.
- Language Migration Project: This involves projects where the exiting product supporting a specific human language needs to port to support another specific language.
- Localization Projects: Projects where a product is enhanced to support I18N also best suits for UTDA.
- Unit Test Driven Approach
In Unit Test Driven Approach (UTDA), the unit test plan composed by developer team (with optional help from testing/QA and business team) is the driving factor for development process. It is important to note that the term UTDA includes the word ‘Unit’ which indicates that the development process is and should be divided into logical units. Although the definition of a ‘Unit’ is not arduous and each environment may define it in its own way, it may range from a simple actionable item on UI to a complete module. Thus the 1st task in UTDA is to define the unit and then prepare test plan for it.
The UTDA can further divide into 2 sub parts:
- Unit Test Driven Approach – UI based
In this approach the unit test plan is prepared using the UI. The test planner should use the UI to find out all possible test cases. Incases where UI is not ready, the HTML wire frame, UI documents etc can also be used to accomplish this task.
- Unit Test Driven Approach – Code based
In this approach, the test planner explores the code and then prepares test plan accordingly. This includes understanding the code and captures all scenarios and exceptional conditions.
Combining the above 2 approaches results in a comprehensive Unit Test Plan, which then used as the driving factors for development activities.
Once the unit test plan is ready, development team starts implementing the same followed by execution of the test plan as the ceasing step. In UTDA it is also recommend having peer or expert review and execution of unit test plan.
To sum up the above paragraphs, the important steps involved in UTDA are listed below:
- Preparation of unit test cases based on UI
- Preparation of unit test cases based on code
- Merging of unit test cases to prepare unit test plan with optional verification of the same
- Implementation/development process
- Execution of unit test plan
- Optional expert (or peer) unit test execution
- Code release to Testing/QA team
- Unit Test Driven Approach – UI based
How UTDA Different From Test Driven Approach ?
It is important to note that UTDA is not same as Test Driven Approach (TDA) except the fact that both use test cases as driving factor. Incase of TDA the test cases are typically written by Testing/QA team and delivered to development team. Also in most of the cases these test cases are written based on SRS or other documents rather than actual UI or code.
- Advantages of UTDA
UTDA is especially suitable where part/whole code base or UI is ready for reference and the further development is based on the same. Let’s cover some of the advantages of UTDA:
- Scenarios where part or whole of the code/UI is available UTDA can be proved extremely helpful as it involve exploring UI and code while preparing Unit Test Plan.
- UTDA is by definition completely compatible with Agile Methodology.
- Unit Test Plan composed by development team can be proved very helpful and useful for Testing/QA team and results in saving lot of time especially incase of black box testing.
Unit Test Driven Approach (UTDA) is a very simple but efficient approach specially incases where some code/UI is ready for reference to development process.
Thursday, March 6, 2008
Sunday, January 27, 2008
In this article I tried to present few notable points regarding competencies based interviews along with merits of the same over traditional interviewing approach.
What is ‘Competencies Based Interview’?
Competency can be defined as a personal characteristic which is displayed by outstanding performers in a role in a given business environment and which is demonstrated through specific observable behaviors. In other words competency is the way one conduct/demonstrate his/her skills in the given environment.
In competencies based interviews, the interviewer tries to evolve, understand and judge the competencies of the interviewees in different areas including behavioral and technical fronts.
How Competencies Based Interviews are different from Traditional Interviewing approach?
Competencies based interviews tends to evolve the technical and non-technical skills of the candidate based on his/her knowledge, behavior and demonstration of the same while traditional interviews tends to evolve the technical and non-technical skills using results as the base line.
Traditional interviewing approaches were more based on ‘What’ kind of questions rather than ‘How’ and ‘Why’ kind of questions and were strongly supported by ‘Theoretical and Hypothetical questions’. For e.g. ‘What was your role in previous organization?’ but not followed by ‘How you managed that role, how you handle various challenges etc.
Few more drawbacks associated with traditional interviewing approaches were:
- Lack of clear job profile and competencies required for the same.
- Lack of interview preparation and structure.
- Poor follow-up questions.
- Involvement of various biasing aspects.
What is the structure of a Competency Based Interview?
The structure of a typical Competency Based Interview is:
- Introduction by Interviewer
Introduction of interviewer is as important as that of interviewee. Although the interviewee’s information is present in the resume or CV but the interviewer’s information in nowhere mentioned in the interview in most of the cases. A good introduction of interviewer makes the environment healthy and comfortable for both. This section can be optionally accompanied by brief introduction of organization as well.
- Rapport building questions
Rapport building questions helps in building confidence of the interviewee and making environment comfortable.
- Explanation of Job profile and expectations
A brief explanation of job profile and expectations in the interview helps both interviewer and interviewing in focusing on the important and relevant information.
- Behavioral Competencies based questions
These questions help in judging the interviewee on the behavioral front. Please read the explanation below for detail on behavioral competency based interview.
- Technical Competencies based questions
These questions indicate the technical strength of the candidate in relevant area.
- Questions from interviewee accompanied by optional feedback session
Before ending the interview, the interviewee should be given an opportunity to ask any relevant question or clear any doubt. This section can be optionally accompanied by brief feedback session by interviewer.
- Interview close up
It’s important to close up the interview with a positive attitude maintaining self esteem of the interviewee and expressing gratitude for taking interest in the organization.
Rapport building questions includes questions not directly related with the job profile but are used to begin the communication.
Few examples of rapport building questions could be:
- How are you today?’
- Do you face any problem in finding our office premise?
- How is whether condition there (especially in telephonic interviews)?
- Question/discussion related with any specific place, event or item of their native place for e.g. so you belong to Jaipur, I heard that it is called ‘Pink City’, do you know why?
There are various advantages of these questions including:
- Help in making the environment comfortable for both interviewer and interviewee and boost up the confidence of the interviewee.
- Help in making sure that both are audible to each other especially incase of telephonic interviews.
- Demonstrate the candidate that this is a god place to work.
What is Behavioral Competency Based Interview?
Behavioral Competency Based Interview a.k.a. Behavioral Event Interview (BEI) includes questions related with the behavior or conduct of the candidate in his/her past job/organization or even personal life (useful incase of inexperienced candidate). The background assumption behind BEI is that the past behavior of a person best predicts the future conduct. Thus BEI involves question related with past behavior of the candidate to understand and predict his/her conduct in future and suffixed by follow-up questions to gather more useful data. Few examples of BEI questions:
- Tell me about an instance where you dealt with a client who changes requirements very often and these changes resulted into lots of re-work and slippages? The follow up questions could be ‘How you handle the situation, how you manage your team in that scenario, how you convince your manager at your end, how you faced the challenges and what were learning from that instance, did you get chance to apply that learning in other projects etc.
- Can you tell me an example where you have a deadline nearby but unfortunately 1 or 2 key resources of your team went on emergency leave or left the organization? Follow up question could be ‘How you communicated with client, how you managed your team, what extra efforts you put into the project, what were your learning from that instance etc.
In traditional interviews the theoretical questions were preferred over behavioral questions for e.g. the theoretical version of the 1st example above could be: Tell me if you need to deal with a client who changes requirements very often which may result in lots of re-work and slippages, how will you handle the situation? The drawback of theoretical questions is that the candidate can use his/her good communication skills to answer such questions wisely but not necessarily execute the same. Thus it resulted in more useless data.
In traditional interview question the end result is more important but in behavioral interview the approach, behavior, conduct, learning, execution and other aspects are also important along with results.
One more important point to note here is the difference between behavioral and non-behavioral answers. For e.g. the answer ‘I proved as a great manager in my last project. The project was delivered on time with excellent quality. Our client also appreciated the same.’ is an example of non-behavioral action. Notice that in this answer, no useful data could be collected because it doesn’t indicate how he/she managed the team, how he/she faced critical and complicated situations, what issues/problems he/she faced and resolved etc. Thus it is important for an interviewer to recognize the non-behavioral answers and use follow-up questions to get more information.
It should also be noted that in behavioral interviews it’s important that answers should indicate a complete behavior consisting of context, action and outcome. For e.g. the answer ‘In one of my previous projects, one of the resources left the organization just before project deadline and I took efforts to manage that’ misses the action (to some extent) and outcome. The above answer doesn’t indicate the actual action and what happened finally and learning from this instance.
What is the importance of follow-up questions in BEI?
To illustrate the important of follow-up questions let me quote snippet from a recent interview…
Interviewer: Can you give me a recent example where you own the complete module and delivered it on time in constraint of deadlines?
Interviewee: In the last project, I completely owned one of the modules in the application and since the deadline was nearby we delivered it without testing cycle and later recognized that there were no bugs in the module.
At this point it seems to be a great work. But let’s see the follow-up question:
Interviewer: Can you explain more about that module?
Interviewee: The module was ‘help’ module which opens various manuals of the application on user’s request.
Interviewer: How much code you wrote for the same?
Interviewee: It was 1 JSP page.
Interviewer: Did you also write or manage the manuals?
Interviewee: No those were written by Technical Writing Team.
The above communication indicates the importance of follow-up questions to get more realistic data.
Remember that the ultimate goal of the interview is to get the most useful data regarding the interviewee to help making effective selection and in this regard follow-up questions can be proved critical to get more and more information.
What are important things to notice while asking technical competency based question?
Technical competency of a candidate is the demonstration of his/her technical skills in the given business environment. This section is very critical as it judge the interviewee on the most critical and relevant part i.e. technical caliber. Questions in this section should be cleverly designed to not only gauge his/her technical strength but also instances and way he/she demonstrated the same in previous job. Few important guidelines for technical competency questions are:
- Avoid questions which requires more cramming but ask questions which requires more logic.
- Use more analytical and general questions. Don’t use uncommon terminologies.
- Try to cover more depth rather than width. Ask simple concepts and explore in depth rather than covering everything.
- Be specific and focused in the technical requirements.
- It’s is very important that you rephrase the important questions if the same is not clear to interviewee.
What are major biasing factors during interview?
Below are few examples of biasing factors which an interviewer should neglect to make effective results:
- Pressure to fill positions: Most of the time interviewer says that the position was open for a log time and ultimately I decided to compromise on that. In long term this may result in serious impact on the project and organization growth.
- Contrast effect: This is again a trivial factor with most of the interviewers. The goodness or poor performance of one candidate affects our attitude towards other candidates. This is true especially incases of weekend drives and walk-ins.
- Regional and religious biasing: ‘Some one belonging to the same part of country as you’ or ‘Some one belong to the non-reputed state of the country’ or ‘Some one belongs to majority/minority community’ etc are most common factors affecting the interviews.
- First Impression: Many interviewers got biased with the 1st impression of the candidate or the gesture and dressing code of the candidate.
- Halo and Horn effect: Halo effect means impressing with one quality to such extent that you neglect all other drawbacks while horn effect means you neglect all god qualities because of one drawback. An interviewer should always try to come out of halo and horn effect.
At the last, I just wanted to list down some tips for effective interviews:
- Focused: Interview is also knows as ‘Mining the skills’ and as in mining it’s very important to follow a vertical path to avoid danger of loosing the track, similarly in interviews it’s very important not to loose the focus and deviate from main track.
- Avoidable Question Types: It is recommended that in interviews the ‘Yes/No’ type of question should be avoided as they don’t result in any valuable data. Also leading, confusing and complex questions should be avoided. (Lending question includes those the answer of which lies in the question itself for e.g. ‘I think you can handle a big team?’)
- Non-Question Questions: Nowadays non-question questions are proving very effect in interviews. Thus instead of asking ‘What are your best skills?’ ask ‘Your resume seems to be impressive but to better know you, can u help me by telling your best skills?’
- Simple and Straightforward: It is highly advisable to keep the questions simple and straightforward so as to get better results and useful data. Use your effective communication skills to explain the questions if required. Avoid using uncommon terms and misleading phrases.
- Maintain Candidate’s Self Esteem: It’s very important that after interview, the candidate shouldn’t feel guilty or insulted. Being on the decision-making-chair, it’s the responsibility of the interviewer to maintain the self esteem of the candidate which not only resulted in healthy environment but also sends an impressive message in the community regarding your organization.
Thursday, January 10, 2008
Java, being considered as one of the most successful and versatile computer programming language, also fits in the above requirement. Now the question comes in every programmer’s mind: Is java an Object Oriented Programming (OOP) Language?
In this article I tried to answer this critical question taking help from theoretical concepts.
As per the definition of Object Oriented Programming, a language can be categorized as PURE OOP based on following criteria:
- The language must have inbuilt support for encapsulation and abstraction.
- The language must have inbuilt support for Inheritance.
- The language must have inbuilt support for Polymorphism.
- All system defined types must be objects.
- All user defined types must be object.
- The only way of communication between objects is through the methods exposed on the same.
Criteria 1 to 3 are self explanatory and don’t require further clarification. So I am escaping those. Now consider criteria 4.
Criteria 4 states that all predefined types in the systems must be objects only. This means there can’t be anything other than objects defined by system. This is the first requirement where Java fails to fulfill the criteria to be categorized as pure Object Oriented Programming. Java has primitive types, which are not objects and thus violates this rule.
Criteria 5 suggests that all user defined types must also be objects only. This means users can’t define or create anything other than objects. This restriction is not applicable in using system defined types. Java successfully follows this rule where user can’t create or define anything other than objects.
Criteria 6 suggest that whenever objects communicate with each other, they communicate using the methods exposed on other objects. And this should be the only way of communication. Java violets this rule by using various operators. Consider the ‘+’ operator on String literals which can be used to add 2 or more string objects. By using this operator java violets the rule of object communication using methods. This holds true for other operators on primitive types as well.
Summing up the above points, java fulfils the criteria 1,2,3,5 but fails in 4 and 6. Failing of these 2 criteria deprived java from being categorized as PURE Object Oriented Programming Language. But still the programming community categorizes Java as OOP (although not Pure). In theory such languages are called ‘Hybrid OOP’ languages.