Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Test levels Unit testing tests the minimal software component and sub-component or modules by the programmers. Integration testing exposes defects in the interfaces and interaction between integrated components(modules). Functional testing tests the product according to programmable work. System testing tests an integrated system to verify/validate that it meets its requirements. Acceptance testing testing can be conducted by the client. It allows the end-user or customer or client to decide whether or not to accept the product. Acceptance testing may be performed after the testing and before the implementation phase. See also Development stage Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users. It should be noted that although both Alpha and Beta are referred to as testing it is in fact use emersion. The rigors that are applied are often unsystematic and many of the basic tenets of testing process are not used. The Alpha and Beta period provides insight into environmental and utilization conditions that can impact the software. After modifying software, either for a change in functionality or to fix defects, a regression test re-runs previously passing tests on the modified software to ensure that the modifications haven't unintentionally caused a regression of previous functionality. Regression testing can be performed at any or all of the above test levels. These regression tests are often automated.
  • slides

    1. 1. Presenting a JUnit Testing Framework to a Multi-University Community Romerl Elizes May 4, 2007
    2. 2. Agenda <ul><li>Introduction </li></ul><ul><li>Coeus </li></ul><ul><li>JUnit Testing Framework </li></ul><ul><li>Community of Testers </li></ul><ul><li>Literature Review </li></ul><ul><li>Relevance </li></ul><ul><li>Methodology </li></ul><ul><li>Future Work </li></ul><ul><li>Questions and Answers </li></ul><ul><li>References </li></ul>
    3. 3. Introduction <ul><li>Presentation goals: </li></ul><ul><ul><li>will highlight work done on developing a JUnit Testing Framework for the Coeus Application </li></ul></ul><ul><ul><li>will explore its applicability to a multi-university community </li></ul></ul><ul><ul><li>introduce the concept of a “Community of Testers” </li></ul></ul>
    4. 4. Coeus <ul><li>Coeus: </li></ul><ul><ul><li>Electronic Research Administration (eRA) system developed by MIT </li></ul></ul><ul><ul><li>Automates a variety of university research functions: proposal tracking, proposal development, grant tracking, conflict of interests, internal review board, federal electronic submissions, award budgeting, and compliance standards </li></ul></ul><ul><ul><li>Follows an Open Source Community model called the Coeus Consortium </li></ul></ul>
    5. 5. Coeus <ul><li>Coeus Consortium: </li></ul><ul><ul><li>Participant universities who lack the resources can participate in the Consortium for a nominal annual fee </li></ul></ul><ul><ul><li>Participant universities can download the software binaries and code and customize their deployment based on university needs </li></ul></ul><ul><ul><li>Each university only uses a select number of modules </li></ul></ul><ul><ul><li>Each university can contribute back to the Consortium if it finds an innovative solution to any issues with the module </li></ul></ul><ul><ul><li>Includes 100+ member universities, government agencies, corporations </li></ul></ul>
    6. 6. Coeus <ul><li>Coeus Testing: </li></ul><ul><ul><li>Internal testing mechanism practiced by the developers </li></ul></ul><ul><ul><li>One week testing cycle involving select members of Consortium </li></ul></ul><ul><ul><li>Fixing bugs by committee vote </li></ul></ul>
    7. 7. Coeus <ul><li>Disadvantages: </li></ul><ul><ul><li>MIT software development team always on the move to develop product </li></ul></ul><ul><ul><li>Iterative development is not tested properly thus exposing upward compatibility bugs </li></ul></ul><ul><ul><li>Limited programming support in member universities </li></ul></ul><ul><ul><li>Testing infrastructure is different for each member university </li></ul></ul>
    8. 8. JUnit Testing Framework <ul><li>Personal responsibilities for Coeus: </li></ul><ul><ul><li>Hired by University of Medicine and Dentistry of New Jersey (UMDNJ) to support the Coeus eRA </li></ul></ul><ul><ul><li>Introduced business intelligence reporting capabilities non-existent in Coeus product </li></ul></ul><ul><ul><li>Introduced a testing infrastructure that would support university needs </li></ul></ul>
    9. 9. JUnit Testing Framework <ul><li>JUnit Testing Framework: </li></ul><ul><ul><li>Suggested by Dr. Fred Grossman and Dr. Joe Bergin in developing software development projects based on JUnit </li></ul></ul><ul><ul><li>JUnit Framework encompasses JUnit, Abbot, Cactus, HtmlUnit, and HttpUnit open source software geared for testing </li></ul></ul><ul><ul><li>Coeus Testing for UMDNJ involved: </li></ul></ul><ul><ul><ul><li>Address database table validation (Cactus) </li></ul></ul></ul><ul><ul><ul><li>Address web content validation (Cactus, HtmlUnit, HttpUnit) </li></ul></ul></ul><ul><ul><ul><li>Robot automation to test validity of GUI components (Abbot) </li></ul></ul></ul>
    10. 10. Community of Testers <ul><li>One Tester </li></ul><ul><ul><li>Presented the work at Coeus User Group Conference </li></ul></ul><ul><ul><li>1 university </li></ul></ul><ul><ul><ul><li>has strengths in a specific set of modules </li></ul></ul></ul><ul><ul><ul><li>should focus testing its specific set of modules </li></ul></ul></ul><ul><ul><ul><li>goal is to develop 1 test per day </li></ul></ul></ul><ul><ul><ul><li>200 tests for one year </li></ul></ul></ul>
    11. 11. Community of Testers <ul><li>Many Testers </li></ul><ul><ul><li>50 universities </li></ul></ul><ul><ul><ul><li>50 x 200 tests = 10,000 tests in one year </li></ul></ul></ul><ul><ul><li>Author proposed a development of a Coeus Testing Community – a “Community of Testers” </li></ul></ul><ul><ul><ul><li>Each university asynchronously develops its own tests </li></ul></ul></ul><ul><ul><ul><li>Contributes them back into the Consortium </li></ul></ul></ul><ul><ul><ul><li>Contributes to the development and maturity of product </li></ul></ul></ul><ul><ul><ul><li>The power of many compensates for the limitations of the one </li></ul></ul></ul>
    12. 12. Literature Review <ul><li>Community of Practice (CoP): </li></ul><ul><ul><li>suggests the concept of team infrastructure and multiple overlapping communities for sharing knowledge and standardizing practices (Kahkonen: “Agile Methods for Large Organizations”) </li></ul></ul><ul><ul><li>focuses on communities within a specific location using workshops and team building to foster collaboration </li></ul></ul><ul><ul><li>cannot easily be applied to a community of universities which have distance and timing factors that adversely affect collaboration </li></ul></ul>
    13. 13. Literature Review <ul><li>Open Source Community/Testing: </li></ul><ul><ul><li>PyPy is an open source project to develop software infrastructure within the European Union (During: “Trouble in Paradise: the Open Source Project PyPy. EU-Funding and Agile Practices”) </li></ul></ul><ul><ul><li>Koponen defined a QA process in the Open Source Model (Kopenen: “Evaluation Framework for Open Source Software Maintenance”) </li></ul></ul><ul><ul><li>Maki-Asiala defined a QA process of Open Source components in a corporate model (Maki-Asiala: “Quality Assurance of Open Source Components Integrator Point of View”) </li></ul></ul>
    14. 14. Relevance <ul><li>Work proposes the idea of a “Community of Testers” </li></ul><ul><li>Work involves an actual institution with actual stakeholders that will benefit substantially </li></ul><ul><li>Work proposes a solution based on limited funding issues that many universities experience </li></ul><ul><li>Work supports the marriage of information technology and research administration </li></ul>
    15. 15. Methodology <ul><li>Deployment on Four Linux Servers: Production, Backup, Development and Test </li></ul><ul><ul><li>Tomcat Application Server </li></ul></ul><ul><ul><li>Oracle 9G Database Server </li></ul></ul><ul><ul><li>Oracle 9G Client on Windows, MacOS, and Linux </li></ul></ul><ul><ul><li>Coeus Application </li></ul></ul>
    16. 16. Methodology <ul><li>Testing Methodology </li></ul><ul><li>Cactus, HtmlUnit, HttpUnit </li></ul><ul><ul><li>50 tests mostly database-specific ran against each server </li></ul></ul><ul><li>Abbot </li></ul><ul><ul><li>20 GUI tests on proposal and awards tracking, reporting capabilities </li></ul></ul>
    17. 17. Future Work <ul><li>The future of the Coeus Testing Community: </li></ul><ul><ul><li>MIT and author are in a discussion phase on how to introduce this framework into the Consortium </li></ul></ul><ul><ul><li>Expected implementation: March 2008 </li></ul></ul><ul><ul><li>Work on framework to handle multiple releases </li></ul></ul><ul><ul><li>Exploration of other open source methodologies to benefit this framework </li></ul></ul>
    18. 18. References <ul><li>[COE] “Coeus Consortium.” Web site. Massachusetts Institute of Technology. 2007. Link: </li></ul><ul><li>[DUR] B. During. “Trouble in Paradise: the Open Source Project PyPy, EU-Funding, and Agile Practices.” In Proceedings of AGILE 2006 Conference (AGILE’06), pp. 221-231 . July 2006. </li></ul><ul><li>[KAH] T. Kahkonen. “Agile Methods for Large Organizations – Building Communities of Practice.” In Proceedings of the Agile Development Conference (ADC 2004), pp. 2-11 . June 2004. </li></ul><ul><li>[KOP] T. Koponen. “Evaluation Framework for Open Source Software Maintenance.” In Proceedings on Software Engineering Advances (ICSEA’06), pp. 52 . October 2006. </li></ul><ul><li>[MAK] P. Maki-Asiala, M. Matinlassi. “Quality Assurance of Open Source Components: Integrator Point of View.” In Proceedings of the Thirtieth Annual International Computer Software and Applications Conference (COMPSAC’06), pp. 189-194 . September 2006. </li></ul>