Chartered Accountants and Software Industry

“Software Testing is skill of mind”. It is an art which one can learn and practise. It depends on individual’s instinct to learn new things and adapt to changing environment. Anyone who wants to learn software testing can learn. You need to have passion for it if not still you need to have an urge to learn.

Information technology is dynamic in nature, application which has been launched today may demand up-gradation tomorrow or may become obsolete day-after, you just can’t predict. Any profession which stops learning new things it stagnates. Growth stops. One day you get dead end in your career if you stop learning. Software testing is ongoing process. Every project, every question, new context would teaches you new lesson. It is most happening field.

One who wish to do career can learn skills like exploration, asking questions, investigating problems, identifying bugs or writing a bug report but first understand what is your interest. If you do not come to any conclusion that’s OK because very few can find their interest so easily. One thing in mind that whatever decision you make, thing that matters most is how to make it right and that’s in your hand, choose the career in which you have passion. If you had seen movie ‘3 idiots’, you won’t forget one dialogue.

"Run behind your passion, success will run behind you."

Quality of human to stay student forever would help him to grow in the field you selected as a career option. So ask yourself ‘How good are you as a student?’ you must be willing to learn. It’s not on the teacher who teaches, having high regards in that field but what is a point if student does not want to try those lessons?  That’s where you may find it tough when it comes to demonstration or performing what you learned. You can make your career life easy by learning and practically implementing what you learned.

I am Chartered Accountant by profession. I have come across a numerous people asking me what you are doing in the Software field? I think Chartered Accountancy do not restrict its scope in Accounts and Tax otherwise the subjects like Computers, ERP would not have been part of the CA syllabus. Being a Chartered Accountant, challenging status quo, setting up expectations, demanding the deliverable, keen eye on the quality and issues are keys to success when I am operating out in Software field.

This is my version of entering the field of Software applications. Currently, in the software industry the opportunities are twofold. One, in this industry there is and will be a demand for accounts and finance people. The second and the more recent area is that of consultants, who interface with the technical team and the clients. These consultants facilitate effective communication between the technical team and the client. Finance professionals with their grounding in information technology will be ideally suited for this industry. They liaison with the clients, fully comprehend their business requirements, review the contract, analyse and evaluate the project. The job content is very different and there is a lot of variety available in this kind of a job. For the first time a financial executive is interacting directly with the clients. It gives him the opportunity to be seen in commercial roles due to their orientation of work with different clients.A chartered accountant with his knowledge in accounting , taxation and ability to analyse can understand the implication of systems on entity.Impact of rapid industrialisation, computerisation, and globalisation has had tremendous effect on scope and opportunities for CA's.

CA’s role spans throughout the life cycle of implementation which includes stages like current business process study, solution design, solution build, data migration, user training and post-production support.

Initiation and Internal Planning: Defining the scope of the project. Deliverable for this phase include a general outline of the implementation schedule and basic project milestones.

Business Process Analysis: Studying the existing process and identifying key business areas. It includes understanding and documentation of process workflows and identifying the areas for automation.

Solution Design: Details how the product and processes will be aligned to achieve the desired objectives. It involves iterative process re-engineering and finalising the future business processes.

Solution Build: The goal is to build, test, assess, and refine the initial prototype. The deliverable for this phase is a prototype demonstration for the executive sponsor, steering committee and key users.

Acceptance Testing: The Company’s core team receives a greater degree of training in the software’s architecture and technology, capabilities, maintenance, and usage.

Transition: Once the prototype has been refined and accepted, it’s expanded and built to full production scale.

Documentation: This also plays an important role for smooth transition of the new system and maintaining the same in future. Most of the companies follow standard policies of documentation generally outlined by the ERP vendors. A good and detailed documentation helps in a great way in successful implementation and streamlining the processes.

Skill required to join the software industry:

• Basics of Computers
• Because of the consulting profile, it requires much more than good academic knowledge and domain experience.
• Soft skills : Good communication, presentation skills, Persuasive skills.
• Analytical skills : High degree of analytical, problem-solving skills, creative thinking, questioning the status quo.
• Team skills : Relationships skills, cooperation, networking, handling disagreement.
• Project management skills :Organising and prioritising work.
• Customer orientation : Commitment for customer satisfaction.
• Fast learners : Require quick grasping of product functionalities, processes of different industries and continuous updating with new technologies.

Do not worry what world says negative about software testing. You take good things and throw rest because that does not help to grow anyway.

• You will grow intellectually: Business Analyst and Software testing has huge scope to learn intellectually because your mind gets involved in many test ideas, bugs and bug reports.
• You will learn how to be creative: You need to come up with Ideas which would help you to find bugs because bugs are not so easy to find.
• You will learn to form your own judgement:  People including me would accept someone’s statement as it is without even bothering about the truth behind that statement. I stopped it because testing taught me that it’s quite harmful.
• You will be wise in your thoughts:   When you learn how to find bugs and how you need to convince stakeholders that this would impact customer or their business then you would start getting real business sense and customers.
• You will improve your skills: Testing would help you to improve your skills viz. communication, observation, judgement, analytical, problem solving and questioning skills and that becomes your asset for your career.
• You will form good habits: When you would start taking interest in this field you will learn that you need to read books, articles and blogs. You make a habit of reading which is good because that would help to learn testing better way. You try to be with like minded people because you also want to share your thoughts and listen to theirs. You want to be a part of testing contests because you are also confident to solve them.
• You will be a creator: Every new project you would find an opportunity to create new methodology. Isn’t it great?
• You will start accepting challenges: When you would start learning new domain, technologies and test techniques then this kind of attitude would help you to survive in this ever changing digital generation.

