What does one need to get job?

Hundreds of job hunters send emails to us asking whether we have any positions open. Every company needs people, all the time. Very rarely, they freeze hiring. But what the applicant does not know or does not care to know, is whether he/she is ready for that position. Everyone feels that they are ready to do the job; but every business leader claims that 80% of the students who pass out in India, are not readily employable. Hence there is a big fight to grab the qualifying ones, by so many companies - the result is the inflated salary levels.

Where and when will it end?

First thing. Whatever is the industry to which one applies for a job, that person must have a good analytical reasoning ability. If one is not able to solve a simple aptitude question, that person is not fit to get an entry. During interviews, we had seen people who do not know how to apply the fundamental principles of simple and compound interests, but applying to a banking position.

Second thing. Be confident. Almost 90% of the people who come for interview at fresh level are submissive. They feel like servants and are afraid of answering in clear loud tone. This attitude must change. Many times we see people pleading ta the end of the interview that they have family commitments and this job is an absolute necessity to them. This will not help.

Third. Communicate clearly in simple way. One need not be a great orator or writer. Simple words, clear sentences will make the interviewer happy. But unfortunately, people try to throw jargons and try to show off their knowledge. But when a practical question is thrown at them, they fail to apply concepts and start blabbering. This wastes a lot of time. Better communication can compensate many other negative points.

Fourth. Unreasonable Expectations. Everyone thinks that they are worth minimum 3 lacs per annum salary. They never care about the job profile or the size of the company. People do not even see the website of the company to which they had applied for a job. For the first 2-3 years, learning is the asset one must look for and not money.

Fifth. 100% job guarantee by training institutes. Do IIT and IIM claim that they can 100% guarantee job to every student? It must be knowledge and skill guarantee and not a job guarantee. Only yourself can guarantee a job for you, based on practice. Any institute that does good training and guidance, will help you; but it is ultimately you, who can make the difference. Lack of self belief is the root cause of this; always people need external factors to help them.

When 50,00,000 students graduate from 22000 arts colleges every year, and 10,00,000 students come out of 3000 engineering colleges every year, only the knowledge and practice can help every fresher. Nothing else.

In worst case scenario, if you do not have a job and someone says work is there but no pay, please take it in a short term at least. That is the intellectual money you can earn; that time will never come back, if you refuse that option also. Sorry, this may sound harsh, but this is reality in India.

Top 100 Test Scenarios for Online Shopping Apps

I have been seeing a lot of ads for online shopping portals. What do they really do? Sell items right from shoes to iPhones. A few product companies asked us to educate their testers in testing their product. We first educated the testers in the business flow of ecom portals.

What you see here is a slice from the testing checklist.

1. View the hot promotion plans on home page
2. View top level categories of products on home page
3. View the order of sub categories of products under each category
4. View top products list under each category-sub category
5. View products as grid
6. View products as thumbnails
7. View small and large images of products with short and long descriptions
8. Search for a product with brand name
9. Search for a product with a model name or number
10. Search for a product below certain price
11. Search for a product within a price range
12. Search for a product with some keywords in description
13. Search for a product of certain color
14. Search for a product in specific store
15. Search for a product in a specific geography
16. Search for a product that are referred by many community people
17. Search for a product for a range of user ratings
18. Search for a product with multiple combinations of above
19. Sort product search results based on price
20. Sort product search results based on store
21. Sort product search results based on buyer rating
22. Add a product to cart
23. Add multiple products to cart from same search results
24. Add multiple products to cart from different search results
25. Remove a product from cart
26. Add the same product to cart after removing it
27. Add the same product multiple times to cart
28. Alter quantity of products after adding to cart
29. Alter quantity to zero in the cart
30. Provide payment details to buy product
31. Provide payment details and cancel it
32. Provide wrong credit card details and try to buy
33. Purchase product thru corporate purchase plans
34. Provide shipping address same as user’s registered address
35. Provide shipping address different from the user’s registered address
36. Register new user with valid details
37. Register new user with invalid details
38. Register same user with same emailed and userid
39. Provide same credit card details to two different users
40. View the registration email contents for new users
41. Change password for a registered user
42. View change password email content
43. Do not use account for 60 days and login after that time period
44. Login as user, add a product, logout and login again
45. Use correct promotion code for correct product
46. Use wrong promotion code for a product
47. Use a valid promotion code to a product but after its expiry date
48. Use a promotion code more than once for purchase
49. User a private promotion code of another registered user
50. Track the purchase order for delivery
51. Rate a product for its quality
52. Join a group purchase and confirm purchase
53. Join a group purchase and cancel after an hour or day
54. Join a group purchase for more than once
55. Define alert to notify when product price falls into certain range
56. Purchase a product whose price is more than your credit card limit
57. Purchase a product when the product is out of stock
58. View product details from a different country settings
59. File a complaint as a buyer
60. View complaint tracking email content
61. View complaint status on the buyer portal
62. View past order history for a user
63. Modify the user profile after a few purchase transactions
64. Add products in wish list
65. Manage different lists as part of user profiles
66. Comment on a product
67. Comment on a purchase
68. Provide feedback on a purchase
69. Refer a product to another user in the community
70. Use one time shipping plan for a purchase
71. subscribe to annual shipping plans and do a purchase
72. Subscribe to newsletters
73. Unsubscribe to newsletters

