That’s the takeaway from a recent Gartner talk in Australia, reported by IT News.

At a symposium this week, Gartner analyst Dennis Gaughan explained what the four big vendors are really trying to do, based on Gartner’s experience with its clients.

• Microsoft mainly wants to protect Windows and Office. Microsoft is a platform company, and its main goal is to protect its highly lucrative Windows and Office monopolies, while establishing other platforms that will be hard for customers to break away from later. New functionality is “drip fed” to users of those core platforms, but new products exist to protect the core. He advised extreme caution before moving to Office 365, and said not to slip into an “all-Microsoft” mentality.

• Oracle products don’t really work well together. Oracle’s sales force is extremely aggressive about pushing a suite of products, but has much fewer integration points than SAP. In fact, integration is usually left entirely up to the customer. Oracle is also very reluctant to talk about product roadmaps for fear that future products will cannibalize existing ones. The company makes more than 90% of its profits through maintenance fees, and will do whatever it takes to keep those fees flowing in. Gaughan also expressed some surprise that so many customers keep working with Oracle despite reporting that Oracle is “the most difficult vendor to deal with.”

• IBM wants to take over your IT strategy. IBM bills itself as a thought leader, but its real business is selling consulting services. To thrive, IBM account managers try to take control of a company’s IT strategy so they can keep pushing new products. Gaughan recommends taking a collaborative or partner approach.

• SAP confuses customers with pricing. A lot of SAP customers ask Gartner for help figuring out SAP’s pricing and licensing, as SAP has unusual terms for billing data going into and out of systems. Gaughan also said that a big technology transition that was driving SAP revenue for the last few years — moving existing customers from the old R/3 system to the newer Business Suite — is almost done, which means SAP will have to be more aggressive with maintenance fees. He recommended locking in maintenance prices now.

Overall, Gaughan said that most of the innovation being done in these companies is in their research arms. Their real goal is protecting the status quo for as long as possible.

Today’s topic on the whiteboard: Test Automation.

Test Automation is often seen as a way to reduce the cost of testing, shorten testing cycles, increase coverage and effectiveness, and in general that this is the silver bullet of any QA department.

Nicely put, but usually wrong.

The trend today is that test automation is enforced on some projects that don’t have good results in an attempt to achieve that nice statement presented above.

Management sometimes can become extremely focused on automation rather than improving quality, I’ve seen projects with estimation that have 90% automation, others that promised the creation of hundreds of scripts per day and the classic case when the QA department doesn’t have time to test so the only viable solution considered is automation.

Don’t get me wrong, I strongly believe in test automation but only where it adds value, and that is the tricky part. Automation testing involves higher upfront costs and should be considered a long term investment where the most important variable of the equations is the return of investment. Usually the break even point is considered to be somewhere around 1-3 years.
In the end it’s all about the money and the QA department has a big responsibility here.

Here you can find an interesting tool that helps calculate ROI: http://www.aspiresys.com/testautomationroi/

As you can see in the ROI calculator above, the decision to make a jump from manual to automated testing is a big step and should take into consideration a lot of parameters, such as:

• Age of the product
• Releases planned for a year
• Required regression cycle per year
• Number of existing regression test cases
• Number of configurations to be tested
• Cost of the testing resources
• Infrastructure cost
• Test automation tool cost
• Percentage of test cases that can be considered for automation
• Time required for building reusable components, automation frameworks and batch scripts
• Hourly cost per test automation resource
• Resource training

Test Automation is not something that can be done overnight so before starting, try to have an in depth overview of the project you are working on.

Another thing that usually is not taken into consideration when deciding if test automation is feasible is the product development life cycle duration. If you are working on an application that will be developed and tested in 5 months, automation could be a mistake.
Keep in mind that when effort is invested to write automated test, you implicitly lose time that could be used to find and report defects. Contrary to popular belief automation needs constant updates and debugging especially in an environment where developers are not used to working together with the QA team, where everyone writes code without following a formal procedure.

In my experience more defects are found via ad-hoc (exploratory) tests than via automation. The more time a tester spends playing with a feature the greater the odds of finding real user bugs. An automated script will check a specific flow, specific point in the application depending on what you specified when you wrote it. Don’t underestimate how stupid automated tests can be. A manual check will take into consideration a lot more aspects of the application, things like patterns, layout, complex functionalities, defect clustering and other features.

One other thing I would like to draw attention to is the “Pesticide paradox”. A lot of engineers don’t give this test principle the appropriate attention, they will just be happy that their automated test suite shows no issues.

Pesticide paradox test principle states that running the same tests over and over again would not show any new defects because all defects found using the initial test cases would eventually all be fixed.