Read, Follow, Introspect rather Worship

The ‘Bhagwat Geeta’  has been studied, criticized over thousands of years considering different dimensions of the life. In the previous post, I have enlightened readers on ‘Geeta’s different dimensions with changing scenarios, human perceptions, experiences and learning's. Apart from studying this philosophy, following the principles as way of life-living, a class of people started debating the philosophy as if the learned ones like ‘Raj-purohit’, ’Pandits’ even marketing these principles under the grounds of religious thoughts. Hence a loads of mis-conceptions rose in the minds of general public who are illiterate, superstitious and poor and blind followers of religion instead of creating life enlightenment.

In the great epic of ‘Mahabharata’, the Lord Shri Krishna said to have delivered ‘Geeta Shlokas’, knowingly-unknowingly this great philosophy become the ‘Dev-Vani’ (God’s Saying). Instead of following the thoughts on ‘Karma’, its adherence to have better life. People started worshiping the book as  ‘Holy Religious Book’, Here I would say, the core purpose of ‘Geeta’ thoughts are defeated.

By ‘Geeta’, Lord Krishna, reminded Arjuna about his duties as ‘Kshatriya’ (Warrior). The thoughts depicted in ‘Geeta’ are towards following ‘Karma’, duties entrusted with every humans as part of living creature, may be towards himself, family, society, country and entire human beings. In such situation, how come this philosophy can be restricted its to holy religious book. This philosophy instigate ‘Karma’

Indian society is made up of different classes. One who dictates, like Brahmin Society (Who performs religious duties) and other blind follows. With caste system and deprivation of lower castes from seeking education, the former class has successfully ensured that other castes should blindly follow them on the religious dictations which were their means of living. This class started mugging the ‘ Geeta Shlokas’  as part of earning livelihood instead spreading the living principles of Karma-Yoga.

‘Geeta’ thoughts are for knowledge and enlightenment. Its way from known world to un-known world of knowledge. Great Saint – Shree Shankaracharya considers ‘Geeta’ as ‘Science of Living’. Marathi Saint – Dnyaneshwar Maharaj treated this philosophy as ‘Adhyatma’, knowledge about self and soul. The Lord Krishna while enlightening ‘Arjuna about the duties as warrior, ensured that Arjuna introspect himself about his purpose of living, objectives, duties.

There is one tale about ‘Swami Vivekananda’. While searching the ‘Guru’, Narendra, visited Swami Ramakrishna Paramahans Math(Holy Temple). Swami Rama Krishnaji were testing aptitude level of students who were studying in ‘Math’ - “Who are you?”, every student was responding to Swamiji with his name, surname and caste. One by one, Swamiji reached to Narendra and enquired about him, “Ko- Aham?” (Who I am?) responded Narendra. “I have  come all the way from Calcutta to learn who I am?.” After studying ;Geeta’ wiith Swamiji, this student become great Hindu Philosopher “Swami Vivekananda'” who has learned about himself, his soul, purpose for which he had born.

Unlike holy religious book, ‘Geeta’,  do not promote blind faith but respect Knowledge, learned behavious, insight, knowledge about self-soul. Each and every dimension of life is validated, inspected with time may be its for decade, century or thousands of years – Its not changed. 

Assumptions in Software Testing

Software testing and Assumptions are quiet interlinked. Entire Software Development cycle is based on use of Assumptions,

Let us start with requirement phase. While documenting requirements the Business Analysts may make assumptions viz. information about few conditions and/ or associated behavior is missing, interpreted differently, hence perceptions are given more importance than facts, complex system behavior need simplicity in understanding etc.

These assumptions become input for designers/architects, developers and they implement without questioning them or asking for evidences. While designing the application Designers too add their assumptions on which applications are built like requirement will certainly not change, hence we may not factor changes in the design, data source will be XML file, as previous projects used XML.

The developers also continue to take the same path as others did. They make assumptions on input parameters for a function, interfaces

What is ‘assumption’& inference?

A thing that is accepted as true or as certain to happen without proof. An assumption is something we take for granted or pre-suppose whereas inference means a conclusion reached on the basis of evidence and reasoning

We interpret based on our beliefs. Our beliefs are based on assumptions. Assumptions can be justified or unjustified, depending on reasons that you provide. Inference is exactly opposite to assumptions and we live with both of them. We naturally & regularly use our beliefs as assumptions to make inferences from the situation. Both things can be justified, unjustified, accurate or inaccurate. It depends on person to person & their point of view.

When it is everyday life or work we take things for granted as a human we cannot question everything, every time.Human makes hundreds of assumptions consciously & sub-consciously. Most of them are justifiable, however many aren't.

Testing is fact based activity for that we require assumptions. One has to make certain assumptions to see if it’s true to build your testing results

A tester should learn to make accurate assumptions about the proposition & practice making justifiable inferences. A Skilled Tester should be able to justify his/her assumptions when challenged.

Awareness of assumptions is required to lead good work. Various general assumptions which are made during the testing are:

