The Geek Withinletting the inner geek shine through…

Abstract

Open source software has generated much interest, especially in the wake of a slow economy.  This has forced many Information Technology (IT) departments to cut back on spending.  One of the main reasons open source technology is being considered by more IT departments is because open source technology is perceived as being free of charge.  While that perception is not all together true, this article will discuss an example of the real cost savings of open source technology as an enterprise system solution.  All costs related to the implementation of an open source server operating system including the hardware costs to run the operating system software, training costs to setup the operating system software, support cost to maintain the operating system software, and staff salary to administer the operating system software will be recognized in this article. 

Open Source Technology – The Cost at the Enterprise Level

     Open source refers to any program whose source code is made available for use or modification as users or other developers see fit. (Historically, the makers of proprietary software have generally not made source code available.)  Open source software is usually developed as a public collaboration and made freely available (Open Source, 2008).  When companies are deciding on whether to use open source products versus commercial products the benefits of both choices are apparent.  Commercial products typically favor visible features (giving marketing advantage) over hard to measure qualities such as stability, security and similar less glamorous attributes. Some experts describe this phenomenon as quality versus features (Benefits of Using Open Source, n.d.).  This paper examines the enterprise level cost of an open source technology system.  Different factors discussed in this paper include the cost of open source software, the cost of open source hardware, the cost of open source training to support this platform, and the salary requirements for open source administrators.  For the purpose of this paper, the total cost of ownership of an open source production database server will be discussed in detail.

     There are many different distribution options or ‘flavors’ a technology manager can choose from that are considering an open source operating system.  Linux is about freedom and choice, so one has plenty of freedom to choose the flavor of Linux that best fits the business needs (Linux Distributions, n.d.).  Common flavors of Linux include:

• Red Hat Enterprise Linux
• Mandrake Linux
• The Fedora Project
• The Debian Project
• Knoppix
• SUSE Linux
• Slackware Linux
• MEPIS Linux
• Ubuntu Linux
• Xandros
• PCLinux OS
• Linspire

     Jim Klein (2009) writes that Total Cost of Ownership (TCO) can be defined as all of the costs of acquiring and maintaining a network of computers. This includes the cost for Hardware and software technology – client computers, servers, software, printers, networking equipment, external service providers

• Direct labor – those responsible for purchasing, training, implementation, management and support of the computer environment
• Indirect labor – time spent by users in training, dealing with computer and networking issues, and effect of computer or network down-time.

     Red Hat Linux is one of the most supported Linux operating systems on the market.  Red Hat provides operating systems for the individual users as well as the large enterprises.  When pricing operating systems it’s very important to know the hardware that this operating system will reside on.  For example, it makes a difference if this operating system is a dual processor or a quad processor.  For the purpose of this paper, the server we want to install Red Hat on is a quad Intel processor.  Because this server is a production server, 24/7 support is required.  According to Red Hat, the best license option for this configuration is the ‘Red Hat Enterprise Linux Advanced Platform, Premium Subscription’ (Server Operating Systems, n.d.).  When you subscribe to a Red Hat subscription, you’re renting the use of that software.  With the Premium Subscription of Red Hat Enterprise Linux Advanced Platform you get the following:

