DOCSLIB.ORG

(PSR) Challenges, Metrics and Tools for Web Testing : a Case Study

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Thesis no: MSSE-2016-14 Performance, Scalability, and Reliability (PSR) challenges, metrics and tools for web testing A Case Study Akshay Kumar Magapu Nikhil Yarlagadda Faculty of Computing Blekinge Institute of Technology SE–371 79 Karlskrona, Sweden This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Author(s): Akshay Kumar Magapu E-mail: [email protected] Nikhil Yarlagadda E-mail: [email protected] External advisor: Saket Rustagi Project Manager Ericsson India Global Services Pvt. Ltd. Gurgaon, India. University advisor: Michael Unterkalmsteiner Department of Software Engineering Faculty of Computing Internet : www.bth.se Blekinge Institute of Technology Phone : +46 455 38 50 00 SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57 Abstract Context. Testing of web applications is an important task, as it ensures the functionality and quality of web applications. The quality of web applica- tion comes under non-functional testing. There are many quality attributes such as performance, scalability, reliability, usability, accessibility and se- curity. Among these attributes, PSR is the most important and commonly used attributes considered in practice. However, there are very few empiri- cal studies conducted on these three attributes. Objectives. The purpose of this study is to identify metrics and tools that are available for testing these three attributes. And also to identify the challenges faced while testing these attributes both from literature and practice. Methods. In this research, a systematic mapping study was conducted in order to collect information regarding the metrics, tools, challenges and mitigations related to PSR attributes. The required information is gathered by searching in five scientific databases. We also conducted a case study to identify the metrics, tools and challenges of the PSR attributes in practice. The case study is conducted at Ericsson, India where eight subjects were interviewed. And four subjects working in other companies (in India) were also interviewed in order to validate the results obtained from the case com- pany. In addition to this, few documents of previous projects from the case company are collected for data triangulation. Results.A total of 69 metrics, 54 tools and 18 challenges are identified from systematic mapping study. And 30 metrics, 18 tools and 13 challenges are identified from interviews. Data is also collected through documents and a total of 16 metrics, 4 tools and 3 challenges were identified from these documents. We formed a list based on the analysis of data that is related to tools, metrics and challenges. Conclusions.We found that metrics available from literature are overlap- ping with metrics that are used in practice. However, tools found in liter- ature are overlapping only to some extent with practice. The main reason for this deviation is because of the limitations that are identified for the tools, which lead to the development of their own in-house tool by the case company. i We also found that challenges are partially overlapped between state of art and practice. We are unable to collect mitigations for all these challenges from literature and hence there is a need for further research to be done. Among the PSR attributes, most of the literature is available on perfor- mance attribute and most of the interviewees are comfortable to answer the questions related to performance attribute. Thus, we conclude there is a lack of empirical research related to scalability and reliability attributes. As of now, our research is dealing with PSR attributes in particular and there is a scope for further research in this area. It can be implemented on the other quality attributes and the research can be done in a larger scale (considering more number of companies). Keywords: Web applications, Web testing, Performance, Scalability, Reli- ability, Quality. ii Acknowledgments We would like to thank our supervisor Michael Unterkalmsteiner for his tremen- dous and quick support whenever needed. We also thank Ericsson for providing us the opportunity to conduct case study and interviewees from other organiza- tions for participating in the interviews. Special credits go to our family, friends for providing us the support to make the thesis completed. The authors iii Contents Abstract i Acknowledgments iii 1 Introduction 1 1.1 Web testing . 1 1.1.1 Functional testing . 2 1.1.2 Non-functional testing . 2 1.2 Problem statement . 3 1.3 Thesis structure . 3 2 Background and Related Work 5 2.1 Web applications . 5 2.2 Web testing . 7 2.2.1 Functional testing . 8 2.2.2 Non-functional testing . 10 2.3 Selected attributes . 13 2.4 Research scope . 14 2.5 Related work . 15 2.5.1 Literature related to metrics . 15 2.5.2 Literature related to tools . 15 2.5.3 Literature related to challenges . 16 2.5.4 Research gap . 17 3 Method 18 3.1 Research purpose . 18 3.1.1 Objectives . 18 3.2 Research questions . 19 3.2.1 Motivation . 20 3.3 Research method . 20 3.3.1 Systematic mapping study . 21 3.3.2 Case study . 31 3.4 Data analysis . 36 3.4.1 Familiarizing yourself with the data . 36 iv 3.4.2 Generating initial codes . 37 3.4.3 Searching for themes . 38 3.4.4 Reviewing themes . 38 3.4.5 Defining and naming themes . 39 3.4.6 Producing the report . 39 3.5 Validity threats . 39 3.5.1 Construct validity . 39 3.5.2 Internal validity . 40 3.5.3 External validity . 40 3.5.4 Reliability . 41 4 Results and Analysis 43 4.1 Facet 1: Metrics for testing PSR attributes . 44 4.1.1 Systematic mapping study . 44 4.1.2 Interviews and documents . 48 4.1.3 Criteria for selection of metrics . 52 4.2 Facet 2: Tools for testing PSR attributes . 53 4.2.1 Systematic mapping study . 53 4.2.2 Interviews and documents . 56 4.2.3 Tool drawbacks and improvements . 61 4.3 Facet 3: Challenges faced by software testers . 62 4.3.1 Systematic mapping study . 62 4.3.2 Interviews and documents . 67 4.3.3 Does mitigations available in literature mitigates challenges in practice? . 72 4.4 Facet 4: Important attribute among PSR . 72 4.4.1 Interviews . 72 5 Discussion 75 5.1 Metrics for testing PSR attributes of web applications . 75 5.2 Tools for testing PSR attributes of web applications . 77 5.3 Challenges in PSR testing of web applications . 79 5.4 Most important attribute among PSR . 82 5.5 Implications . 82 6 Conclusions and Future Work 86 6.1 Research questions and answers . 86 6.1.1 RQ 1: Metrics used for testing the PSR attributes . 86 6.1.2 RQ 2: Tools used for testing the PSR attributes . 87 6.1.3 RQ 3 Challenges identified while testing the PSR attributes 89 6.1.4 RQ 4: Important attribute among PSR . 90 6.2 Conclusion . 90 6.3 Research contribution . 91 v 6.4 Future work . 92 Appendices 105 A Systematic maps 106 B SMS overview 108 C List of metrics 117 D List of tools 121 E List of challenges 122 F Interview questions 124 F.1 Technical Questions . 124 F.1.1 Tools . 124 F.1.2 Metrics . 125 F.1.3 Challenges . 126 F.1.4 General . 127 G MTC and IA identified between case company and other com- panies 128 G.1 Metrics . 128 G.2 Tools . 129 G.3 Challenges . 129 G.4 Important attribute . 129 H Consent form 130 vi List of Figures 1.1 Types of testing . 2 1.2 Thesis structure . 4 2.1 Requirements classification . 7 2.2 Types in functional testing . 8 2.3 Types in non-functional testing . 10 2.4 Research scope . 14 3.1 Systematic mapping study process . 22 3.2 Case study process steps . 31 3.3 Pyramid model for interview questions . 33 3.4 Steps for thematic analysis . 36 3.5 Themes formed in Nvivo tool for interviews . 42 4.1 Number of sources addressing the research attributes . 44 4.2 Thematic map for metrics from SMS . 45 4.3 Thematic map for metrics from interviews . 48 4.4 Thematic map for metrics from documents . 52 4.5 Thematic map for tools from SMS . 53 4.6 Thematic map for tools from interviews . 57 4.7 Types of tools obtained from interviews . 57 4.8 Thematic map for tools from documents . 61 4.9 Thematic map for challenges from SMS . 62 4.10 Number of articles addressed each theme from SMS . 63 4.11 Thematic map for challenges from interviews . 67 4.12 Number of interviewees addressed the themes . 68 4.13 Thematic map for challenges from documents . 71 4.14 Thematic map for important attribute from interviews . 73 5.1 Overlap and differences in metrics among all data sources . 76 5.2 Overlap and differences in tools among all data sources . 78 5.3 Overlap and differences in challenges among all data sources . 81 5.4 Overlap and differences in challenge areas among all data sources 81 vii 5.5 Overlap and differences in metrics between state of art and state of practice . 83 5.6 Overlap and differences in tools between state of art and state of practice . 84 5.7 Overlap and differences in challenges between state of art and state of practice . 85 A.1 Research parameters vs research attributes in SMS . 106 A.2 Research methods vs research attributes in SMS . 107 A.3 Research methods vs research parameters in SMS .
Recommended publications
  • Automated Web Application Testing Using Search Based Software Engineering

    Automated Web Application Testing Using Search Based Software Engineering

    Automated Web Application Testing Using Search Based Software Engineering Nadia Alshahwan and Mark Harman CREST Centre University College London London, UK fnadia.alshahwan.10,[email protected] Abstract—This paper introduces three related algorithms and [21]. However, of 399 research papers on SBST,1 only one a tool, SWAT, for automated web application testing using Search [20] mentions web application testing issues and none applies Based Software Testing (SBST). The algorithms significantly search based test data generation to automate web application enhance the efficiency and effectiveness of traditional search based techniques exploiting both static and dynamic analysis. The testing. combined approach yields a 54% increase in branch coverage and Popular web development languages such as PHP and a 30% reduction in test effort. Each improvement is separately Python have characteristics that pose a challenge when ap- evaluated in an empirical study on 6 real world web applications. plying search based techniques such as dynamic typing and identifying the input vector. Moreover, the unique and rich Index Terms—SBSE; Automated Test data generation; Web nature of a web application’s output can be exploited to aid applications the test generation process and potentially improve effective- ness and efficiency. This was the motivation for our work: We seek to develop a search based approach to automated I. INTRODUCTION web application testing that overcomes challenges and takes advantage of opportunities that web applications offer. The importance of automated web application testing de- rives from the increasing reliance on these systems for busi- In this paper we introduce an automated search based ness, social, organizational and governmental functions.
  • Software Quality Management

    Software Quality Management

    Software Quality Management 2004-2005 Marco Scotto ([email protected]) Software Quality Management Contents ¾Definitions ¾Quality of the software product ¾Special features of software ¾ Early software quality models •Boehm model • McCall model ¾ Standard ISO 9126 Software Quality Management 2 Definitions ¾ Software: intellectual product consisting of information stored on a storage device (ISO/DIS 9000: 2000) • Software may occur as concepts, transactions, procedures. One example of software is a computer program • Software is "intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a data processing system" •A software product is the "complete set of computer programs, procedures and associated documentation and data designated for delivery to a user" [ISO 9000-3] • Software is independent of the medium on which it is recorded Software Quality Management 3 Quality of the software product ¾The product should, on the highest level… • Ensure the satisfaction of the user needs • Ensure its proper use ¾ Earlier: 1 developer, 1 user • The program should run and produce results similar to those expected ¾ Later: more developers, more users • Need to economical use of the storage devices • Understandability, portability • User-friendliness, learnability ¾ Nowadays: • Efficiency, reliability, no errors, able to restart without using data Software Quality Management 4 Special features of software (1/6) ¾ Why is software ”different”? • Does not really have “physical” existence
  • Web Gui Testing Checklist

    Web Gui Testing Checklist

    Web Gui Testing Checklist Wes recrystallizing her quinone congruously, phytophagous and sulphonic. How imponderable is Schroeder when barbate whileand soft-footed Brewer gliff Zachery some incisure yakety-yak affluently. some chatoyancy? Fulgurating and battiest Nealson blossoms her amontillados refine Wbox aims to the field to be able to the automated support data, testing web gui checklist Planned testing techniques, including scripted testing, exploratory testing, and user experience testing. This gui content will the css or dynamic values? Test all input fields for special characters. For instance, create test data assist the maximum and minimum values in those data field. Assisted by timing testing is not tested to the order to achieve true black art relying on gui testing web checklist will best. The web hosting environments you start all web testing gui checklist can provide tests has had made. The gui testing procedures are the weak factors causing delays in agile here offering, gui testing web? At anytime without giving us a testing web gui checklist can also has on. How gui testing checklist for a gui testing web checklist to induce further eliminating redundant if there is transmitted without the below to use of jobs with. Monkey testing tool that an application or even perform testing web gui changes some test android scripts behind successful only allows an. Discusses the preceding css or if a sql injections through an application penetration testing on gui testing web? How much regression testing is enough? Fully automated attack simulations and highly automated fuzzing tests are appropriate here, and testers might also use domain testing to pursue intuitions.
  • Quality-Based Software Reuse

    Quality-Based Software Reuse

    Quality-Based Software Reuse Julio Cesar Sampaio do Prado Leite1, Yijun Yu2, Lin Liu3, Eric S. K. Yu2, John Mylopoulos2 1Departmento de Informatica, Pontif´ıcia Universidade Catolica´ do Rio de Janeiro, RJ 22453-900, Brasil 2Department of Computer Science, University of Toronto, M5S 3E4 Canada 3School of Software, Tsinghua University, Beijing, 100084, China Abstract. Work in software reuse focuses on reusing artifacts. In this context, finding a reusable artifact is driven by a desired functionality. This paper proposes a change to this common view. We argue that it is possible and necessary to also look at reuse from a non-functional (quality) perspective. Combining ideas from reuse, from goal-oriented requirements, from aspect-oriented programming and quality management, we obtain a goal-driven process to enable the quality-based reusability. 1 Introduction Software reuse has been a lofty goal for Software Engineering (SE) research and prac- tice, as a means to reduced development costs1 and improved quality. The past decade has seen considerable progress in fulfilling this goal, both with respect to research ideas and industrial practices (e.g., [1–3]). Current reuse techniques focus on the reuse of software artifacts on the basis of de- sired functionality. However, non-functional properties (qualities) of a software system are also crucial. Systems fail because of inadequate performance, security, reliability, usability, or precision, to name a few. Quality concerns, therefore, should also be front and centre in methods for software reuse. For example, in designing for the NASA Mars Spirit spacecraft, one would not adopt a “cosine” function from an arbitrary mathemat- ical library.
  • A Systematic Review on Regression Testing for Web-Based Applications

    A Systematic Review on Regression Testing for Web-Based Applications

    Journal of Software A Systematic Review on Regression Testing for Web-Based Applications Anis Zarrad* Department of Computer Science and Information Systems, Prince Sultan University, Riyadh, Saudi Arabia. * Corresponding author. Tel.: +966114948531; email: [email protected] Manuscript submitted December 12, 2014; accepted April 16, 2015. doi: 10.17706/jsw.10.8.971-990 Abstract: Web-based applications and their underlying parts are growing rapidly to offer services over the internet around the world. Web applications play critical roles in various areas such as community development, business, academic, sciences etc. Therefore their correctness and reliability become important factors with each succeeding release. Regression testing is an important means to ensure such factors for every new released version. Regression testing is a verification process to discover the impact of changes in other interconnected modules. With the goal of selecting an appropriate regression testing approach to respond adequately to any changes in Web applications, we conduct a complete systematic study of regression testing techniques in Web applications. Out of 64, we identified a total of 22 papers reporting experiments and case studies. We present a qualitative analysis for used tools, an overview of test case section techniques and empirical study evaluation for every selected work. No approaches were found clearly superior to other since results depend on many varying factors and the deployment environments. We identified the need of evidences where approaches are evaluated cost effective rather than technical description. Key words: Regressing testing, web-based application testing, empirical study, test set, software testing. 1. Introduction In today’s scenario, as the world became global and with the advent of internet technologies, Web-based applications become more effective manner for enterprises, and academic entities to produce business strategies and policies.
  • Design Rules

    Design Rules

    Design rules Chapter 7 adapted by Dr. Kristina Lapin, Vilnius University design rules Designing for maximum usability – the goal of interaction design • Principles of usability – general understanding • Standards and guidelines – direction for design • Design patterns – capture and reuse design knowledge types of design rules • principles – abstract design rules – low authority – high generality Guideline s • standards – specific design rules – high authority – limited application increasinggenerality Standards • guidelines generality increasing – lower authority increasing authority increasing authority – more general application Principles to support usability Learnability the ease with which new users can begin effective interaction and achieve maximal performance Flexibility the multiplicity of ways the user and system exchange information Robustness the level of support provided the user in determining successful achievement and assessment of goal- directed behaviour •Predictability •Synthezability Learnability •Familiarity •Generalizability •Consistency Principles of learnability Predictability – determining effect of future actions based on past interaction history – operation visibility Predictability http://www.webbyawards.com/ 7 Principles of learnability Synthesizability – assessing the effect of past actions – immediate vs. eventual honesty Synthesizability 1. 2. 3. 9 Principles of learnability (ctd) Familiarity – how prior knowledge applies to new system – guessability; affordance Principles of learnability (ctd) Generalizability
  • Software Testing: Essential Phase of SDLC and a Comparative Study Of

    Software Testing: Essential Phase of SDLC and a Comparative Study Of

    International Journal of System and Software Engineering Volume 5 Issue 2, December 2017 ISSN.: 2321-6107 Software Testing: Essential Phase of SDLC and a Comparative Study of Software Testing Techniques Sushma Malik Assistant Professor, Institute of Innovation in Technology and Management, Janak Puri, New Delhi, India. Email: [email protected] Abstract: Software Development Life-Cycle (SDLC) follows In the software development process, the problem (Software) the different activities that are used in the development of a can be dividing in the following activities [3]: software product. SDLC is also called the software process ∑ Understanding the problem and it is the lifeline of any Software Development Model. ∑ Decide a plan for the solution Software Processes decide the survival of a particular software development model in the market as well as in ∑ Coding for the designed solution software organization and Software testing is a process of ∑ Testing the definite program finding software bugs while executing a program so that we get the zero defect software. The main objective of software These activities may be very complex for large systems. So, testing is to evaluating the competence and usability of a each of the activity has to be broken into smaller sub-activities software. Software testing is an important part of the SDLC or steps. These steps are then handled effectively to produce a because through software testing getting the quality of the software project or system. The basic steps involved in software software. Lots of advancements have been done through project development are: various verification techniques, but still we need software to 1) Requirement Analysis and Specification: The goal of be fully tested before handed to the customer.
  • Usability Basics for Software Developers Usability Engineering

    Usability Basics for Software Developers Usability Engineering

    focususability engineering Usability Basics for Software Developers Xavier Ferré and Natalia Juristo, Universidad Politécnica de Madrid Helmut Windl, Siemens AG, Germany Larry Constantine, Constantine & Lockwood n recent years, software system usability has made some interesting ad- vances, with more and more organizations starting to take usability seri- ously.1 Unfortunately, the average developer has not adopted these new I concepts, so the usability level of software products has not improved. Contrary to what some might think, us- Usability engineering defines the target us- This tutorial ability is not just the appearance of the user ability level in advance and ensures that the examines the interface (UI). Usability relates to how the software developed reaches that level. The system interacts with the user, and it includes term was coined to reflect the engineering ap- relationship five basic attributes: learnability, efficiency, proach some usability specialists take.3 It is between usability user retention over time, error rate, and sat- “a process through which usability character- and the user isfaction. Here, we present the general us- istics are specified, quantitatively and early in interface and ability process for building a system with the the development process, and measured desired level of usability. This process, which throughout the process.”4 Usability is an is- discusses how most usability practitioners apply with slight sue we can approach from multiple view- the usability variation, is structured around a design- points, which is why many different disci- process follows a evaluate-redesign cycle. Practitioners initiate plines, such as psychology, computer science, design-evaluate- the process by analyzing the targeted users and sociology, are trying to tackle it.
  • Cigniti Technologies Service Sheet

    Cigniti Technologies Service Sheet

    Cigniti Technologies Service Sheet Cigniti Technologies is an Independent Software Testing Services Company headquartered in Irving, Texas. Cigniti offers Test Consulting, Enterprise Mobility Testing, Regression Automation, Security and Performance Testing services. Over the last 14 years, leveraging its Smart Tools, Cigniti helped Enterprises and ISVs build quality software while improving time to market and reducing cost of quality. Designed to deliver quality solutions, the service portfolio spans technologies transcending Cloud, Mobile, Social, Big Data and Enter- prise IT across verticals and ensures impeccable standards of QA. World’s 3rd Largest Independent Software Testing Services Company Dallas | Hyderabad | Atlanta | San Jose | Des Moines | London | Toronto | www.cigniti.com Service Sheet Over the last decade, there has been a lot of transformation in the philosophy of testing and several tools have been introduced in the market place. With so many choices around, it has become a real challenge to choose the right testing partner / service provider. The Testing industry has witnessed a phenomenal growth in term of offerings, tools, and infrastructure with diverse engagement models. Now, it has become a lot more important for organizations to choose the right testing partner. Cigniti delivers Independent Quality Assurance Services backed by its proprietary IP. As a strategic partner, Cigniti brings comprehensive service offerings in the Quality Assurance space which accelerate overall test efforts for its clients. Cigniti’s Service Offerings TCoE Performance Testing Security Testing Cigniti's Test Center of Excellence Cigniti’s new age performance Cigniti’s security testing services lays down roadmaps for scalable testing frameworks initiate and ensure early detection with com- frameworks that enrich business revitalize performance across prehensive vulnerability assess- outcomes with speed, skill and systems, networks and software ment and match the emerging accuracy.
  • Stress Testing Embedded Software Applications

    Stress Testing Embedded Software Applications

    Embedded Systems Conference / Boston, MA September 20, 2007 ESC-302 Stress Testing Embedded Software Applications T. Adrian Hill Johns Hopkins University Applied Physics Laboratory [email protected] ABSTRACT This paper describes techniques to design stress tests, classifies the types of problems found during these types of tests, and analyzes why these problems are not discovered with traditional unit testing or acceptance testing. The findings are supported by citing examples from three recent embedded software development programs performed by the Johns Hopkins University Applied Physics Laboratory where formal stress testing was employed. It also defines what is meant by the robustness and elasticity of a software system. These findings will encourage software professionals to incorporate stress testing into their formal software development process. OUTLINE 1. INTRODUCTON 1.1 What can be learned by “breaking” the software 2. DESIGNING A STRESS TEST 2.1 What is a reasonable target CPU load? 2.2 Other ways to stress the system 2.3 Characteristics of a Stress Test 3. REAL WORLD RESULTS 3.1 Case #1: Software Missed Receiving Some Commands When CPU Was Heavily Loaded 3.2 Case #2: Processor Reset when Available Memory Buffers Were Exhausted 3.3 Case #3: Unexpected Command Rejection When CPU Was Heavily Loaded 3.4 Case #4: Processor Reset When RAM Disk Was Nearly Full 3.5 Synopsis of All Problems Found During Stress Testing 4. SUMMARY 1. INTRODUCTON Traditional Software Acceptance Testing is a standard phase in nearly every software development methodology. Test engineers develop and execute tests that are defined to validate software requirements.
  • Testing Techniques Selection Based on SWOT Analysis

    Testing Techniques Selection Based on SWOT Analysis

    International Journal of Knowledge, Innovation and Entrepreneurship Volume 2 No. 1, 2014, pp. 56—68 Testing Techniques Selection Based on SWOT Analysis MUNAZZA JANNISAR, RUQIA BIBI & MUHAMMAD FAHAD KHAN University of Engineering and Technology, Pakistan Received 02 March 2014; received in revised form 15 April 2014; approved 22 April 2014 ABSTRACT Quality is easy to claim but hard to achieve. Testing is a most essential phase in software development life cycle not only to ensure a project’s success but also customer satisfaction. This paper presents SWOT Analysis of three testing tech- niques—White-Box, Black-Box and Grey Box. The testing techniques are evaluated on the basis of their strengths, weaknesses, opportunities and threats. The analysis in this paper shows that selection of the techniques should be based on a set of defined attrib- utes, context and objective. The findings in this paper might be helpful in highlighting and addressing issues related to testing techniques selection based on SWOT analysis. Keywords: Black Box Testing, White Box Testing, Grey Box, SWOT Introduction Software plays a substantial role in every sphere of life. It is a key reason why software engineering continually introducing new methodologies and improvement to software development. The capacity of organisations to achieve customer satisfaction or to cor- rectly identify the needs of customers can be misplaced, leading to ambiguities and un- wanted results 1. Researchers have suggested many testing techniques to deal with fault identification and removal subjects, before the product [software] is shipped to cus- tomer. Despite many verification and validation approaches to assuring product quality, defect-free software goal is not very often achieved.
  • Test Center of Excellence How Can It Be Set Up? ISSN 1866-5705

    Test Center of Excellence How Can It Be Set Up? ISSN 1866-5705

    ISSN 1866-5705 www.testingexperience.com free digital version print version 8,00 € printed in Germany 18 The Magazine for Professional Testers The MagazineforProfessional Test Center of Excellence Center Test How can itbesetup? How June 2012 Pragmatic, Soft Skills Focused, Industry Supported CAT is no ordinary certification, but a professional jour- The certification does not simply promote absorption ney into the world of Agile. As with any voyage you have of the theory through academic mediums but encour- to take the first step. You may have some experience ages you to experiment, in the safe environment of the with Agile from your current or previous employment or classroom, through the extensive discussion forums you may be venturing out into the unknown. Either way and daily practicals. Over 50% of the initial course is CAT has been specifically designed to partner and guide based around practical application of the techniques you through all aspects of your tour. and methods that you learn, focused on building the The focus of the course is to look at how you the tes- skills you already have as a tester. This then prepares ter can make a valuable contribution to these activities you, on returning to your employer, to be Agile. even if they are not currently your core abilities. This The transition into a Professional Agile Tester team course assumes that you already know how to be a tes- member culminates with on the job assessments, dem- ter, understand the fundamental testing techniques and onstrated abilities in Agile expertise through such fo- testing practices, leading you to transition into an Agile rums as presentations at conferences or Special Interest team.