• Programme Manager will be responsible for giving a timely sign-off on the deliverables,test data covering all the testing scenarios, procuring any tools’ licenses required for the successful facilitating testing activities.
• Functionalities are delivered as per schedule for testing.
• It is assumed that all the Signed off Functional Specification documents requisite test environments/applications with product parameters setup done and interfaces will be provided on start of Testing execution i.e. The complete build is expected to be available on day one of testing
• Planning estimates includes testcase designs/Testwares for CRs & modification of Regression packs as per the scope. Estimates include cost of one review and one rework based on the review comments of the same by BA & TO.
• Code is fully Unit tested and closure report to be shared by development team before handing over code to testing team.
• Any impact to testing budget due to delay in Build, Environment, Defect fix, Interface availability will be handled through Change Request process. Changes if any to the requirement / functional specifications documents during SIT will follow the change request process needing separate budget and estimate.
• Application and environment should be stable. There should be no downtime or error in functionality. Environments, connectivity, User access (Testers), IP opening, Firewall opening to be taken care by the Infrastructure team.
• Sample Test data is available OR Information on how to generate the same is shared.
• SLA for defect fixing is considered to be Sev1 = 4 Hrs, Sev2 = 8 Hrs, Sev3 = 2 Days

Always challenge, question and justify your assumptions. While finalizing the testing assumption one should be sure about the basis, criteria and testing grounds on which these assumptions are finalized. Wrong assumption can impact the testing and ultimate objective of testing is sacrificed. Below is the list of 9 factors I understand that makes assumptions more dangerous.

1. Create confusion – The tester may assume a ground while start the tetsting which may not be acceptable to development team being the specified condition on which testing assumption made ever exist e.g. if a tester assumes that she is working on a build which is latest but latest build is not yet deployed by development team then she might be raising a bug which won’t be acceptable  by development team. This might create confusion in test and development team.
2. Time consuming – Tester should make assumptions after thorough validation of the events, mere assumption on inputs received from support leads to time loss both at testing and development. Secondly, the assumption made need to be discussed with the developers to ensure they are in sync. Say I received data from other team which I presume is valid data. After few tests I found few bugs which I reported to development team. Programmer claim after some investigation that the data used for test is not valid resulting to loss of time of testers and developers.
3. It stops tester’s ability to think other possibility – As tester, he/she need to evaluate all the possible events by which an application fail or do not meet the desired conditions. By making assumption, tester is restricting the testing as the particular event is already been considered or presumed anticipated behavior of the application. 
4. Limit the scope of testing – A tester need to anticipate all the possible user behavior while using the application under different conditions. If a tester assumes that a user will not behave differently, then tester is limiting the scope of testing. Tester will not consider other possible scenarios just because of assumptions he makes. Tester creates tests based on some mental models based on their assumptions. This might reduce other possible scenarios. 
5. Fail to notice new bugs – Suppose a tester knows that he has already tested this functionality then she might overlook that function. She might misses new bugs. 
6. Reporting False Alarm – Tester is supposed to discuss the assumption with developers while testing an application. Suppose tester is testing based on requirement but if she fails to verify her assumptions with stakeholders then she might raise false alarms. Though the actual feature works appropriately but her assumption declares it as bug. 
7. Lose stakeholder’s trust – Tester’s responsibility is to test the applicatons irrespective of the application is under change or run. If testers raise false alarms then chances are high that stakeholder loses trust in tester.Suppose Tester think that application under scope of testing is already tested and he declares (assume) that function works. If anything goes wrong in production then management may question the testing ability of a tester. 
8. Lose credibility – When someone loses trust in you, it means that you also lose credibility. Stakeholders stop assigning bigger responsibilities, they start taking testers for granted. 
9. It costs – The Business user or the sponsor exactly aware of the requirement on the basis of which application is designed. If the tester make wrong assumptions which contradicts with the business users/requirements then ultimate objective of testing is at stake. If assumption made is related to cost or revenue then tester may lead to cost impact for the organisation.

Geeta…. Yesterday and today

‘Shree Madbhagwatgeeta’ has been guiding not only Indian Society but also entire human being for past 2500 years. A millions of people had read and still reading the ‘ Geeta’  and trying to follow the noble path suggested in this holy book. A thousands of people had written, explored and tried to express their thoughts on this philosophy. Great Marathi saint – Dyaneshwar Maharaj has first transcripted the thoughts on Geeta in Marathi. Great Hindu philosopher, Babu Aravind Ghosh, Lokmanya Tilak, Mahatma Gandhi, Vinoba Bhave and others had written on this great philosophi-religious book created by Great Saga Vyasa.

During the Mahabharata war, Arjuna had been advised by Lord Krisha as “Whatever you are doing in your life, instead of doing it for yourself, do it for myself (Lord Almighty) So, the repercussions arising from your activities will not impact you. You will be freed from your Good/Wrong doings and will ultimately align yourself with Me, which is Godliness”. In the above statement, Lord Krishna suggests the ultimate objective of living for the human being.

‘The Geeta’, if we say is part of Mahabharata, but in real terms Mahabharata won’t have been a great novel without ‘Geeta’. Over the 2500 years, the Geeta thoughts or philosophy has not become redundant or replaceable but its still being explored and new meanings are being sought. Let’s take an example of Carbon, we can derive A diamond, sugar and coal from the carbon material which has varied intrinsic values and usage but the basic element of all the above remains the same. Likewise, the thoughts expressed in the Geeta are immortal however the meanings derived or perceived by the generations are changing with generations.