Therefore, to avoid the pesticide paradox and other causes of diminishing returns, all tests should be regularly reviewed to ensure that all expected areas of functionality are covered.  This could involve adding new scenarios as well as discontinuing ones that are no longer valid.  Additionally, new tests can be written to exercise the code in new or different ways to highlight potential defects.  Finally, use a mix of formal and informal testing techniques to achieve more holistic testing results.
source

Another mistakenly qualified “best practice” is that test automation should be done in the beginning of the test cycle. Sounds good on paper and the principle is correct, but it rarely works in real life. At the beginning of the project things are changing fast and they usually tend to be chaotic, my advice for the best time to automate tests is somewhere around the middle of the cycle or to better put it: when things are mostly stable but a lot of builds are left to test.

Here are some areas where automation has great value:

• File interaction (open/save/export)
• Authentication
• Security holes
• Core/critical area functionalities (functionalities that the application revolves around)
• Features/functionalities that don’t use a dynamic oracle.
• Important scenarios that have to be performed often
• Data comparison

To conclude, automated testing is not and should not be considered a silver bullet that will magically solve all the problems of testing and software development. It is a valuable tool in your toolbox and if used wisely it can enhance the overall quality of a product, but the key ingredients of any successful project are: the right level of automation combined with exploratory testing and good test design.

Pilot: Left inside main tire almost needs replacement.
Engineers: Almost replaced left inside main tire.

Pilot: Test flight OK, except auto-land very rough.
Engineers: Auto-land not installed on this aircraft.

Pilot: Something loose in cockpit.
Engineers: Something tightened in cockpit.

Pilot: Dead bugs on windshield.
Engineers: Live bugs on back-order.

Pilot: Autopilot in altitude-hold mode produces a 200 feet per minute descent.
Engineers: Cannot reproduce problem on ground.

Pilot: Evidence of leak on right main landing gear.
Engineers: Evidence removed.

Pilot: DME volume unbelievably loud.
Engineers: DME volume set to more believable level.

Pilot: Friction locks cause throttle levers to stick.
Engineers: That’s what friction locks are for.

Pilot: IFF inoperative in OFF mode.
Engineers: IFF always inoperative in OFF mode.

Pilot: Suspected crack in windshield.
Engineers: Suspect you’re right.

Pilot: Number 3 engine missing.
Engineers: Engine found on right wing after brief search.

Pilot: Aircraft handles funny.
Engineers: Aircraft warned to straighten up, fly right, and be serious.

Pilot: Target radar hums.
Engineers: Reprogrammed target radar with lyrics.

Pilot: Mouse in cockpit.
Engineers: Cat installed.

Pilot: Noise coming from under instrument panel. Sounds like a midget pounding on something with a hammer.
Engineers: Took hammer away from midget

1. Acceptance Testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. It is usually performed by the customer.

2. Accessibility Testing: Type of testing which determines the usability of a product to the people having disabilities (deaf, blind, mentally disabled etc). The evaluation process is conducted by persons having disabilities.

3. Active Testing: Type of testing consisting in introducing test data and analyzing the execution results. It is usually conducted by the testing teams.

4. Agile Testing: Software testing practice that follows the principles of the agile manifesto, emphasizing testing from the perspective of customers who will utilize the system. It is usually performed by the QA teams.

5. Age Testing: Type of testing which evaluates a system’s ability to perform in the future. The evaluation process is conducted by testing teams.

6. Ad-hoc Testing: Testing performed without planning and documentation – the tester tries to ‘break’ the system by randomly trying the system’s functionality. It is performed by the testing teams.

7. Alpha Testing: Type of testing a software product or system conducted at the developer’s site. Usually it is performed by the end user.

8. Assertion Testing: Type of testing consisting in verifying if the conditions confirm the product requirements. It is performed by the testing teams.

9. API Testing: Testing technique similar to unit testing in that it targets the code level. API Testing differs from unit testing in that it is typically a QA task and not a developer task.

10. All-pairs Testing: Combinatorial testing method that tests all possible discrete combinations of input parameters. It is performed by the testing teams.

11. Automated Testing: Testing technique that uses automation testing tools to control the environment set-up, test execution and results reporting. It is performed by a computer and is used inside the testing teams.

12. Basis Path Testing: A testing mechanism which derives a logical complexity measure of a procedural design and use this as a guide for defining a basic set of execution paths. It is used by testing teams when defining test cases.

13. Backward Compatibility Testing: Testing method which verifies the behavior of the developed software with older versions of the test environment. It is performed by testing teams.

14. Beta Testing: Final testing before releasing application for commercial purpose. It is typically done by end-users or others.

15. Benchmark Testing: Testing technique that uses representative sets of programs and data designed to evaluate the performance of computer hardware and software in a given configuration. It is performed by testing teams.

16. Big Bang Integration Testing: Testing technique which integrates individual program modules only when everything is ready. It is performed by the testing teams.

