Programming Solution

Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions. Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it. To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts. E.g: Lets assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Ap

Following are some facts that can help you gain a better insight into the realities of Software Engineering. The best programmers are up to 28 times better than the worst programmers. New tools/techniques cause an initial LOSS of productivity/quality. The answer to a feasibility study is almost always “yes”. A May 2002 report prepared for the National Institute of Standards and Technologies (NIST)(1) estimates the annual cost of software defects in the United States as $59.5 billion. Reusable components are three times as hard to build. For every 25% increase in problem complexity, there is a 100% increase in solution complexity. 80% of software work is intellectual. A fair amount of it is creative. Little of it is clerical. Requirements errors are the most expensive to fix during production. Missing requirements are the hardest requirement errors to correct. Error-removal is the most time-consuming phase of the life cycle. Software is usually tested at best at the 55-60% (

Certification Information for Software QA and Test Engineers CSQE - ASQ (American Society for Quality)’s program for CSQE (Certified Software Quality Engineer) - information on requirements, outline of required 'Body of Knowledge', listing of study references and more. CSQA/CSTE - QAI (Quality Assurance Institute)'s program for CSQA (Certified Software Quality Analyst) and CSTE (Certified Software Test Engineer) certifications. ISEB Software Testing Certifications - The British Computer Society maintains a program of 2 levels of certifications - ISEB Foundation Certificate, Practitioner Certificate. ISTQB Certified Tester - The International Software Testing Qualifications Board is a part of the European Organization for Quality - Software Group, based in Germany. The certifications are based on experience, a training course and test. Two levels are available: Foundation and Advanced.

ISO - International Organization for Standardization is a network of the national standards institutes of 150 countries, on the basis of one member per country, with a Central Secretariat in Geneva, Switzerland, that coordinates the system. ISO is a non-governmental organization. ISO has developed over 13, 000 International Standards on a variety of subjects.

Six Sigma is a quality management program to achieve "six sigma" levels of quality. It was pioneered by Motorola in the mid-1980s and has spread to many other manufacturing companies, notably General Electric Corporation (GE). Six Sigma is a rigorous and disciplined methodology that uses data and statistical analysis to measure and improve a company's operational performance by identifying and eliminating "defects" from manufacturing to transactional and from product to service. Commonly defined as 3.4 defects per million opportunities, Six Sigma can be defined and understood at three distinct levels: metric, methodology and philosophy... Training Sigma processes are executed by Six Sigma Green Belts and Six Sigma Black Belts, and are overseen by Six Sigma Master Black Belts.

Developed by the software community in 1986 with leadership from the SEI. The CMM describes the principles and practices underlying software process maturity. It is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The focus is on identifying key process areas and the exemplary practices that may comprise a disciplined software process. What makes up the CMM?  The CMM is organized into five maturity levels: Initial Repeatable Defined Manageable Optimizing Except for Level 1, each maturity level decomposes into several key process areas that indicate the areas an organization should focus on to improve its software process. Level 1 Initial Level:  Disciplined process, Standard, Consistent process, Predictable process, Continuously Improving process Level 2 Repeatable: Key practice areas - Requirements management, Software project plan

Buying the Wrong Tool Inadequate Test Team Organization Lack of Management Support Incomplete Coverage of Test Types by the selected tool Inadequate Tool Training Difficulty using the tool Lack of a Basic Test Process or Understanding of What to Test Lack of Configuration Management Processes Lack of Tool Compatibility and Interoperability Lack of Tool Availability

Take time to define the tool requirements in terms of technology, process, applications, people skills, and organization. During tool evaluation, prioritize which test types are the most critical to your success and judge the candidate tools on those criteria. Understand the tools and their trade-offs. You may need to use a multi-tool solution to get higher levels of test-type coverage. For example, you will need to combine the capture/play-back tool with a load-test tool to cover your performance test cases. Involve potential users in the definition of tool requirements and evaluation criteria. Build an evaluation scorecard to compare each tool's performance against a common set of criteria. Rank the criteria in terms of relative importance to the organization.

There are three broad options in Test Automation: Full Manual Partial Automation Full Automation Reliance on manual testing Redundancy possible but requires duplication of effort Reliance on automated testing Responsive and flexible Flexible Relatively inflexible Inconsistent Consistent Very consistent Required for automation - - Low implementation cost - High implementation cost Low skill requirements - High skill requirements High repetitive cost Automates repetitive tasks and high return tasks Economies of scale in repetition, regression etc Fully manual testing has the benefit of being relatively cheap and effective. But as quality of the product improves the additional cost for finding further bugs becomes more expensive. Large scale manual testing also implies large scale testing teams with the related costs of space, overhead and infrastructure. Manual testing is also far more responsive and flexible than automated testing but is pro

Let’s first look at some common relationship problems and why many romantic partnerships do not work out. 1. Ego, Fear, & Emotional Insecurities As with material possessions or professional achievements, relationships give our ego a method by which to identify who we are to the outside world. The problem is that we attach so much of our identity to the external appearance of our relationships that we lose touch with the parts of ourselves that are wise and conscious. The attachment to this false identity leads to a feeling of desperation rather than fulfillment. After all, without the relationship, or the job, or whichever other false identity we have chosen, who would we be? Besides the ego identification, it’s easy to develop a dependency on companionship. That independent person that we once were starts to evaporate. Our mind becomes fogged and as our self-identification begins to attach itself to the other person, unconsciously or consciously, we become afraid to lose that

Automating testing is no different from a programmer using a coding language to write programs to automate any manual process. One of the problems with testing large systems is that it can go beyond the scope of small test teams. Because only a small number of testers are available the coverage and depth of testing provided are inadequate for the task at hand. Expanding the test team beyond a certain size also becomes problematic with increase in work over head. Feasible way to avoid this without introducing a loss of quality is through appropriate use of tools that can expand individual’s capacity enormously while maintaining the focus (depth) of testing upon the critical elements. Consider the following factors that help determine the use of automated testing tools: • Examine your current testing process and determine where it needs to be adjusted for using automated test tools. • Be prepared to make changes in the current ways you perform testing. • Involve people who will be

The documents outlined in the IEEE Standard of Software Test Documentation covers test planning, test specification, and test reporting. Test reporting covers four document types: 1. A Test Item Transmittal Report identifies the test items being transmitted for testing from the development to the testing group in the event that a formal beginning of test execution is desired Details to be included in the report - Purpose, Outline, Transmittal-Report Identifier, Transmitted Items, Location, Status, and Approvals. 2. Test Log is used by the test team to record what occurred during test execution Details to be included in the report - Purpose, Outline, Test-Log Identifier, Description, Activity and Event Entries, Execution Description, Procedure Results, Environmental Information, Anomalous Events, Incident-Report Identifiers 3. Test Incident report describes any event that occurs during the test execution that requires further investigation.Details to be included in the repor

1. Forget and forgive This is the most powerful aid to peace of mind. We often nurture ill feeling inside our heart for the person who insults or harms us. We forget that the insult or injury was done to us once but by nourishing the grievance we go on excavating the wound forever. Therefore it is essential that we cultivate the art of forgiving and forgetting. Believe in the justice of God and the doctrine of Karma. Let Him judge the act of the one who insulted you. Life is too short to waste in such trifles. Forget, forgive, and march on. 2. Do not interfere in others' business Most of us create our own problems by interfering too often in others' affairs. We do so because somehow we have convinced ourselves that our way is the best way, our logic is the perfect logic, and those who do not conform to our thinking must be criticized and steered to the right direction, our direction. This kind of attitude on our part denies the existen

Once the reported defect is fixed, the tester needs to re-test to confirm the fix. This is usually done by executing the possible scenarios where the bug can occur. Once retesting is completed, the fix can be confirmed and the bug can be closed. This marks the end of the bug life cycle.

You should provide enough detail while reporting the bug keeping in mind the people who will use it – test lead, developer, project manager, other testers, new testers assigned etc. This means that the report you will write should be concise, straight and clear. Following are the details your report should contain: -              Bug Title -              Bug identifier (number, ID, etc.) -              The application name or identifier and version -              The function, module, feature, object, screen, etc. where the bug occurred -              Environment (OS, Browser and its version) -              Bug Type or Category/Severity/Priority o      Bug Category: Security, Database, Functionality (Critical/General), UI o      Bug Severity: Severity with which the bug affects the application – Very High, High, Medium, Low, Very Low o      Bug Priority: Recommended priority to be given for a fix of this bug – P0, P1, P2, P3, P4, P5 (P0-Highest, P5-Lo

Once the test cases are developed using the appropriate techniques, they are executed which is when the bugs occur. It is very important that these bugs be reported as soon as possible because, the earlier you report a bug, the more time remains in the schedule to get it fixed. Simple example is that you report a wrong functionality documented in the Help file a few months before the product release, the chances that it will be fixed are very high. If you report the same bug few hours before the release, the odds are that it won’t be fixed. The bug is still the same though you report it few months or few hours before the release, but what matters is the time. It is not just enough to find the bugs; these should also be reported/communicated clearly and efficiently, not to mention the number of people who will be reading the defect.  Defect tracking tools (also known as bug tracking tools, issue tracking tools or problem trackers) greatly aid the tes

As discussed earlier, defect is the variance from a desired product attribute (it can be a wrong, missing or extra data). It can be of two types – Defect from the product or a variance from customer/user expectations.  It is a flaw in the software system and has no impact until it affects the user/customer and operational system.

      With the knowledge of testing so far gained, you can now be able to     categorize the defects you have found. Defects can be categorized into different types basing on the core issues they address. Some defects address security or database issues while others may refer to functionality or UI issues.      Security Defects: Application security defects generally involve improper handling       of data sent from the user to the application. These defects are the most severe and given highest priority for a fix.     Examples:   -           Authentication: Accepting an invalid username/password -           Authorization: Accessibility to pages though permission not given Data Quality/Database Defects: Deals with improper handling of data in the database.    Examples:       -           Values not deleted/inserted into the database properly     -           Improper/wrong/null values inserted in place of the actual values     Critical Functionality D

As discussed earlier, defect is the variance from a desired product attribute (it can be a wrong, missing or extra data). It can be of two types – Defect from the product or a variance from customer/user expectations.  It is a flaw in the software system and has no impact until it affects the user/customer and operational system.

The test case design techniques are broadly grouped into two categories: Black box techniques, White box techniques and other techniques that do not fall under either category. Black Box (Functional) White Box (Structural) Other Specification derived tests Branch Testing Error guessing Equivalence partitioning Condition Testing Boundary Value Analysis Internal boundary value testing State-Transition Testing

The manner in which a test case is depicted varies between organizations. Anyhow, many test case templates are in the form of a table, for example, a 5-column table with fields: Test CaseID Test Case Description Test Dependency/ Setup Input Data Requirements/ Steps Expected Results Pass/Fail

It is clear and evident that when the veils that conceal the realities of the manifestations of the Names and Attributes of God, nay of all created things visible or invisible, have been rent asunder, nothing except the Sign of God will remain - a sign which He, Himself, hath placed within these realities. This sign will endure as long as is the wish of th

The way to crack a job interview is not just by giving answers, but the ‘right’ answers. Here are some important tips on how to get it right Create a strong resume. Build a compelling case on why you fit the job role: The process of giving a job winning interview starts by forming a strong resume. A resume works as an entrance test to get an interview. A person’s resume should be concise and convey more in fewer words. For example, instead of saying, “I am an exceptional guitarist”, one can say, “I was the lead guitarist of an award winning rock band back in college”. Do your primary research on your potential employer Every recruiter expects you to have some basic knowledge about the organization and the industry that you are contemplating joining. Hence, it is advisable to do a primary research before going. After all, the employer has a lot of information about the applicant, so it’s only polite if the applicant evens the score. Highl