The ‘Geeta Dnyan’ (Knowledge) had been given by Lord Krishna to Arjuna a 2500 years back however you still refer the relevance in today’s life. The Mahabharata war was fought among Kouravas and Pandavas but it was not war among the two armies, it was among the noble thoughts vs. bad thoughts which is still on and will continue forever till the human exists.

Over these thousands years, humans have made enormous progress in terms of living, culture, habitat, lifestyle and technology. Now human can get whatever he desires by his fingertips. Human being also tried to overcome the adverse natural condition and made it habitat for living which earlier was considered impossible or un-imaginable. A man not only reached the other end of earth but have explored Moon, Mars and now trying to explore the new universe outside ours. Everything has been changed but not changed in Human nature, his attitude it’s still the same. The greed for power, ownership, discrimination by skin, money as well classes like rich-poor & sufferings still exists. A man not only cherishes the love, happiness, devotion and sacrifice but also endeavor the hatred, lust and selfishness. All these mixture of emotions lie in the Holy book of ‘Geeta’

The important thing about ‘Geeta’ is that it is being perceived differently by individuals, may it be experts, critics or a common man. Moreover one will interpret the same ‘Shlokas’  differently over a different period of time… Isn’t it more amazing.

‘Geeta’ though a well written book, but can be perceived differently by individuals by their experiences of life and survival. So for every individual, the thoughts and underlying meanings to it changes. It is not necessary that ‘Geeta’ lesson learnt or vision I have sought necessarily be same with you who is reading this article.

Modi, Taxila and We

The Hunkar rally of BJP Prime Minister aspirant “Narendra Bhai Modi” was more than successful and challenged the ruling party of Bihar and India. It is obvious that, the ruling leaders need to criticize the speech of the leader to prove the inadequacy of the leadership.

As usual, he was named as ‘Feku’ being over-projecting the development in Gujarat but ever anybody spoke to Gujarathi people to sought their opinion on the Narendra Bhai’s development and his attempt for good governance? Sadly the answer is NO.

Secondly, inadequate study of the Indian History as Taxila Univerisity located in Bihar and Great Alexander lost the battle in Ganges. Whether Narendra Modi spoke on the above lies or twisting the history, let me leave it to viewer of the attached video of Hunkar Rally. 

But, there is one saying “ Learn from the History and create The HISTORY”. From History we can learn that Great Universities Takshashila and Nalanda lies in the Hindustan. Like Oxbridge (Combination of Oxford and Cambridge) we call them as Pride of Nation – Hindustan, never said to have located in same region. I don’t think its matter of criticism when there lies only ruins. The Great Alexander was lost the battle whether at Sutlej or Ganges are of least importance when we talk of Hindustan. His Victorious movement was stopped in Hindustan, our Motherland.

I am not sure how many of us really know about our Glorious History of Hindustan, we being the slaves of lifetime, learn the American Revolution, French Revolution etc in our school days. Nobody teach us about our own country’s great history, tradition, achievements as far as social, human development.

In a 2010 report, Global Heritage Fund identified Taxila as one of 12 worldwide sites most "On the Verge" of irreparable loss and damage, citing insufficient management, development pressure, looting, and war and conflict as primary threats

Ancient Takshashila was situated at the pivotal junction of India, western Asia and Central Asia. Owing to its strategic location, Taxila has changed hands many times over the centuries, with many empires vying for its control. When the great ancient trade routes connecting these regions ceased to be important, the city sank into insignificance and was finally destroyed by the nomadic Huns in the 5th century CE.

Takshshila is reputed to derive its name from Takṣa, who was the son of Bharata, the brother of the Hindu god Rama. Legend Takṣa ruled a kingdom called Takṣa Khanda, and founded the city of Takṣhshila. It is also mentioned, in the geat Hindu epic Mahābhārata, the Kuru heir Parikṣit (grandson of the Arjuna) was enthroned at Takṣaśilā. The city of Takshashila is also described in the Jataka literature as the capital of the kingdom of Gandhara and as a great centre of learning.

Takshashila became a noted centre of learning (including the religious teachings of Hinduism) at least several centuries BCE, and continued to attract students from around the old world until the destruction of the city in the 5th century. At its height, it has been suggested that Takshashila exerted a sort of "intellectual suzerainty" over other centres of learning in India. Generally, a student entered Takshashila at the age of sixteen, after completing the primary and secordary education at home chiefly to reach the ends of knowledge in specific disciplines. The Vedas, the ancient and the most revered Hindu scriptures, and the Eighteen Silpas or Arts, which included skills such as archery, hunting, and elephant lore, were taught, in addition to its law school, medical school, and school of military science. Students came to Takshashila from far-off places such as Kashi, Kosala and Magadha, in spite of the long and arduous journey they had to undergo, on account of the excellence of the learned teachers there, all recognized as authorities on their respective subjects.