17. Binary Portability Testing: Technique that tests an executable application for portability across system platforms and environments, usually for conformation to an ABI specification. It is performed by the testing teams.

18. Boundary Value Testing: Software testing technique in which tests are designed to include representatives of boundary values. It is performed by the QA testing teams.

19. Bottom Up Integration Testing: In bottom up integration testing, module at the lowest level are developed first and other modules which go towards the ‘main’ program are integrated and tested one at a time. It is usually performed by the testing teams.

20. Branch Testing: Testing technique in which all branches in the program source code are tested at least once. This is done by the developer.

21. Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail. It is performed by testing teams.

22. Black box Testing: A method of software testing that verifies the functionality of an application without having specific knowledge of the application’s code/internal structure. Tests are based on requirements and functionality. It is performed by QA teams.

23. Code-driven Testing: Testing technique that uses testing frameworks (such as xUnit) that allow the execution of unit tests to determine whether various sections of the code are acting as expected under various circumstances. It is performed by the development teams.

24. Compatibility Testing: Testing technique that validates how well a software performs in a particular hardware/software/operating system/network environment. It is performed by the testing teams.

25. Comparison Testing: Testing technique which compares the product strengths and weaknesses with previous versions or other similar products. Can be performed by tester, developers, product managers or product owners.

26. Component Testing: Testing technique similar to unit testing but with a higher level of integration – testing is done in the context of the application instead of just directly testing a specific method. Can be performed by testing or development teams.

27. Configuration Testing: Testing technique which determines minimal and optimal configuration of hardware and software, and the effect of adding or modifying resources such as memory, disk drives and CPU. Usually it is performed by the performance testing engineers.

28. Condition Coverage Testing: Type of software testing where each condition is executed by making it true and false, in each of the ways at least once. It is typically made by the automation testing teams.

29. Compliance Testing: Type of testing which checks whether the system was developed in accordance with standards, procedures and guidelines. It is usually performed by external companies which offer “Certified OGC Compliant” brand.

30. Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. It it usually done by performance engineers.

31. Conformance Testing: The process of testing that an implementation conforms to the specification on which it is based. It is usually performed by testing teams.

32. Context Driven Testing: An Agile Testing technique that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization at a specific moment. It is usually performed by Agile testing teams.

33. Conversion Testing: Testing of programs or procedures used to convert data from existing systems for use in replacement systems. It is usually performed by the QA teams.

34. Decision Coverage Testing: Type of software testing where each condition/decision is executed by setting it on true/false. It is typically made by the automation testing teams.

35. Destructive Testing: Type of testing in which the tests are carried out to the specimen’s failure, in order to understand a specimen’s structural performance or material behaviour under different loads. It is usually performed by QA teams.

36. Dependency Testing: Testing type which examines an application’s requirements for pre-existing software, initial states and configuration in order to maintain proper functionality. It is usually performed by testing teams.

37. Dynamic Testing: Term used in software engineering to describe the testing of the dynamic behavior of code. It is typically performed by testing teams.

38. Domain Testing: White box testing technique which contains checkings that the program accepts only valid input. It is usually done by software development teams and occasionally by automation testing teams.

39. Error-Handling Testing: Software testing type which determines the ability of the system to properly process erroneous transactions. It is usually performed by the testing teams.

40. End-to-end Testing: Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. It is performed by QA teams.

41. Endurance Testing: Type of testing which checks for memory leaks or other problems that may occur with prolonged execution. It is usually performed by performance engineers.

42. Exploratory Testing: Black box testing technique performed without planning and documentation. It is usually performed by manual testers.

43. Equivalence Partitioning Testing: Software testing technique that divides the input data of a software unit into partitions of data from which test cases can be derived. it is usually performed by the QA teams.

44. Fault injection Testing: Element of a comprehensive test strategy that enables the tester to concentrate on the manner in which the application under test is able to handle exceptions. It is performed by QA teams.

45. Formal verification Testing: The act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics. It is usually performed by QA teams.

46. Functional Testing: Type of black box testing that bases its test cases on the specifications of the software component under test. It is performed by testing teams.

47. Fuzz Testing: Software testing technique that provides invalid, unexpected, or random data to the inputs of a program – a special area of mutation testing. Fuzz testing is performed by testing teams.

48. Gorilla Testing: Software testing technique which focuses on heavily testing of one particular module. It is performed by quality assurance teams, usually when running full testing.

49. Gray Box Testing: A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings. It can be performed by either development or testing teams.

50. Glass box Testing: Similar to white box testing, based on knowledge of the internal logic of an application’s code. It is performed by development teams.

51. GUI software Testing: The process of testing a product that uses a graphical user interface, to ensure it meets its written specifications. This is normally done by the testing teams.

