| دانلود رایگان مقاله انگلیسی + خرید ترجمه فارسی | |
| عنوان فارسی مقاله: | طراحی و ساخت شرکت آزمون نرم افزار |
| عنوان انگلیسی مقاله: | Designing and Building a Software Test Organization |
| دانلود مقاله انگلیسی: | برای دانلود رایگان مقاله انگلیسی با فرمت pdf اینجا کلیک نمائید |
| مشخصات مقاله انگلیسی (PDF) | |
| سال انتشار | 2008 |
| تعداد صفحات مقاله انگلیسی | 9 صفحه با فرمت pdf |
| رشته های مرتبط | مدیریت و فناوری اطلاعات |
| مجله | کنفرانس بین المللی تست نرم افزار، تأیید و اعتبار(International Conference on Software Testing, Verification, and Validation) |
| لینک مقاله در سایت مرجع | لینک این مقاله در سایت IEEE |
| نشریه | IEEE |
| مشخصات و وضعیت ترجمه مقاله (Word) | |
| تعداد صفحات ترجمه مقاله | 21 صفحه با فرمت ورد، به صورت تایپ شده و با فونت 14 – B Nazanin |
بخشی از ترجمه:
طراحی و ساخت یک سازمان تست کننده نرم افزار را می توان به مجموعه ای از تصمیمات مختلف و درک عوامل محیطی که بر این تصمیمات تاثیر می گذارند تفکیک کرد.این مقاله خلاصه ای است از سه استراتژی کلیدی (استراتژی اتوماسیون-استراتژی سازمانی-استراتژی تست) که در این زمینه باید مورد توجه قرار گیرند و درباره چگونگی تاثیرگذاری عوامل محیطی مختلف نظیر حوزه محصول، حوزه مسئله و حوزه کسب و کار بر این استراتژی ها بحث می کند. این مقاله بر اساس تجربه بدست آمده در ساخت سازمان های تست کننده نرم افزار در یک شرکت بین المللی نرم افزار که در برگیرنده چندین تکنولوژی و چندین قسمت از بازار است، نوشته شده است.بعلاوه این مقاله توصیه های عمومی برای هر یک از این تصمیمات و اطلاعات لازم برای درخورسازی این تصمیمات با نیازهای خاص سازمان خواننده را فراهم می نماید.
١-مقدمه
پیشتر، تعهدات سازمانی در زمینه کیفیت نرم افزار محدود به شرکت های مسئول در قبال تولیده سیستم های حیات محور و ماموریت محور یا برخی شرکت های تولید نرم افزار و گاهاً سازمان های تولید نرم افزار مالی بوده است. بخش اعظم سایر شرکت ها برای تضمین کیفیت بر تیم های توسعه خود یا سازمان های کوچک تست کننده در قالب تیم های توسعه متکی بودند. با رشد و بالندگی صنعت نرم افزار و افزایش رقابت در بسیاری از قسمت های بازار، کیفیت محصول تبدیل به یکی از وجوه تمایز در تصمیمات خرید مشتریان شده است. بدین دلیل امروزه بسیاری از شرکت ها سرمایه گذاریهای عظیمی جهت سازمان های اختصاصی کیفیت نرم افزار می کنند.
بخشی از مقاله انگلیسی:
Abstract Designing and building a software test organization can largely be broken down into a set of decision categories and an understanding of the environmental factors which influence those decisions. This paper summarizes the three key strategies which must be addressed (automation strategy, organizational strategy and test strategy) and discusses how various environmental factors such the product domain, the problem domain and the business domain influence those strategies. This paper is based on experience generated building test organizations in a large international software company spanning several technologies and market segments. Additionally, this paper provides general recommendations for each of these decisions and the information required to tailor those decisions to the specific needs of the reader’s organization. 1. Introduction Historically, major organizational commitments to software quality have been limited to companies responsible for the production of life critical or mission critical systems, some software product companies and the occasional financial software organization. Most other companies relied on the development teams themselves or small testing organizations contained within the development teams to ensure quality. With the maturation of the software industry, and the increasing competition in most segments, product quality is becoming one of the key differentiators in customer purchase decisions. For this reason, many companies today are making significant investments in dedicated software quality organizations. There are literally countless resources which purport to tell you how a software test organization should work in a vacuum and what an ideal test organization should look like. However, companies do not exist in a vacuum and how we accommodate our business needs when establishing a test organization has far more impact on the eventual success of that effort than endless debates about the relative merits of competing test methodologies. This paper provides a pragmatic overview of the key strategic decisions which should be made when establishing a dedicated test organization and the environmental factors which influence those decisions. While it does not claim to answer all questions for all potential readers it attempts to provide a solid overview of the key factors involved in the decisions. It also makes general recommendations based on those factors which can be tailored to fit each situation. Before it is possible to have meaningful, value added discussions on the relative merits of specific competing test methodologies, it is important to first understand the strategic decisions which must be made and the nature of certain key environmental factors in your company. The two primary questions you need to answer when forming a new test organization are “How am I going to structure my organization?” and “How is my test process going to work?” An additional key question: “How much test automation will I do?” is technically a detail of the second question above, however, because this is the detail which has the single greatest impact on your overall approach to testing and on your organizational structure and staffing as well, it is treated here as a third separate question. This means that the primary strategies which must be defined for your organization include the following: Automation Strategy – What basic decisions will you make related to the mix of test automation and manual testing in your organization. This is separated from the general topic of a test strategy since it has such a significant impact on the next item. Organizational Strategy – What is the nature of the organization which you plan to build? This includes the team size and the skills mix of the eventual personnel as well as the staffing strategy which will be followed. Test Strategy – The overall approach to product validation including validation methodologies (inspection, analysis and demonstration), division of 2008 International Conference on Software Testing, Verification, and Validation 0-7695-3127-X/08 $25.00 © 2008 IEEE DOI 10.1109/ICST.2008.49 978-0-7695-3127-4/08 $25.00 © 2008 IEEE 412 414 responsibilities, work sequencing and coordination plans with development and program management It is largely possible to evolve effective strategies in each of these categories by thoroughly understanding the organizational needs and desires and a set of environmental factors which heavily influence each of these strategies. There are many aspects which can impact the decisions you will make about the strategies above. These include things like the size of the products and projects which the new team will own, the architecture of these same projects and the resources and commitment level of the sponsoring organization. For planning simplicity these issues are grouped into three environmental factor sets defined below: Product Domain – This term refers to the distribution, sales and support aspects of a product. It distinguishes between engineer to order development projects and shrink wrapped products which might be sold through a distribution channel and will have multiple updated versions over the course of the products life. Problem Domain – This term refers to the physical nature of the software and the problem domain area the product targets. It includes architectural descriptions of the product in question and factors such as the complexity of the problem space and any legislative or statutory restrictions placed on the product. Business Domain – This term refers to the maturity and fiscal health of the organization responsible for producing a product as well as the existing processes or standards already adopted by the parent organization. The author has found that these three sets form a sufficient and intuitive framework for making these decisions. It is sufficient because there are no significant issues which cannot reasonably fit into one of these sets and intuitive because experience has shown this framework to be understandable by all key project stakeholders. Obviously, this is not the only framework that could be used to facilitate these decisions but experience has proven it to be one effective basis set. A thorough understanding of how these factors relate to your organization will enable you to intelligently address the decisions you need to make about the eventual organizational structure and processes you will implement. The information in this article is distilled from experience gained in the process of building, or significantly re-engineering, eight separate software test organizations within a large international software company across several market segments and technologies and over the past ten years. In most instances team transformations occurred in less than 1 year and resulted in productive, valued software test organizations. The current team where this approach has been applied has produced a 2000% increase in software automation and a 75% reduction in manual test effort, while meeting all previously scheduled major project commitments over a 15 month period. Where data is supplied in this article it is either described as the result of a specific documented measurement activity or it is representative of the results observed by one or more of these team building experiences. When data presented is the result of a specific data acquisition effort that will be noted. 2. Automation Strategy This is a classic area of ongoing debate in the industry. While the general trend in larger software organizations is definitely toward increased automation there are still many companies, possibly a majority, that engage solely in manual testing. In the author’s experience of discussions with a minimum of two to three dozen smaller companies on this topic over the past year, less than 20% generated any substantive test automation beyond basic unit testing. There are many factors arguing in favor of automated testing including increased repeatability of testing, ability to deal with complex stress and performance scenarios and the potential for increased functional and code coverage. One of the most direct and least controversial approaches to making this decision is based on a simple return on investment (ROI) analysis. The simple reality is that most corporate or organizational management is primarily interested in minimizing organizational costs and maximizing the value delivered by organizational resources. Analyzing the ROI of proposed automation efforts serves to align your project proposals with the decision framework that most management favors. This creates the added benefit of producing a strong justification for your decision process within a framework easily understood by management. This analysis is primarily driven by factors encompassed within the Product Domain area mentioned above. The primary factor here is the lifecycle of the product under development. The non recurring cost of automating the tests and the subsequent minimal recurring cost of running those tests is balanced against the larger recurring costs of manual testing to determine a cost breakeven point. This point is based on the total number of test runs which will be required on any given product. Given the relative cost of automating a test vs. the manual cost of a single execution instance, it is a straight forward matter to calculate this breakeven point. Typical industry numbers for automation costs vs. manual costs indicate that the cost of automation is approximately 413 415 four to six times greater than the single instance manual execution cost. In one recent project that the author managed a team of five engineers ran a full manual test pass prior to completing automation of the test suite. This suite was comprised of approximately 500 tests and the relative cost of automation to manual execution came out to be a factor of 4.3 to one. Interestingly, this ratio will improve over time as this team adds additional automated tests because over 60% of the total effort was associated with the implementation of re-useable automation objects which will not be experienced for future automation enhancements. This ratio would possibly run higher in an environment with more stringent process requirements on the test automaton (i.e. mission critical or life critical business areas) but that would also probably be balanced out by the increased cost associated with logging manual results in this environment.
| دانلود رایگان مقاله انگلیسی + خرید ترجمه فارسی | |
| عنوان فارسی مقاله: | طراحی و ساخت شرکت آزمون نرم افزار |
| عنوان انگلیسی مقاله: | Designing and Building a Software Test Organization |