Taxilla was considered to be amongst the earliest universities in the world. No external authorities like kings subjected the scholastic activities at Takshashila to their control. Each teacher was enjoying complete autonomy in work, teaching as many students as he liked and teaching subjects he liked without conforming to any centralized syllabus. For a specialisation in a subject took around eight years, though this could be lengthened or shortened in accordance with the intellectual abilities and dedication of the student in question. In most cases the "schools" were located within the teachers' private houses, and at times students were advised to quit their studies if they were unable to fit into the social, intellectual and moral atmosphere there.

Knowledge was considered too sacred to be bartered for money. Financial support for running the university; free boarding and lodging came from the society at large, as well as from rich merchants and wealthy parents. Though the number of students studying under a single Guru sometimes numbered in the hundreds, teachers did not deny education even if the student was poor. Students had to do manual work in the household. Guru Dakshina was usually expected at the completion of a student's studies, as a mere token of respect and gratitude - many times being nothing more than a turban, a pair of sandals, or an umbrella.

The process of teaching was critical and thorough- unless one unit was mastered completely, the student was not allowed to proceed to the next. Both theoretical and practical aspects of the subjects were taught, and particular care was taken to ensure competence of students in case of subjects like medicine, where improper practice could result in disaster. No examinations, no convocations were held upon completion, and no written "degrees" were awarded, since it was believed that knowledge was its own reward. Using knowledge for earning a living or for any selfish end was considered sacrilegious.

Takshashila had great influence on the Hindu culture and Sanskrit language. It is perhaps best known because of its association with renowned disciples

• Chanakya, also known as Kautilya, the strategist who guided Chandragupta Maurya and assisted in the founding of the Mauryan empire. The Arthashastra (The knowledge of Economics) of Chanakya, is been composed in Takshashila.
• The Ayurvedic healer Charaka also studied and taught Medical at Taxila.
• The ancient grammarian Pāṇini, who codified the rules that would define Classical Sanskrit, has been part of the community at Takshashila.
• Jivaka, the court physician of the Magadha emperor Bimbisara who once cured the Buddha, and the enlightened ruler of Kosala, studied in Takshashila

Currently, Taxila is situated about 32 km (20 mi) north-west of Islamabad and Rawalpindi; just off the famous Grand Trunk Road. The town lies 549 metres (1,801 ft) above sea level. It is the head-quarters of the Taxila Tehsil in Rawalpindi district, Pakistan. Renowned archaeologist Sir Alexander Cunningham rediscovered the ruins of Takṣaśilā in mid-19th century. In 1980, Taxila was declared a UNESCO World Heritage Site. In 2006 it was ranked as the top tourist destination in Pakistan by The Guardian newspaper

Defects in Software Testing

Objective of Software testing is to provide independent view of the software to allow the business to appreciate and understand the risks of software implementation. It is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.

Software testing can be stated as the process of validating and verifying that a computer program/application/product:

1. meets the requirements that guided its design and development,
2. works as expected,
3. can be implemented with the same characteristics,
4. and satisfies the needs of stakeholders

A Software Defect / Bug is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectations (which may not be specified but are reasonable). In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected results.

Software Defects/ Bugs are normally classified as per:

Severity / Impact- Defect Severity or Impact is a classification of software defect (bug) to indicate the degree of negative impact on the quality of software. Severity or impact is broadly categorized in 4 classes.

• Critical (Severity 1): The defect affects critical functionality or critical data. It does not have a workaround. Example: Unsuccessful installation, complete failure of a feature.
• Major (Severity 2): The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.
• Minor (Severity 3): The defect affects minor functionality or non-critical data. It has an easy workaround. Example: A minor feature that is not functional in one module but the same task is easily doable from another module.
• Trivial (Severity 4): The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors

Probability / Visibility - Defect Probability indicates the likelihood of a user encountering the defect / bug. If the user easily identifies a bug in rarely used functionality then it will be considered as High priority and vice-versa. Defect probability is broadly classified in 3 categories:

1. High: Encountered by all or almost all the users of the feature
2. Medium: Encountered by about 50% of the users of the feature
3. Low: Encountered by very few or no users of the feature

Priority / Urgency - Defect Priority indicates the importance or urgency of fixing a defect. Though priority may be initially set by the Software Tester, it is usually finalized by the Project/Product Manager.Priority is quite a subjective decision; do not take the categorizations above as authoritative. However, at a high level, priority is determined by considering Business requirement, severity type, probability, available time and resources. Priority can be categorized in following levels:

1. Urgent: Must be fixed in the next build.
2. High: Must be fixed in any of the upcoming builds but should be included in the release.
3. Medium: May be fixed after the release / in the next release.
4. Low: May or may not be fixed at all. 

· 

Related Dimension of Quality – When someone says “This software is of a very high quality.” you might want to ask “In which dimension of quality?”Software has below dimensions of quality.

• Accessibility:The degree to which software can be used comfortably by a wide variety of people, including those who require assistive technologies like screen magnifiers or voice recognition.
• Compatibility:The suitability of software for use in different environments like different Operating Systems, Browsers, etc.
• Concurrency: The ability of software to service multiple requests to the same resources at the same time.
• Efficiency: The ability of software to perform well or achieve a result without wasted energy, resources, effort, time or money.
• Functionality: The ability of software to carry out the functions as specified or desired.
• Installability: The ability of software to be installed inspecified environment.
• Localizability: The ability of software to be used in different languages, time zones etc.
• Maintainability: The ease with which software can be modified (adding features, enhancing features, fixing bugs, etc.)
• Performance: The speed at which software performs under a particular load.
• Portability: The ability of software to be transferred easily from one location to another.
• Reliability: The ability of software to perform a required function under stated conditions for stated period of time without any errors.
• Scalability: The measure of software’s ability to increase or decrease in performance in response to changes in software’s processing demands.
• Security: The extent of protection of software against unauthorized access, invasion of privacy, theft, loss of data, etc.
• Testability: The ability of software to be easily tested.
• Usability: The degree of software’s ease of use.