52. Globalization Testing: Testing method that checks proper functionality of the product with any of the culture/locale settings using every type of international input possible. It is performed by the testing team.

53. Hybrid Integration Testing: Testing technique which combines top-down and bottom-up integration techniques in order leverage benefits of these kind of testing. It is usually performed by the testing teams.

54. Integration Testing: The phase in software testing in which individual software modules are combined and tested as a group. It is usually conducted by testing teams.

55. Interface Testing: Testing conducted to evaluate whether systems or components pass data and control correctly to one another. It is usually performed by both testing and development teams.

56. Install/uninstall Testing: Quality assurance work that focuses on what customers will need to do to install and set up the new software successfully. It may involve full, partial or upgrades install/uninstall processes and is typically done by the software testing engineer in conjunction with the configuration manager.

57. Internationalization Testing: The process which ensures that product’s functionality is not broken and all the messages are properly externalized when used in different languages and locale. It is usually performed by the testing teams.

58. Inter-Systems Testing: Testing technique that focuses on testing the application to ensure that interconnection between application functions correctly. It is usually done by the testing teams.

59. Keyword-driven Testing: Also known as table-driven testing or action-word testing, is a software testing methodology for automated testing that separates the test creation process into two distinct stages: a Planning Stage and an Implementation Stage. It can be used by either manual or automation testing teams.

60. Load Testing: Testing technique that puts demand on a system or device and measures its response. It is usually conducted by the performance engineers.

61. Localization Testing: Part of software testing process focused on adapting a globalized application to a particular culture/locale. It is normally done by the testing teams.

62. Loop Testing: A white box testing technique that exercises program loops. It is performed by the development teams.

63. Manual Scripted Testing: Testing method in which the test cases are designed and reviewed by the team before executing it. It is done by manual testing teams.

64. Manual-Support Testing: Testing technique that involves testing of all the functions performed by the people while preparing the data and using these data from automated system. it is conducted by testing teams.

65. Model-Based Testing: The application of Model based design for designing and executing the necessary artifacts to perform software testing. It is usually performed by testing teams.

66. Mutation Testing: Method of software testing which involves modifying programs’ source code or byte code in small ways in order to test sections of the code that are seldom or never accessed during normal tests execution. It is normally conducted by testers.

67. Modularity-driven Testing: Software testing technique which requires the creation of small, independent scripts that represent modules, sections, and functions of the application under test. It is usually performed by the testing team.

68. Non-functional Testing: Testing technique which focuses on testing of a software application for its non-functional requirements. Can be conducted by the performance engineers or by manual testing teams.

69. Negative Testing: Also known as “test to fail” – testing method where the tests’ aim is showing that a component or system does not work. It is performed by manual or automation testers.

70. Operational Testing: Testing technique conducted to evaluate a system or component in its operational environment. Usually it is performed by testing teams.

71. Orthogonal array Testing: Systematic, statistical way of testing which can be applied in user interface testing, system testing, regression testing, configuration testing and performance testing. It is performed by the testing team.

72. Pair Testing: Software development technique in which two team members work together at one keyboard to test the software application. One does the testing and the other analyzes or reviews the testing. This can be done between one Tester and Developer or Business Analyst or between two testers with both participants taking turns at driving the keyboard.

73. Passive Testing: Testing technique consisting in monitoring the results of a running system without introducing any special test data. It is performed by the testing team.

74. Parallel Testing: Testing technique which has the purpose to ensure that a new application which has replaced its older version has been installed and is running correctly. It is conducted by the testing team.

75. Path Testing: Typical white box testing which has the goal to satisfy coverage criteria for each logical path through the program. It is usually performed by the development team.

76. Penetration Testing: Testing method which evaluates the security of a computer system or network by simulating an attack from a malicious source. Usually they are conductedby specialized penetration testing companies.

77. Performance Testing: Functional testing conducted to evaluate the compliance of a system or component with specified performance requirements. It is usually conducted by the performance engineer.

78. Qualification Testing: Testing against the specifications of the previous release, usually conducted by the developer for the consumer, to demonstrate that the software meets its specified requirements.

79. Ramp Testing: Type of testing consisting in raising an input signal continuously until the system breaks down. It may be conducted by the testing team or the performance engineer.

80. Regression Testing: Type of software testing that seeks to uncover software errors after changes to the program (e.g. bug fixes or new functionality) have been made, by retesting the program. It is performed by the testing teams.

81. Recovery Testing: Testing technique which evaluates how well a system recovers from crashes, hardware failures, or other catastrophic problems. It is performed by the testing teams.

82. Requirements Testing: Testing technique which validates that the requirements are correct, complete, unambiguous, and logically consistent and allows designing a necessary and sufficient set of test cases from those requirements. It is performed by QA teams.