74. Freeze a user account
75. Unfreeze a user account
76. Set transaction limits for users
77. Generate reports for today’s purchase
78. Generate reports for purchase for specific products
79. Generate reports for purchase in specific geographies
80. Generate reports for shipping status
81. Generate reports for customer complaints
82. Generate reports on purchase feedback
83. Upload stores details who act as suppliers
84. Upload price details from various stores
85. Upload products and price details from stores in different formats such as xml, csv, Excel etc.
86. Upload products and price details from stores with erroneous records
87. Upload product image contents with static images
88. Upload product image contents with animated images
89. Create survey to selected users
90. Publish a poll to all users
91. Create product promotion codes and publish to selective users or geography
92. Manage shipping and handling charges and terms
93. Manage group purchase settings and products
94. Extend a promotion offer
95. Configure prizes for buyers on specific purchase criteria such as 100000^th buyer etc.
96. Configure corporate purchase accounts
97. Manage out of stock alert settings
98. Manage different payment gateway settings
99. Configure SMS alerts to users
100. View whether purchase details reflect in the CRM thru synchronization

For recorded training programs and online tests, visit us at http://www.openmentor.net

Five angles to look at everything

Test must be looked at both science and art. There must be some structured way to test and there must be ways that are beyond imaginations.

When we want to test any object, look at it from 5 different aspects.

1. Configuration. This means the physical presence of a part in its right place. If this itself is not satisfied, how can we expect the parts to work in the right way? Imagine the brake and accelerator (gas pedal) are interchanged in their positions! Imagine the steering wheel is fixed so low that touches your knee! So the first visual checks ensure, things are in right place.
2. Security. Any system must ensure the safety of its operator or user. Before operating any item or system or machinery, the severity features must be tested, to see if those safety measures work. Before lighting a gas stove check there is no gas smell in the room. Before using the lift, ensure that there is an alarm bell in place. Before connecting a new CD player to power plug, ensure that the adapter is the right one to connect to 110 V or 220 V. See if the keypad lock is fine in a mobile phone.
3. Functionality. This is nothing but the operational feature of any system or item or machinery. Every operation of the system must be tested. When we press the close door button in a list, it must close the door. When we press the ^ button for channels, the TV must switch to the next listener channel.
4. Performance. Speed, consumption and capacity fall under performance. This is also one kind of functionality, but a special one. What would be the speed of the lift (elevator) when it goes up with full load? What is the fuel consumption of a car, when driven at 70mph? This is a key measure that ensuresthe system can cater to a large set of users, to handle large set of information and to run for a longer time.
5. Environment. The behavior of a system may vary, depending on the surroundings. Some features of the system affected by some environmental parameters. The behavior of the tennis prayer changes from grass court to clay court. The performance of a runner changes when he runs on a flat surface and when he runs on a slope (uphill).

If we think from the above 5 angle , any object or system can be judged for its quality. As an exercise, list what you can test in

1) a Vending machine

2) TV and Remote control

3) Instant messenger

List at least 5 points in each category discuss among yourselves.