• Unlimited CPU processors
• Unlimited virtualized guests
• Red Hat global File System and Cluster Suite
• Web and phone-based comprehensive support
• 24×7 coverage
• 1 hour critical response (4 hour normal response time)
• Red Hat Network Update
• Product Updates
• Installation and documentation media
• Covered under the Open Source Assurance program
• Server applications to include ISV applications, Apache, Samba, nfs, ftp, Tomcat, MySQL, and PostgreSQL

     For the purpose of this paper the server this Red Hat software will run on will be a Dell PowerEdge Energy Smart Quad Core Intel Xeon L5410 server.  This server comes with 8 Gig of ram and 3 73 gig hard drives.  The cost of this server is $6250.00 (Dell, Select Components, n.d.).  This hardware is approved by Red Hat as a supported hardware platform. 

     The skill sets required to support an open source environment requires a person who completely understands how each component in an environment works.  In most environments this person’s title would be a Linux administrator.  A capable Linux administrator will have a variety of skills.  Jay Beal (2004) provides skill sets a Linux Administrator should have would include security, operating system hardening, software installation, hardware installation, system assessment, troubleshooting, and intelligence gathering (Essential Linux Skills, 2004).

     Security in any environment is essential.  A Linux administrator must understand that any port on any server is venerable to an attack.  Every port must be accounted for and the Linux administrator needs to know what log files are tracking all port traffic.  Those log files need to be monitored daily for malicious attacks.  In case an attack occurs, a Linux administrator should know how to recover from a server that has crashed.

     Most default server installations install more services that are generally needed.  A Linux administrator needs to be aware of the purpose of the server and understand specifically what services need to be running and just as important, what services do not need to be running.  Those services that do not need to be running should be shut down and the Linux administrator needs to recognize these services and shut those services down along with the ports they use.

     At some point, the server may need software and/or hardware upgrades.  A Linux administrator needs to be prepared to apply upgrades or patches for software upgrades.  Those software patches may require more hardware in order to run optimally.  In this case a Linux administrator needs to be comfortable upgrading the hardware if there is a need to do so. 

     Finally, the Linux administrator needs to be able to assess the system and if there is concern, research the problem and find the solution.  Because open source software is mostly supported by the ‘community’, it can be tedious to find solutions to complex problems.  If the Linux administrator is fortunate, support is paid for when the subscription is obtained.  If support is not paid for, the Linux administrator has to rely on good research skills to solve the problem.

     Finding a good Linux administrator to administer the open source environment is hard to do.  When you do find them, it is obvious that they are in great demand by the salary requirements they are demanding.  A seasoned Linux administrator that is industry certified will demand as much as $90k – 120k per year if he/she is considered a full-time employee (Salary Search, n.d.).  Linux contractors range from $60.00 – $120.00 per hour. 

     One of the benefits of having an open source environment is training courses are usually reasonably priced.  The only difficulty is finding a training center that specializes in open source technology training.  Most 3-day classes will range anywhere from $1200 to $1400 dollars per class.  Most 5-day classes will range from $1800 – $2200 dollars per class.  If your Linux administrator is a good self-learner there are many options online that he/she can take advantage of.  Many websites offer free online training videos and free training manuals for anyone interested in taking advantage of them.

     As it is evident, the notion of open source technology being free is far from true.  However, many experts agree that the total cost of ownership is less than it would be if commercial software was being used.  Dan Orzech (2002) writes that the cost of Linux is roughly 40% that of Windows, and only 14% that of Sun Microsystem’s Solaris based on a study of various operating systems over a 3 year period.  Below is a table that summarizes the total cost of ownership for a typical open source database environment.

Total Cost of Ownership
(Annual)

Description of Service

Cost

Linux OS Software including Premium Support

$1299.00 per year

Linux Administrator

$100,000 per year

Ongoing Training

$1500.00 per year

Total Cost

$102,799.00 per year

Total Cost of Ownership

(One-Time Cost)

Server Hardware

$6250.00 purchase price

Total One-Time Cost

$6250.00

     As one can see from the table above, open source technology is not free.  Open source proponents and proprietary companies disagree on the total cost of ownership. Proponents claim that even if open source requires more expertise, the TCO is ultimately lower.  Companies claim that the required expertise is daunting and the other costs of proprietary solutions are exaggerated (Open Options, 2005).  Yes, there are some ways that prices could be cut.  The Linux administrator could be contracted out on an ‘as needed’ basis.  It is also possible to purchase a server with fewer features and less processors if cost was a factor when purchasing hardware.  Training could be kept to a minimum or even limited to online training only.  Even with all this being said, the myth that open source technology is free just is not a true statement, especially in a production environment.  However, open source technology is the preferred technology in many IT shops for reliability reasons. 

Jeff Merritt

Article Source:http://www.articlesbase.com/information-technology-articles/open-source-technology-the-cost-at-the-enterprise-level-891004.html

SAP Business One is a fully integrated enterprise resource planning software solution, which encompasses business areas such as: finance, sales, purchasing, stock management, servicing, production and human resources. Essentially the software solution provides the range of functions required by the SMBs and improves operational efficiency as well as reducing cost base. In addition, the software features a high level of integration as well as navigation options within the functional areas. The great strength of SAP Business One is in its extreme flexibility to meet the different needs of SMBs. Different tools are provided for the customer and the consultant for use in adapting processes to fulfil the requirements of the individual business (for example, user-defined fields and tables, SQL queries and software development kit). For this reason, SAP Business One is used across all industries and has a correspondingly broad customer base. The scope of customers who use the software also varies, ranging from businesses with one deployed work centre up to businesses with more than 100 work centres.