83. Security Testing: A process to determine that an information system protects data and maintains functionality as intended. It can be performed by testing teams or by specialized security-testing companies.

84. Sanity Testing: Testing technique which determines if a new software version is performing well enough to accept it for a major testing effort. It is performed by the testing teams.

85. Scenario Testing: Testing activity that uses scenarios based on a hypothetical story to help a person think through a complex problem or system for a testing environment. It is performed by the testing teams.

86. Scalability Testing: Part of the battery of non-functional tests which tests a software application for measuring its capability to scale up – be it the user load supported, the number of transactions, the data volume etc. It is conducted by the performance engineer.

87. Statement Testing: White box testing which satisfies the criterion that each statement in a program is executed at least once during program testing. It is usually performed by the development team.

88. Static Testing: A form of software testing where the software isn’t actually used it checks mainly for the sanity of the code, algorithm, or document. It is used by the developer who wrote the code.

89. Stability Testing: Testing technique which attempts to determine if an application will crash. It is usually conducted by the performance engineer.

90. Smoke Testing: Testing technique which examines all the basic components of a software system to ensure that they work properly. Typically, smoke testing is conducted by the testing team, immediately after a software build is made .

91. Storage Testing: Testing type that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. It is usually performed by the testing team.

92. Stress Testing: Testing technique which evaluates a system or component at or beyond the limits of its specified requirements. It is usually conducted by the performance engineer.

93. Structural Testing: White box testing technique which takes into account the internal structure of a system or component and ensures that each program statement performs its intended function. It is usually performed by the software developers.

94. System Testing: The process of testing an integrated hardware and software system to verify that the system meets its specified requirements. It is conducted by the testing teams in both development and target environment.

95. System integration Testing: Testing process that exercises a software system’s coexistence with others. It is usually performed by the testing teams.

96. Top Down Integration Testing: Testing technique that involves starting at the stop of a system hierarchy at the user interface and using stubs to test from the top down until the entire system has been implemented. It is conducted by the testing teams.

97. Thread Testing: A variation of top-down testing technique where the progressive integration of components follows the implementation of subsets of the requirements. It is usually performed by the testing teams.

98. Upgrade Testing: Testing technique that verifies if assets created with older versions can be used properly and that user’s learning is not challenged. It is performed by the testing teams.

99. Unit Testing: Software verification and validation method in which a programmer tests if individual units of source code are fit for use. It is usually conducted by the development team.

100. User Interface Testing: Type of testing which is performed to check how user-friendly the application is. It is performed by testing teams.

101. Usability Testing: Testing technique which verifies the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. It is usually performed by end users.

102. Volume Testing: Testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner. It is usually conducted by the performance engineer.

103. Vulnerability Testing: Type of testing which regards application security and has the purpose to prevent problems which may affect the application integrity and stability. It can be performed by the internal testing teams or outsourced to specialized companies.

104. White box Testing: Testing technique based on knowledge of the internal logic of an application’s code and includes tests like coverage of code statements, branches, paths, conditions. It is performed by software developers.

105. Workflow Testing: Scripted end-to-end testing technique which duplicates specific workflows which are expected to be utilized by the end-user. It is usually conducted by testing teams.

Source

Reporting from Sacramento — Computer errors prompted California prison officials to mistakenly release an estimated 450 inmates with “a high risk for violence” as unsupervised parolees in a program meant to ease overcrowding, according to the state’s inspector general.

More than 1,000 additional prisoners presenting a high risk of committing drug crimes, property crimes and other offenses were also let out, officials said.

No attempt was made to return any of the offenders to state lockups or place them on supervised parole, said inspector general spokeswoman Renee Hansen.

All of the prisoners were placed on “non-revocable parole,” whose participants are not required to report to parole officers and can be sent back to prison only if caught committing a crime. The program was started in January 2010 for inmates judged to be at very low risk of reoffending, leaving parole agents free to focus on supervising higher-risk parolees.

The revelations come two days after the U.S. Supreme Courtruled that California’s prisons are dangerously overcrowded and upheld an earlier order that state officials find a way to reduce the 143,335-inmate population by roughly 33,000. The state has two years to comply.

State Sen. Ted Lieu (D-Torrance), a former prosecutor who requested an investigation of the unsupervised-parole program, said the inspector general’s report “confirms my worst fears” about it.

Investigators reviewed case files for 200 of the 10,134 former inmates who were on non-revocable parole in July of last year. They found that 31 were not eligible, and nine of those were determined likely to commit violent crimes. The inspector general and corrections officials refused to identify the inmates who were released erroneously. They also would not specify what their original offenses had been.

Using the 15% error rate they found in their sample, investigators estimated that more than 450 violent inmates had been released during the first seven months of the program, the time period they reviewed. Prison officials have disputed the findings, saying they had corrected some of the computer problems discovered by the inspector general. The error rate is now 8%, the inspector general report says.