Related Module / Component– This defect category further classify the defect in module or component where defect lies and reported. This give clear idea to developers where to look for the defect and accordingly run the simulation process.

Phase Detected– This is very important when we consider the System Development life cycle and testing. In testing phase, there are four phases involved viz. Unit testing, Integration Testing, System Testing and Acceptance testing. The phase, in which defect detected and type of defect reported in line with severity, probability has severe consequence in implementation to production.

Phase Injected - Phase Injected can be known only after a proper root-cause analysis of the bug.Phase Injected indicates the phase in the software development lifecycle where the bug was introduced. There are 3 phases of code development viz.

Requirements Development – 

Requirements are the details describing an application's externally-perceived functionality and properties. Requirements are ideally clear, complete, reasonably detailed, cohesive, attainable, and testable. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods and software tools are available depending on the particular project.

If the defect is injected at the time of requirement finalization, then entire code is built on the wrong ground. This code will not be acceptable by the user and will discover at very later stage of testing. The flaws in the requirement definition will be carried forward the in the code design, coding and formulation and deployment. The testers won’t trace the defect being the Business requirement document will the base documentation in the devising the testwares. They are sub-categorized as :

• Business Requirement - The functionality is not as per the desired requirement specified in the Business requirement document or there may be addition in the requirement due to change in the delivery timelines. Defect reported may be on account of difficult to understand the requirement, non-compliance to regulatory standards, contradictory statements in the documents, incorrect statement etc.
• Non-Functional - The requirement though important for the functinality however does not impact the functionality of the application as per the scope document.
• Operational - There may be change in the functionity requirement or modification as per the changing market conditions or operational requirement.

High Level Design&Detailed Design - 

Good Design' could refer to  'functional design' or 'internal design'. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works as expected when implemented. Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements or user stories.

The defects introduced in design level are harder to deal with; developers built exactly what they were told to but unfortunately the designer made some mistakes so there are defects in the design. Unless Programme Managerchecks against the requirements definition, tester will not spot those defects during testing. When such defects are reported, they will be hard to fix because design changes will be required. They are sub-categorized as :

• Functional :If the functionality of the application is not working as per the Software requirement specification(SRS), it is functionality defect.
• Technical :A technical defect exists if the product “departs from its intended design even though all possible care was exercised in the preparation and marketing of the product So, if the product was inadequately assembled or if the materials or components were not consistent with those specified design.

Coding& Deployment – 

'Good code' is code that works, is reasonably bug free, secure, and is readable and maintainable. Some organizations have coding 'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is too many or too few rules. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks' pair programming, code analysis tools, etc. can be used to check for problems and enforce standards.

Issues related to coding & deployment are not severe being these are easily spotted and corrected during testing, because tester can see the product does not meet its design specification. Coding defects can be broadly summarized as :

• Build/Code : A failure or flaw in a program that produces undesired or incorrect results. It’s an error that prevents the application from functioning as it should.
• Configuration :System software/application need to be configured at compile time to tailor it with respect to a broad range of supported hardware architectures and application domains. If the there is no such compilation resulting to error in application performance.
• Documentation: A defect in a user manual, reference manual or on-line help that gives incorrect information or fails to give information relevant to a problem. Requirement is not clear to the reviewer. Also includes ambiguous use of words – e.g. Like, such as, may be, could be, might etc.

Deploy-Test environment - 

Test environments differ from production environments in terms of operating systems, patch levels, software versions, configuration, etc. The wider the gap between the test and production environments, the greater the chance of an application failing after being deployed or a defect leaking into live systems. Further, configuration changes made in response to errors often go untracked, causing errors when applications are moved into production. They are sub-classified as :

1. Connectivity/network : Internal or external to application interfacing error, Incorrect handling of passing parameters, Incorrect alignment, incorrect/misplaced fields/objects, un friendly window/screen positions
2. Hardware/Operating system-Application framework: Hardware issues, memory leaks, Windows-type interfaces, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications will result in defect related to Operating system/application framework.

Test Defects - 

These are the defects generally reported on account of Testing error. Mis-understanding or mis-communication about the testing requirement viz. test scripting error. They are sub-classified in :

• Data - Local to Application: Incorrect data population / update in database. Error in the database schema/Design.
• Duplicate Defects: Defects which are linked to either of previously logged defect and resolution to that defect will automatically resolve the issue.
• Mainframe Data: Defects reported while connecting to Mainframe through web based applications.
• No Fault found: While re-testing the defect at devlopers end, if the defect is not reported on the code, such defect logged can be classified as 'No Fault found'.
• Reference data: Error reported in connection with reference data on account of incorrect data, inconsistent data, matching or linking or batch/real time connections.
• Script Error: Inadequate/ incorrect/ misleading or missing comments in the test script. Missing or Inadequate or irrelevant or ambiguous functionality in scripting.
• Unreproducible: Bug is not reproducible, in essence we are indicating that at the present time, insufficient detail is known about the whole set of circumstances. The bug is able to be reproduced, but we aren't able to do it.
• User error: The requirements have been performed falsely. Wrong procedure observed by user while testing. 