Making the right IT investment is difficult. Making the right implementation choice is just as hard. Official Certification for SAP Business One (2007) implementation validates that you as a solution consultant have the training you need to apply practical knowledge to your SAP Business One project. There are no eligibility requirements for certification. Certification candidates should, however, have the know-how that can be obtained in corresponding courses in the SAP training programme, and preparatory courses given by the instructor for the operating system and database concerned.

B1 Academy is entirely focussed on SAP Business One software package. We strive to provide best-in-class curriculum training services in implementing the software. We are a registered Limited Company in private ownership and have been providing training courses since 2005.

At B1 Academy our aim is to equip you with thorough knowledge of SAP Business One to prepare you both for certification and employment. You will be taught by our experienced and SAP certified instructors at our London training centre in Hammersmith or King’s Cross or Manchester training centre in Piccadilly Gardens.

The course runs for 8 days as follows:
TB1000 – Logistics – 2 days
TB1100 – Accounting – 2 days
TB1200 – Implementation & Support – 3 days
2007 Exam Preparation – 1 day

Different modes of study are available:
Day
Evening
Weekend

Becoming a Certified Implementation Consultant at B1 Academy is easy:
1. Register and book your training course
2. Complete the training course + Implementation case study
3. Pass the exam (B1 Academy has 98% pass rate)
4. Our career officer will professionally remake your CV
5. We give you interview coaching on the 20 most frequently asked questions
6. We guarantee that you will be invited to a minimum of 2 interviews within 3 months of getting certified

SAP Business One solution market is relatively unsaturated and there are plenty of employment opportunities available right now. It has never been a better time to enter the SAP Business One employment market with an average salary of £30,000 and £200m spending by SAP into Research & Development for their portfolio of SME solutions. The Applications team at B1 Academy are real people with real experience in the SAP Business One jobs market.

Visit B1 Academy www.b1academy.co.uk

Anthony Ryllat has been an SAP Business One Certified Implementation Consultant for the past 4 years, working a wide range of industries. He has also been training students at B1 Academy for the past 2 years.

Article Source:http://www.articlesbase.com/information-technology-articles/becoming-an-sap-business-one-implementation-consultant-900973.html

First of all let us see the meaning of the term Regression Testing

According to Wikipedia, “Regression testing is any type of software testing which seeks to uncover software regressions”. Such regressions occur whenever software functionality that was previously working correctly, stops working as intended. Typically regressions occur as an unintended consequence of program changes. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged.

Concluding Definition of “Regression Testing”:

It is quite natural to have changes in the code during software development and maintenance phase. Thus a software program that happened to execute properly earlier might stop functioning the same way after the changes. Hence re-running of the test cases of a program, which functioned correctly before the changes, and with an objective of detecting failures, can be concluded to be “Regression Testing”.

Regression testing is a quality control measure aimed at ensuring the following two conditions:

a) Newly modified code meets the specified requirements.

b) Unmodified code has not been affected by the change as above.

Going by the definition, regression testing is repetitive. Hence majority of the tests would be best suited to automation, where after performing few test iterations, test automation would prove to be extensively costs effective as compared to the strenuous manual process.

Why defects get introduced during changes?

Correctly working applications fail due to either incorrect or incomplete changes made in them. In software industry, the rate of defect introduction in the applications is quite high. In general, one out of six attempts made over the applications to correct them are faulty themselves.

The prime reason of high rate of defects getting introduced is

1) Poor system documentation held by the developers.

2) Tendency of the developers to tackle the symptoms instead of identifying the underlying causes.

3) Lack of experience of the developers.

Objectives of regression testing:
1) The objective of regression testing is to identify unexpected defects. These defects or faults are the ones, which remained in the system, due to the reason that, while changing the code, the developer probably could not completely understand the internal correlations of the code.

Hence regression testing remains the only reliable means to provide adequate confidence that changes or additions in the code are safe & are not liable to “break” the existing functionality of the application.

Regression testing thus becomes a must, every time code is modified or is used in a new environment. It is essential to verify the integrity of the code with a view to identify & fix the defects as quickly as possible.