Gov. Jerry Brown‘s plan to address overcrowding would shift tens of thousands of low-level offenders from prison to county custody. Counties would also supervise most low-risk parolees, like those in the non-revocable program.

But if the state can’t properly identify which inmates qualify for an unsupervised parole program, Lieu said on Wednesday, “how can the public have confidence they can release 33,000 felons safely?”

Under the law that created non-revocable parole, inmates are excluded if they are gang members, have committed sex crimes or violent felonies or have been determined to pose a high risk to reoffend based on an assessment of their records behind bars.

That’s where the problems begin, according to the inspector general. The computer program prison officials used to make that assessment does not access an inmate’s disciplinary history.

The program also relies on a state Department of Justice system that records arrests but is missing conviction information for nearly half of the state’s 16.4 million arrest records, according to the inspector general report.

Lee Seale, a deputy chief of staff for the California prisons, acknowledged that the corrections department’s computer system can’t access an inmate’s disciplinary record. But that information is reviewed manually by a member of his staff before prisoners are released, said spokesman Luis Patino.

Seale agreed that the missing conviction information from the Department of Justice database is a problem. “That presents a serious issue for the entire criminal justice system, every judge, every probation officer, every cop on the street trying to decide whether to arrest someone,” Seale said.

In July, a parolee named Javier Joseph Rueda, who had been classified a low-level offender and placed in the non-revocable program, opened fire on two Los Angeles police officers, hitting one in the arm. The police returned fire, killing Rueda.

Prison spokesman Oscar Hidalgo said Rueda had been properly classified. At the time, Hidalgo pointed out that the attack could have taken place even if Rueda had been checking in periodically with a parole agent.

“Supervised parole is not incarceration,” Hidalgo said.

Source: http://www.latimes.com/news/local/la-me-prisons-20110526,0,6293602.story

1.           Senior Java Development (middleware) J2EE, Struts, JSF, Spring, Ajax, JUnit, XML, JDBC, Hibernate, ETL

2.           Advanced Java Developer (middleware) J2EE, Struts, JFS, Spring, Ajax, JUnit, XML

3.           Advanced Java/Web Developer (middleware) J2EE, Struts, JFS, Spring, Ajax, JUnit, XML

4.           Javascript Senior Developer JavaScript, Dojo, jQuery, PHP or Ruby

5.           Java Developer (middleware) J2EE, Hibernate, Spring, Linux development, JUnit

6.           Java Back-end Developer J2EE, JSP, Servlets, EJB, JPA /Hibernate, JMS, Spring, SOA , SOAP

7.           Javascript Junior Developer Javascript, Dojo, jQuery, PHP or Ruby

8.           Javascript Advanced Developer Javascript, Dojo, jQuery, PHP or Ruby

9.           Web Front-end Developer Javascript, HTML, CSS, PHP, JQuery, SOAP, JSON

10.        Application Maintenance & Support Developer Java EE, Cobol, MQ Series, JMS, German Fluent

11.        Application Developer J2EE JEE, Struts, eCommerce

12.        Senior Eclipse/RCP Java Developer Java, Eclipse/RCP, OSGi, XML, Web Services, Spring

13.        J2EE Developer J2EE, JMS, ORM, XML, XSD, Oracle, SQL, Linux

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.

So what are the worst software defects in history ?