For free recorded learning content, view http://www.openmentor.net.

SDLC - Coding, Testing, Implementation, Maintenance Phases

Coding Phase

The LLD document contains all the details for a programmer to convert it into a working program. Designed in the right way, the job of the developer is to convert the pseudo code into a programming language in the specified platform. The developer will be given specific guidelines that tell how to code. This guideline includes the naming convention of procedures, variables, commenting methods etc. As per the guidelines, the developer codes and at the end of the coding, he/she compiles the program unit.

By compiling and correcting the errors, all syntax error and removed. Syntax errors are the easy ones to rectify. The logical errors in the programs are the difficult ones to identify and then rectify. By logical error, we mean, the program behaves in a way, that it is not expected to behave. The role of testers is to identify the logical errors at various stages.

Testing

*This section provides only a shorter version of the testing techniques.

Testing is the process of evaluating a system or application, to check whether the application meets all requirements of the client and to detect the errors.

Generally testing can be classified into static testing and dynamic testing.

Again Dynamic Testing is classified into two types: Structural Testing (or) white box , Functional Testing (or) Black Box testing.

Static Testing

Verification activities fall into the category of Static Testing. Static testing refers to testing something that’s not running. It is examining and reviewing it. i.e., to check whether the work done meets the standards of the organization. Reviews, Inspections and Walk-throughs are static testing methodologies.

Example: The specification is a document and not an executing program. When we read it to find out the issues, it is considered as static testing.

Dynamic Testing

Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.

Techniques used are determined by type of testing that must be conducted.

• Functional ("black box") testing.

• Structural (usually called "white box") testing.

Black box testing involves looking at the specifications and does not require examining the code of a program. Tests that examine the observable behavior of software as evidenced by its outputs without referencing to internal functions is black box testing. It is not based on any knowledge of internal design or code and tests are based on requirements and functionality. Nowadays there are automatic code generation tools and code re-use becomes more prevalent, analysis of source code itself becomes less important and functional tests become more important.

Black box testing is easy as it is based on system’s response for a given user’s input. If we know the business functionality of the product, we can do black box testing. On the other hand, white box testing requires programming knowledge to know the internals of the code. Also it is time consuming. So only a developer can become a white box tester.

Unit Testing

Soon after the program is corrected for syntax errors, the program has to be checked for logical errors, at the unit level. Programs may have simple user inputs or outputs thru screens or reports. The inputs must be validated for their format, data type, boundary conditions etc. Also, the elementary functionality of the program must be verified. In most of the cases, the programmers themselves will do this unit testing. Many inputs will be verified in this way and the program unit will be checked for the basic functionality in this phase.

If there are any problems while doing this testing, the programmers will debug the program and the bugs will be fixed and will be tested again for the bug fix. While doing the unit testing, that particular unit need not wait for another unit to be completed. It can be tested independently. Unit testing is also termed as component testing. For example, if we need to test a java class and method, even without any screen, the programmer can test the same. Thus any piece of code, that can be independently executed, can be independently tested as well. This is termed as unit testing.

Integration Testing

When all the individual program units are tested in the unit testing phase and all units are clear of any known bugs, the interfaces between those modules will be tested, to establish that they communicate to each other property via the specified APIs and thus they can be integrated into an application. The integration test may be performed by the independent testers or by the development team members.

System Testing

After all the interfaces are tested between multiple modules, the whole set of software is tested to establish that all modules work together correctly as an application or system or package. This is again performed by independent testes. The testers will have to do the system testing as though they are the end users of the application. Systems testing includes special testing methods like performance testing, interoperability testing, stability testing etc.

Acceptance Testing

After the software product is tested by the SDU in 3 different stages (unit, integration and system), the client will test it, in their place, in a near-real-time or simulated environment. This establishes that the software meets the requirements of the end user. This testing is carried out as though they are using the system in their real office, to mimic the real time scenarios.

Implementation Phase/Support

This Phase will provide users with the documentation and training required to use the system effectively. Data Conversion will only occur once, but user documentation will be required. Deployment of the product will be carried out, on the hardware that is going to be used in production (on live systems). Deployment itself requires careful planning. Once the product is deployed, initial data will be populated, user training will happen.