Risks in Software Testing

Testing is inherently a risk-based activity. In software testing, RISKs are the possible problems that might endanger the objectives of the project stakeholders. It is the possibility of a negative or undesirable outcome. As testing is the last part of the project, it’s always under pressure and have time constraint. To save time and money you should be able to prioritize your testing work. How will prioritize testing work? - Exhaustive testing is impractical for most applications under development. Exceptions include applications that support very high risk processes, such as air traffic control, nuclear station operations, defense systems, and so on. The project team must design a test strategy that utilizes a balance of testing techniques to cover a representative sample of the system in order to minimize risk while still delivering the application to production in a timely manner.

Test manager’s responsibility is to determine the test methodology to achieve the greatest level of confidence in the application under development. Risk is a major driver in the test planning activity. A risk has some probability between 0% and 100%; it is a possibility, not a certainty. When conducting risk analysis, two major components are taken into consideration:

• The probability that the negative event will occur.
• The potential loss or impact associated with the event.

The test manager must determine the appropriate amount of testing to perform based upon the risks associated with the application. These risks can arise from the newness and reliability of the technology being used, the nature of the application, or from the priority of the business functions under test. The amount of testing that should be performed is directly related to the amount of risk involved.

There are numerous testing approaches used by Test Managers while assessing risk in the Testing like Analytical, Model Based, Methodical, Standard compliant, Dynamic or exploratory and regression-averse. Understanding the risk-based nature of testing is the key to dealing with the chronic problem related to application testing.

Some of the primary testing risks include:·

Not Enough Training/Lack of Test Competency

Competencies are the knowledge, understanding, practical and thinking skills needed to perform effectively to the standards required in employment. They are identified and demonstrated through sets of behaviors that encompass the skills, knowledge, abilities and personal attributes that are critical to successful role accomplishment. Developers are often trained to design and code the application however tester are not. The majority of IT personnel have not been formally trained in testing, and only about half of full-time independent testing personnel have been trained in testing techniques. This causes a great deal of misunderstanding and misapplication of testing techniques. Many tester confirms that they learnt testing technique on the job while carrying out testing on the projects.
Test Environment

The work environment is not conducive to effective and efficient testing. A testing environment is a setup of software and hardware on which the testing team is going to perform the testing of the newly built software product. This setup consists of the physical setup which includes hardware, and logical setup that includes Server Operating system, client operating system, database server, front end running environment, browser (if web application), IIS (version on server side) or any other software components required to run this software product. This testing setup is to be built on both the ends – i.e. the server and client. Sometime issues reported in Internal or external to application interfacing error, Incorrect handling of passing parameters, incorrect alignment, incorrect/misplaced fields/objects, and unfriendly window/screen positions. Hardware and operating system issues like Windows-type interfaces, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications will result in defect related to Operating system/application framework.

Test environments differ from production environments in terms of operating systems, patch levels, software versions, configuration, etc. The wider the gap between the test and production environments, the greater the chance of an application failing after being deployed or a defect leaking into live systems. Further, configuration changes made in response to errors often go untracked, causing errors when applications are moved into production.
New technology

The new focus on client/server, Intranet, and Internet applications has introduced even more risk to the test process. These multi-tiered systems are more complex than traditional mainframe systems, and therefore have a higher level of risk associated with their testing and implementation. Security, performance, availability, complex component integration, and a team new to the technology are just a few of these new risk factors. With advancement of technology the developers have privilege in the learning the new technology the coding and designing concepts. Training programmes, walk-though sessions, ample access to literature made available to developers for upgrading their knowledge base, whereas the tester carry on testing on the earned skills-sets from on-job training.
Us versus Them Mentality

This common problem arises when developers and testers are onopposite sides of the testing issue. In many organizations, testing is an Us Vs. Them mentality. Testers are treated like Bad guys. Each whether developer or tester feels that it is “out to get” the other. Often, the political infighting takes up energy, sidetracks the project, and accomplishes little except to negatively impact relationships. Some developers write sloppy coding initially and let the testing reports the defects. Such defects are then cured, and code released for production with credit to developers for high quality system.
Requirement study
Requirements are the details describing an application's externally-perceived functionality and properties. Requirements are ideally clear, complete, reasonably detailed, cohesive, attainable, and testable. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods and software tools are available depending on the particular project. If there is no clarity on the testing scope or the business requirement document, tester will be at confused status because of difference in Business Requirement Document and scope definition during business discussion or there may be addition in the requirement due to change in the delivery timelines. Defect reported may be on account of difficult to understand the requirement, non-compliance to regulatory standards, contradictory statements in the documents, incorrect statement etc.
Code Design

Good Design' could refer to ‘functional design' or 'internal design'. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works as expected when implemented. Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements or user stories. Since the testers lack the adequate training opportunities toward knowledge up gradation required for testing an application, defects reported may get in-appropriately categorized resulting to blame on the tester on in-adequate quality in testing.
Lack of Test Tools