1. July 28, 1962 — Mariner I space probe. A bug in the flight software for the Mariner 1 causes the rocket to divert from its intended path on launch. Mission control destroys the rocket over the Atlantic Ocean. The investigation into the accident discovers that a formula written on paper in pencil was improperly transcribed into computer code, causing the computer to miscalculate the rocket’s trajectory.
2. 1982 — Soviet gas pipeline. Operatives working for the Central Intelligence Agency allegedly (.pdf) plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet’s history.
3. 1985-1987 — Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-25 was an “improved” therapy system that could deliver two different kinds of radiation: either a low-power electron beam (beta particles) or X-rays. The Therac-25′s X-rays were generated by smashing high-power electrons into a metal target positioned between the electron gun and the patient. A second “improvement” was the replacement of the older Therac-20′s electromechanical safety interlocks with software control, a decision made because software was perceived to be more reliable.What engineers didn’t know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a “race condition,” a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured.
4. 1988 — Buffer overflow in Berkeley Unix finger daemon. The first internet worm (the so-called Morris Worm) infects between 2,000 and 6,000 computers in less than a day by taking advantage of a buffer overflow. The specific code is a function in the standard input/output library routine called gets() designed to get a line of text over the network. Unfortunately, gets() has no provision to limit its input, and an overly large input allows the worm to take over any machine to which it can connect.Programmers respond by attempting to stamp out the gets() function in working code, but they refuse to remove it from the C programming language’s standard input/output library, where it remains to this day.
5. 1988-1996 — Kerberos Random Number Generator. The authors of the Kerberos security system neglect to properly “seed” the program’s random number generator with a truly random seed. As a result, for eight years it is possible to trivially break into any computer that relies on Kerberos for authentication. It is unknown if this bug was ever actually exploited.
6. January 15, 1990 — AT&T Network Outage. A bug in a new release of the software that controls AT&T’s #4ESS long distance switches causes these mammoth computers to crash when they receive a specific message from one of their neighboring machines — a message that the neighbors send out when they recover from a crash.One day a switch in New York crashes and reboots, causing its neighboring switches to crash, then their neighbors’ neighbors, and so on. Soon, 114 switches are crashing and rebooting every six seconds, leaving an estimated 60 thousand people without long distance service for nine hours. The fix: engineers load the previous software release.
7. 1993 — Intel Pentium floating point divide. A silicon error causes Intel’s highly promoted Pentium chip to make mistakes when dividing floating-point numbers that occur within a specific range. For example, dividing 4195835.0/3145727.0 yields 1.33374 instead of 1.33382, an error of 0.006 percent. Although the bug affects few users, it becomes a public relations nightmare. With an estimated 3 million to 5 million defective chips in circulation, at first Intel only offers to replace Pentium chips for consumers who can prove that they need high accuracy; eventually the company relents and agrees to replace the chips for anyone who complains. The bug ultimately costs Intel $475 million.
8. 1995/1996 — The Ping of Death. A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed “ping” packet from anywhere on the internet. Most obviously affected are computers running Windows, which lock up and display the so-called “blue screen of death” when they receive these packets. But the attack also affects many Macintosh and Unix systems as well.
9. June 4, 1996 — Ariane 5 Flight 501. Working code for the Ariane 4 rocket is reused in the Ariane 5, but the Ariane 5′s faster engines trigger a bug in an arithmetic routine inside the rocket’s flight computer. The error is in the code that converts a 64-bit floating-point number to a 16-bit signed integer. The faster engines cause the 64-bit numbers to be larger in the Ariane 5 than in the Ariane 4, triggering an overflow condition that results in the flight computer crashing.First Flight 501′s backup computer crashes, followed 0.05 seconds later by a crash of the primary computer. As a result of these crashed computers, the rocket’s primary processor overpowers the rocket’s engines and causes the rocket to disintegrate 40 seconds after launch.
10. November 2000 — National Cancer Institute, Panama City. In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.Multidata’s software allows a radiation therapist to draw on a computer screen the placement of metal shields called “blocks” designed to protect healthy tissue from the radiation. But the software will only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use five.The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don’t realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.
11. Death resulted from inadequate testing of the London Ambulance Service software. Story
12. Several 1985-7 deaths of cancer patients were due to overdoses of radiation resulting from a race condition between concurrent tasks in the Therac-25 software. ReportReportStoryMoreMoreMoreMore
13. An Airbus A320 crashes at an air show. Story
14. An Air New Zealand airliner crashed into an Antarctic mountain; its crew had not been told that the input data to its navigational computer, which described its flight plan, had been changed. From “The development of software for ballistic-missile defense,” by H. Lin, Scientific American, vol. 253, no. 6 (Dec. 1985), p. 52.
15. On July 1-2, 1991, computer-software collapses in telephone switching stations disrupted service in Washington DC, Pittsburgh, Los Angeles and San Francisco. Once again, seemingly minor maintenance problems had crippled the digital System 7. About twelve million people were affected in the crash of July 1, 1991. Said the New York Times Service: “Telephone company executives and federal regulators said they were not ruling out the possibility of sabotage by computer hackers, but most seemed to think the problems stemmed from some unknown defect in the software running the networks.” Within the week, a red-faced software company, DSC Communications Corporation of Plano, Texas, owned up to glitches in the signal transfer point software that DSC had designed for Bell Atlantic and Pacific Bell. The immediate cause of the July 1 crash was a single mistyped character: one tiny typographical flaw in one single line of the software. One mistyped letter, in one single line, had deprived the nations capital of phone service. It was not particularly surprising that this tiny flaw had escaped attention: a typical System 7 station requires ten million lines of code. From The Hacker Crackdown, by Bruce Sterling, 1992. StoryMoreMoreMore
16. The Denver airport stayed closed for over a year due to software glitches in the automated baggage handling system. StoryMore
17. The U.S. Social Security Administration systems could not handle non-Anglo names, affecting $234 billion for 100,000 people, some going back to 1937. From Internet Risks Forum NewsGroup (RISKS) , vol 18, issue 80.
18. The Korean Airlines KAL 801 accident in Guam killed 225 out of 254 aboard. A design problem was discovered in barometric altimetry in Ground Proximity Warning System (GPWS). From ACM SIGSOFT Software Engineering Notes, vol. 23, no. 1.NTSB final report.
19. Software reboot during the Apollo 11 landing forced Armstrong to manually land the lunar lander. Story
20. In 1989, Swedish Gripen prototype crashed due to new software in the fly-by-wire system. Story
21. French ticket reservation software took 4 months to get working. Story
22. Software error causes patients to be declared dead.  Story
23. Software suspected in 1994 Chinook helicopter crash, killing 29.  StoryReport
24. For two days during the summer holidays in 2004, the French national railroad company’s reservation system was disorganized, due to a faulty patch. Report