Release to Production and warranty Period

When the clients to the acceptance testing and finds no problems, then they will accept the software and now they have to start using the software in their real office. It may be a real bank for a banking application. During the acceptance testing also, there may be some bug fixed done to the software. Before the software is put into production (real time environment), the SDU must release the latest versions of the software, which has no known bugs to the client. This may be in a CD or tape or an Internet download. The clients will then install the latest software in their production system and will start using. This is called go-live process.

In the same way every product has a guarantee period software also has a warranty period. Normally it will be a 60-day or a 90-day warranty period for most kinds of software. Depending upon the complexity and size of the software the warranty period may be extended or shortened. During this warranty period, in case of any problems, the SDU has the responsibility to rectify the problem, at no charges. Again, it depends upon the contract, whether to charge for the fix or not and may vary from industry to industry.

Maintenance Phase

After the warranty period, the software enters the maintenance phase. During the maintenance phase, 3 things happen to the software. They are :

• Bug fixing

• Upgrade

• Enhancement

During the maintenance phase, because of some untested scenarios, the software may give errors or logical problems. This has to be fixed. This is same as any other bug fixing. This is similar to any repair works done to a vehicle, by its owner.

In the software field, the software versions are constantly changing and the applications may have to keep themselves upgraded to the newer versions of the software. For example, the anti-virus software must be constantly upgraded to address new viruses, which come very day. If the operating system version charges, it may necessitate to introduce some changes in the programs. So, this kind of upgrade works to the existing software applications, because of operating system or environmental changes or hardware changes may have to be incorporated.

Any software is not all complete and there are enough rooms to add new features to an existing software. For example, today the railways reservation system may not be in the internet; but tomorrow there may be a need to go in the internet way. So, new modules are to be added to the existing system to address this. This is enhancement.

After some time, the software may become obsolete and will reach a point that it cannot be used. At that time, it will be replaced by another software which is superior to that. This is the end of the software. The software will reach its end, when the maintenance cost of the software becomes more than the new software available. Software can become obsolete when the company does not upgrade it to work on new environments such as databases or operating systems. When the software becomes incompatible with the environment, users will move on to another software, dumping the existing one.

For recorded training content, please visit http://www.openmentor.net.

SDLC - First 3 Critical Phases

We have been getting very good feedback from audience of this blog. Even experienced readers convey that they refer this to their team members, to learn complex things in simpler way. Thanks to all.

Software Development Life Cycle

The Various activities which are carried out when developing a software are commonly termed as a software Development Life Cycle (SDLC). The software development life cycle begins with the identification of a need for software and ends with the formal testing of the developed software against the requirements.

A software project is made up of a series of phases; most software projects comprise the following phases:

• Inception Phases
• Requirement Analysis Phase
• Design Phase
• Coding Phase
• Testing Phase
• Implementation Phase
• Maintenance Phase

Inception phase

Request for proposal

The first initiative that happens for the development of a software product, is the need for someone to automate or computerize their system, e.g. a bank willing to automate its day to day activities. When the need is felt by the concerned unit, they will give a formal advertisement in the media that they need a software product for their automation. This may be in newspapers or on internet or private letters known software development people. This process is called Request for Proposal (RFP).

In the real world it is called as tender also, in many situations. When there is a need, the state highways department may want to lay road for 100 miles, at a particular stretch. In that case they will give a tender notice in newspapers inviting people to give their proposals. RFP is a similar one. The tender may contain minimal information about the need; and it may not be sufficient for the bidders. In those cases, the sales department of a software development company will approach people to identify the needs. The sales department will keep its eyes and ears open to see any open tenders, that can fit into their business.

Proposal

When the software development company finds that there is an RFP, they will prepare a formal proposal and sent it to the concerned unit that needs the software product. The proposal will contain: Time frame in which the project will be executed, Milestones of the projects activities and the respective start and finish dates, Cost involved in the project, Number of people likely to work in the project and their skill sets, Hardware and software requirements for the project, an overall architecture of the system, the technology that will be used to develop the software, Credentials of the software development company including annual turnover, manpower, past experience in executing similar kinds of projects etc. The cost and time will be estimated by project manager or any appropriate senior person, who possesses this kind of estimation experience. The success of the project greatly relies on the accuracy of these estimates.