2) Objective of regression testing is not only limited to testing the correctness of an application but extends to track the quality of its output as well. For example, while designing a compiler, regression-testing can lay focus on the size of the code, time for doing simulation and time to run the test suites.

What are the Best Practices / strategies for Regression Testing?

1) Formulate a policy for regression testing on regular basis, if we want to achieve success in developing reliable & definitely predictable software applications.

2) Perform standard actions defined in the testing procedure & check the desired responses for correctness. Any failure of the system to comply with the set of desired responses becomes a clear indicator of system regression.

3) Ensure that the regression test must be correct & should not be out of date.

4) Do careful analysis of every defect escaping detection during the process of regression testing. This would need a careful updating of the regression test cases, so that such defects don’t give us a slip in future.

5) Generally unit test cases & integration test cases are used to build regression test cases; hence instead of having one large regression test, it is better to create a logical batch of such test cases in the form of a comprehensive test suite. This would provide flexibility of executing small unit tests in case of urgency or time-pressures.

6) Going by the famous 80 / 20 principle of management, we can assume that there is a great probability of 20% functions being used during 80% of the time. Hence test suites for regression testing can be designed accordingly.

Severity of a problem in a comparatively lesser common functions would be lesser being used by small number of users. Thus major focus of our regression tests must lie over excessively used transactions, menus & screens etc.

7) For smaller projects, do regression testing after every successful compile or at least once in a week. Such repetitive activities can be automated with the help of tools like HP-QuickTest Professional etc.

Depending upon the risk factors across the business, we can design the regression test suite. It has been seen that there are certain types of failures, which are not frequent, but whenever they happen, they leave serious impact on the business process.

Hence whenever any change is made to the system or to the environment, we should perform regression tests covering such vulnerable areas having negative impact on the business.

9) We need to identify the application areas known to have high rate of failures & include more regression tests in them.

10) Tightly link the regression testing with functional testing & create the regression tests out of successful test cases created & used during the functional testing.

11) Regular rerunning of successful functional test cases (which happen to verify the desired functionality of the application) as regression tests.

12) Regression testing should be like a chain, starting from the unit level, involving adaptation & rerunning of the unit tests after sensing any change to the unit. The chain of regression tests continues further across integration testing, system testing, user acceptance testing and across all operational phases under the SDLC.

13) As a best practice, before releasing any build across the masses or across any live environment in the organization, stringent regression tests must be executed. Such an approach would help in uncovering major defects if any, which could otherwise have serious Implications towards cost, productivity, schedule & most important being the adverse effect on company’s reputation.

14) As a best practice, execution of regression tests at regular intervals should be made a continuous exercise in case of Web based & all multi user systems. Regular regression testing helps in maintaining a continuous check on the performance of important transactions being within the specified limits.

Any factor responsible for slowing down the response time for any major transaction can be easily pin pointed by frequent regression testing.

15) Apart from testing the functional aspects, we need to perform regression tests covering non-functional attributes of the application like its performance, security, usability etc. Reason being, it has been seen that in many cases, a minor change in the code or design produces considerable effect on the system performance.

16) Before running the time consuming regression testing scenarios over newly delivered code, doing Smoke Testing or Sanity Testing is helpful in saving time, since Smoke Testing or Sanity Testing generally uncover the obvious errors. Early detection of such errors can lead to early fixation.

17) We should have a careful eye on the side effects of the bug fixes. There is great probability that the bug gets fixed but at the same time our fix could have introduced another bug in the system.

18) Regression testing must be treated as an integral part of the extreme programming method of software development. This would involve extensive automated testing of the complete application at every stage during the SDLC.

Pitfalls of Results of Regression Testing

1) We should not become happy & get satisfied just because the system has responded as desired, since there can be every probability of presence of introduced defects, which might have escaped the detection.

2) In majority of companies the critical functionality of the applications are verified once, and an assumption is drawn that it would continue to behave well until modified intentionally. However, the fact remains that even minor changes in code as a matter of routine are liable to have serious unexpected side effects, which can probably break the functionality verified earlier.

http://www.softwaretestinggenius.com
A Storehouse of Complete Knowledge on Software Testing & QA under one Roof

Article Source:http://www.articlesbase.com/information-technology-articles/know-the-regression-testing-its-best-practices-902389.html