Testing is normally treated as art rather than an engineering discipline. Management prefers to labour intensive technique instead use of testing tools. IT management may have the attitude that test tools are a luxury. Manual testing can be an overwhelming task. Although more than just tools are needed, trying to test effectively without tools is like trying to dig a trench with a spoon. Sometimes tools are available but integrating them with actual testing is challenge for the test manager. When system grows larger, testing without use of tools becoming logistically impossible.
Lack of Management Understanding and Support of Testing

Testing is always looked as secondary activity whereas Development is classified as Creative or desirable endeavor. Support for testing must come from the top, otherwise staff will not takethe job seriously and testers’ morale will suffer. Management support goes beyond financial provisions; management must also make the tough calls to deliver the software on time with defects or take a little longer and do the job right.
Lack of Customer and User Involvement

Users and customers may be shut out of the testing process, or perhapsthey don’t want to be involved. Users and customers play one of the most critical roles in testing; making sure the software works from a business perspective. Here Customers are those who sponsor the development of application so as to ensure that objectives are met in the designing application whereas Users of application want ease of use and operability.
Not Enough Schedule or Budget for Testing

This is a common complaint. The challenge is to prioritize the plan to test the right things in the given time. When the schedules are established, time is allotted for testing however many a time either developers usurp the testing timelines for development phase or there is inadequate staffing in testing work load. Testers are placed under excessive stress when they are categorized as the group which stands in Go-Live timelines for application going in production. Since testing comes in last phase of SDLC, testers are blamed for delays in timelines despite developers have over utilized schedule. Due to stressed timelines, there may be possibility of inadequate test coverage. Show-stoppers, delayed response of the system due to connectivity issues, delay in running batch runs etc. may impact the Project Testing plan.

There is also quite disparity in management attitude towards the allocation budgets for the development and testing.
Over Reliance on Independent Testers

Sometimes called the “throw it over the wall” syndrome, developers know that independent testers will check their work, so they focus on coding and let the testers do the testing. Unfortunately, this results in higher defect levels and longer testing times. Traditionally, once developers are finished with coding the application; the system is handed over to testing team. There is no effective communication between developers and testing team to understand the repeated testing defects and issues reported in testing an application.
Rapid Change

In some technologies, especially Rapid Application Development (RAD), the software is created and modified faster than the testers can test it. This highlights the need for automation, but also for version and release management.
Testers are in A Lose-Lose Situation

Testers are always on the loser end in the entire system life cycle. If thorough testing is done and defects are reported which has resulted in delayed implementation, they are blamed for delaying the project. Conversely, if the testers do not find the critical defects and approve the implementation and typical problems reported in the production, they are blamed for poor quality. Some developers try to isolate designing from the defects. The defects reported are considered as tester’s responsibility and if the same flow to the production, the testers are held responsible for inadequate code testing. Tester are often held responsible for delay in fixing the defects.
Having to Say “No”

Having to say, “No, the software is not ready for production,” is the single toughest dilemma for testers. Nobody on the project likes to hear that and frequently testers succumb to the pressures of schedule and cost. Many a times tester face the challenge of telling the developers and customer about the in-adequacy of code, status of applications, defects and recommendation on implementing in production.
New developmental processes

Along with these new delivery platforms come new methods for software development. Project teams have moved away from traditional “waterfall” methods, and follow a much more iterative approach to development and delivery. An integral part of this iterative approach is that testing activities are more integrated across the development cycle than before. Traditional system testing is not just conducted at the end of development, but may be conducted multiple times throughout the project for major components, and then completed once all development is complete. Based on the risk assessment of the risks associated with the test process, changes to the test process may be needed. For example, if the testers lack training in the test process, that training should be provided prior to testing. If the training cannot occur then extra supervision would be required. If inadequate test resources and schedule time is not available the number of tests may need to be reduced. Risk analysis will determine the risks associated with the software being tested and performing the test process. Risk analysis should determine the magnitude of the risks, and prioritize them in importance. Test planning will then consider those risks in developing the Test Plan.
Programmatic Risk

These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program like running out of funds, market development, change in product and market strategy, changes in government rules and regulations.
Technical risks

Technical risks generally lead to failure of functionality and performance like Continuous changing requirements, no advanced technology available or the existing technology is in initial stages, Product is complex to implement, difficult project modules integration, failure to identify complex functionalities and time required to develop those testing scripts.
No Say on the Big bang Approach

Sometimes Project Management decides to adopt Big Bang approach and devise schedule accordingly, testing teams in such scenario are hardly taken in consideration when they have bigger role to play. When a new system needs to be implemented in an organization, there are three different ways to adopt this new system: The big bang adoption, phased adoption and parallel adoption. With the big bang adoption, the switch between using the old system and using the new system happens at one single date, the so-called instant changeover of the system.

Everybody starts to use the new system at the same date and the old system will not be used anymore from that moment on. There is real challenge to the testing team on ensuring appropriate functioning of new system. Testing team has to learn all applications involved, their interfaces, consolidation of all system etc. Tester has to stress on defects present at the interfaces of components are identified well in advance, identify the defect impact whether defect is in component or interface. There is high probability of missing some critical defects which might surface in production. With timelines its too stressful for testing team to cover up all the integration. To be more efficient and accurate, testing team has to take care in defining the user-like workloads for creating realistic scenarios in exercising the environment to give confidence that the integrated environment will work as expected for the target customers.