These details will be provided in a single document and will be sent to the concerned unit. This is called Proposal. In colloquial terms, this is called a quotation. Many Software Development Units (SDUs) will send their formal proposal to the unit, which needs the software. Obviously each proposal will differ in terms of cost, time, people etc

Negotiation

When the company receives multiple proposals from various SDUs, they have to identify a suitable SDU, which can provide the required software product with minimal cost, in a minimal time frame, through an optimal technology. To identify a particular SDU among multiple SDUs, the company, which needs the software, may call all of them or a few of them based on the credentials and other parameters stated above for further clarifications. During this process, SDUs will be asked for a lot of technical and functional clarifications and also to reduce the cost and to shorten the time frame. This happens invariably in all projects and this process is called negotiation. After one or more rounds of such talks, the company may identify a suitable SDU as the unit that is going to develop the software. In this process, both the company that needs the software and the identified SDU are in agreement of the terms, in terms of cost, time, technology etc.

Usually the senior management team and sales team are involved in negotiation process.

Letter Of Intent (LOI)

Once an SDU is identified, they will be given a formal letter by the company, which needs the software, stating that they are willing to proceed further in the development process. This is a pre-cursor to signing a contract. This is only an informal assurance that the deal is closed. Also, LOI alone cannot stand as the final document to start work.

.

Feasibility Study

Once the Letter Of Intent is given to the SDU, the SDU may send some people to the client’s place to do a preliminary research to know the feasibility of the automation. This may be for a shorter period. This is called Feasibility Study. In this process, the SDU will come to know about the complexities and the difficulties in implementing a computerized solution.

This study may occur even before the proposal stage, in some cases. But there is a disadvantage for the client, i.e. inviting multiple SDUs to do the feasibility study. If this happens after the LOI is issued, then it will be one SDU, that does this work in a focused manner and this will help the client in passing on the project information in a quick and efficient manner.

Contract

After the negotiation is complete, LOI is issued and the feasibility study is furnished, there will be (may be) another round of re-estimation of the cost and time. But this may not vary in many cases from the original estimates and many clients do not want any further increase in the cost or time. Then the SDU and the client will formally sign a contract, which clearly specifies the timeframe within which the project must finish, the cost involved, the technology to be used, the hardware and software setup etc. This is the commitment document that serves as the basis, throughout the project. The contract will include many clauses regarding the legalities and any other penalty charges in case the SDU is not able to keep up its promise.

There are projects, in which the time is not fixed, but the work is measured in terms of person-days and the cost will be paid on an hourly or daily basis per person. Contract usually contains many legal phrases that describe about payment terms, warranty period, dispute handling and jurisdiction, any other specific terms as agreed in negotiation, protecting the intellectual property rights etc.

Requirement Analysis phase

After the contract is signed off between the SDU and the clients, this phase is the main focus of the project managers and stakeholders. Meetings with managers, stakeholders and the users are held in order to determine the requirements.

User Requirement Specification (URS)

The SDU must now know what the client wants in the software project. To ease the process, many clients (alternate terms for clients are customers or users), prepare formal documents, which describe their need. This document will describe in detail about what is expected out of the software product, from the users perspective. This is called User Requirements Specification. This will use the same terms and nomenclature that the customer uses in the day to day business.

This is the base document for the functionality of the product. This will be prepared and reviewed by the user community, mainly by experienced users. As an example, the URS of Railways reservation system will talk about how the reservation, cancellation etc. are carried out in an actual reservation counter. The very idea is that, these are the activities that are going to the computerized and if these are properly documented, then it will be easy to proceed in the actual product development. In some countries, a few clients write this document in their native language and not necessarily in English.

Software Requirements Specification (SRS)

After the URS is defined, a team of business analysts, who are having a very good domain or functional expertise, will go to the clients place and get to know the activities that are to be automated. This includes thoroughly understanding the URS, item by item. The URS may not be in an understandable language and format, for the developers and testers. So SRS is derived based on URS, to provide clarity to the development team. If the SDU does not know what is to be computerized, it cannot develop software that satisfies the customers. So, understanding the requirements is very essential in software in software development process. Most of the times, the business analysts, together with expert users, will frame a single document, which will serve as both URS and SRS. This way, there will be only one document which will serve as a functional commitment document between the customers and the SDU.