Sources and more:

http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html

http://www.cs.tau.ac.il/~nachumd/verify/horror.html

http://www.ccnr.org/fatal_dose.html

http://www.wired.com/software/coolapps/news/2005/11/69355

http://www5.in.tum.de/~huckle/bugse.html

http://www.rvs.uni-bielefeld.de/publications/compendium/index.html

Pros

1. Maintenance is low in a long run
1. Test cases are concise
2. Test Cases are readable for the stake holders
3. Test Cases easy to modify
4. New test cases can reuse existing keywords more easily
2. Keyword re-use across multiple test cases
3. Not dependent on Tool / Language
4. Division of Labor
1. Test Case construction needs stronger domain expertise – lesser tool / programming skills
2. Keyword implementation requires stronger tool/programming skill – with relatively lower domain skill
5. Abstraction of Layers

Cons

1. Longer Time to Market (as compared to manual testing or record and replay technique)
2. Moderately high learning curve initially

• Hybrid automation framework

The Hybrid Automation Framework is otherwise referred to in the industry as a “Hybrid Keyword Data Driven Automation Framework”. The framework is made up of a number of reusable modules & function libraries that are developed with the following characteristics in mind:

• Maintainable
• Reusable
• Manageable
• Accessible
• Robust
• Flexibility
• Measurable

Some links that can help:

http://en.wikipedia.org/wiki/Keyword-driven_testing

http://en.wikipedia.org/wiki/Hybrid_Automation_Framework

http://en.wikipedia.org/wiki/Data-driven_testing

http://en.wikipedia.org/wiki/Modularity-driven_testing

http://www.ibm.com/developerworks/rational/library/591a.html

This article will take you step by step on how you can set up the RFT execution adapter to use with RQM

First off you need to have at least one RFT test script, a test cases already created and the RQM server must be running.

Starting the RFT execution adapter

1) Locate the install directory of RFT, then  go to the RQMAdapter folder. For example:
C:\Program Files\IBM\SDP\FunctionalTester\RQMAdapter

2) Double click on a batch file called configureadapter.bat the following cmd box and a
GUI will appear

3) In the Rational Functional Tester adapter , specify the:
RQM Server URL: HTTPS://Localhost:9443/jazz (just an example)
Login: admin(just an example)
Password: admin(just an example)

Adapter name: RFT Adapter (This can be called anything, but this will be the name that you
will see in RQM.)

Once you are authenticated the word connected will be displayed in the bottom
left hand corner. You also have the capability of stopping the adapter if needed from this
window.
The adapter console tab is used for viewing the status of the adapter.

Importing existing RFT scripts into RQM.

1. Open RQM , click the Construction icon found in the action bar on the left side of the screen and choose Import scripts.

The Import test scripts page will appear.

2. Choose script type : Functional tester

Select Use test resources that are local to a test machine

Press the select adapter button and the following page will be displayed.

3. Select the Rational Functional tester adapter that you configured in the first steps.

! Note: In the health tab you can see adapter availability, green is online and red offline.

Click the Next button, the following window will appear.

4. Provide the project path to the Rational Functional Tester project and press go.

5. Select the scripts that you want to import by selecting the checkbox and clicking the finish button.

You should be redirected to the Import test scripts page, to finish the importing operation select the scripts and press the import button.

6. To confirm that your test scripts have been imported, click on the Construction icon and choose all test scripts and confirm that the import was successful.

Associating Rational Functional Tester scripts with Test cases

You should already have a test case in this part waiting for the imported scripts .

1. From the test case table of contents, select Test scripts. Then choose the icon for Add existing test scripts

2. Select the script that will be used in the test case and press the save button.

How to execute this test case.

1. Click on Test Execution Records in the Test case table of contents

The following window will appear, click on the Generate Test execution records button.

2. After you completed a new TER, press the run button.

Now the automated script will playback.

After the test is complete, Press the Close and show results button and review the results of test after playback has completed.

Though it may seem a little difficult at first, it comes naturally after the first 20 times.
Hope the screenshots are clear and this little guide come in handy for you.

If you have any other questions, feel free to comment and I’ll gladly answer.