Requirements Collection

The role of a business analyst is very vital to this process. Before we start talking to clients on project features we must know the domain well. The SME (subject matter expert) meets various people who are in charge of the day to day business activities in customer’s core business. For example, if we develop a software for an insurance agent, we must know what he/she does with customer, we must know what detail he/she collects, how they fill up forms, how they arrive at premium amount, who approves it etc. if this can be clearly documented in plain English, the same can be used for development.

The SME must collect all fillable forms, receipts, reference numbers, approval papers, etc. Also the pain areas of customer must be documented so that the same can be computerized.

The SME must talk the same language, jargons, code words, acronyms with the customer, This will create trust with users and they will exchange more information to SME. The SME must make no assumptions. If there are any open or doubtful issues, that must also be documented along with the specs as annexure. Any sample forms must be scanned and attached to the specs. Specs can contain flowcharts as well. See the example flow for a car service centre.

Before going and meeting the client, the SME must do a lot of home work and prepare a clear list of questions. The time one spends with client is very precious and we must not waste client’s time. Simple questions like a checklist will answer complex issues. Eg.

1. How many levels of approval is required for a purchase order?

2. Do you apply service tax for your services or are you exempted?

Once the SME drafts the requirements as described by the customer and end users, the specs must undergo an internal review. The project manager must review the specs. Then the same must be sent to the client for review. The review will clearly bring out the understanding level by the SME on what the customer wants. There are chances that the SME missing some of the points told by customer, or the SME understood it in a different way or the SME added something that the customer did not want/tell. Hence customer must review the specs very carefully. Once customer raises questions on the specs, SME must correct those areas and resend for review. This may take a few back and forth emails, a few telephonic calls etc. Finally when the customer says, “Yes, this what I want in the software”, ask him to send an approval email or to sign off and printed version of specs.

Design Phase

High Level Design (HLD)

Based on the SRS, now the software systems analysts will take over to convert the requirements into a usable product. In order to achieve this, the systems analysts must design the application, which will help the programmers in coding. In the design process, the product is to be broken down in independent modules and then taking each module at a time and then further breaking them to arrive at micro levels.

There are 2 different approaches followed in designing,

1) top-down approach and

2) bottom-up approach.

In top-down approach, the product is broken continuously into smaller levels till it cannot be broken to further levels. In bottom-up approach, the smaller levels and designed first and the used as building blocks to go to next higher level till we reach the complete product level.

The HLD document will contain the following items at a macro level. In HLD, the systems analyst describes what is to be done in the product. It will not go in depth into each component of the product.

• List of modules and a brief description of each module.

• Brief functionality of each module.

• Interface relationships among modules

• Dependencies between modules (if exists, B exists etc.)

• Data elements that are used by customer

• Overall architecture diagrams along with technology details.

This document is one step ahead SRS, to convert the requirement into a product. This is mostly a single document, for small to medium size projects. But if the application is large, then there may be multiple documents, which form the whole HLD. Each document may describe a separate module.

Low Level Design (LLD)

HLD contains details at a macro level and so it cannot be given to programmers as a document for coding. So, the systems analysts prepares micro level design document, called Low Level Design. This document describes each and every module in an elaborate manner, so that the programmer can directly code the program based on this. There will be at least one document for each module and there may be multiple LLDs for a module, depending upon the complexity of the module.

The LLD document will contain the following sections.

• Detailed functional logic of the module, in pseudo code.

• Database tables, with all elements, including their type and size

• All interface details with complete API references ( requests and responses)

• All dependency issues between modules

• Error message Listings

• Complete UI design of how each screen looks like

The HLD and LLD phases put together is called Design phase. Design must be done only by experienced people. Design itself has its own guidelines to be followed; most of the times, people use design patterns to find out what will be the best design for a product. Already there are many experts in the world, who have designed big products; they had published the way they designed. Instead of reinventing the wheel, we can try to reuse those already proven designs, if they fit our software.

For free learning material, visit us at www.openmentor.net.