Basics understanding of Maven

1.  Archetype : Used to create Project with same pattern like Hibernate Project, Web project etc.

command : mvn archetype :generate

2. Compile Project  : Go to folder where POM is place

command : mvn compile

3. Compile and Run Test (Unit Test)

command : mvn test

4. How to compile just test resources

command : mvn test-compile

5. How to create jar file using maven

command : mvn package

6. What are POM files

POM Contains :

·         Information about project

·         Project description

·         Versioning

·         Dependencies

7. List objectives provided by Maven

·         Provide Quality Information

·         Transparent Migration to new features

·         Makes build process easy

·         Uniform building system

8. Maven’s Order of inheritance

·         Parent POM

·         Project POM

·         Settings

·         CLI Parameters

9. What are two main subdirectory folder of Maven

·         src

·         target

10. What is target directory used?

                House all output of build

11. What is Groupid

                Entity or organization responsible for producing the artifact

12. What is Artifact id

                Name of artifact

13. What is version

                Version number of artifact

Browser Automation Using Geb & Spcok

Web Browser Automation Using Geb & Spock

Abstract

Geb is a fairly new web browser automation tool that is very useful in certain web application development projects. It is a JQuery-like content selector and a WebDriver-like automation tool wrapped into one unique language. Using Geb requires a few moving parts but if you require very extensive, in depth web application testing it can be extremely advantageous. It can also be very useful in slightly smaller projects as well if you find yourself constantly clicking through the same pages and scenarios to test certain web application functions. Geb is currently not even at version 1.0 but it is increasing in popularity due to its usefulness. In the narrative that follows you will learn when Geb should be used, what Geb is, what it looks like, and see some examples of Geb code fragments.

 

Automating the Browser

            The reasons may seem slightly obvious why having a tool to automate a web browser would be beneficial but all web application projects are not created equal. There are situations where using Geb would save a large amount of time (in the case of software engineering in industry it would save a large amount of money too) and there are cases where using Geb would actually cost more than it would be worth. What are these scenarios? To find out what these scenarios are one needs to know advantages and disadvantages of integrating a browser automation tool into a project.

Advantages - When to use Geb

          The main advantage of having a browser automation tool is to eliminate the need for tedious manual testing. You would want to use a browser automation tool on a large project with many test cases. Quality Assurance teams on big projects like this will have thousands of test cases to go through before a project is ready for deployment. With modern web applications they can be very complex and just having j-unit tests running in your back end code is not enough to catch errors. Once the back end code is integrated with the front end interface there can be many errors that arise when all the parts actually come together. With complex applications like this it forces the quality assurance teams to have to test a lot of the front end functionality by hand. This becomes very difficult the more complex the application actually is.

            Let’s take an industry standard e-commerce application as an example. There are many parts. First there is back end java code that handles the functionality of the application. Within this code there are multiple layers needed to make the application robust and effective. This depends on the design pattern that is used however let just use the MVC pattern as an example. MVC stands for model, view, and controller. When using this design pattern one must define a model, view, and controller for each feature that supports functionality on the user interface. Then once the model, view, and controller pieces all work together to support the new feature, the component that uses the feature must actually be added onto the user interface. This is done using some kind of markup language or template language in a web application. Once in use some components will even need to talk to a database to get the required information they need to function; for example, if a customer scans a promotional code the application would need to access the database to receive that code, put it in the right text field and apply the correct discount to the current total. To make a long story short this is a lot of moving parts. Anyone who has studied just a little bit of computer science can see that there is a lot of potential for bugs in code of this complexity.

With complex code comes a large amount of required testing. Using Geb to automate certain tests can really save time. A scenario that would be advantageous to use automation on is a one that involves navigation through many pages and a large amount of data entry. Say your application requires a user to enter a large amount of personal information before they can move on to the next page of an application and you need to test one small feature three pages deeper into the application. How would Geb help with this?

 Using Geb you can write a test suite that will access all of the text fields and drop down boxes and enter in all of the information very quickly. You only have to define the information you want in this boxes once in the Geb code. From then on they act like constants and you can write the program to insert those constants in whatever field you see fit. Once you enter in all the necessary information you can then advance to the next page and so on and so forth until you get to the feature you actually want to test. The difference in speed is exponential. To do the same process by hand it would take at least five minutes while Geb can do it in seconds. This is the main advantage using Geb. Quality assurance teams could eliminate a lot of tedious testing time and focus their time on testing the actual functionality instead of mainly performing data entry.

Another main advantage is that it is not too hard to learn. The language is very readable and the constructs do what they say they are going to do. For example the keyword “to” is supposed to be followed by the name (if you have defined the page in your code) or the url of the page you want to go to (such as “GoogleHomePage”) so a line of code using the “to” keyword would read “to GoogleHomePage.” [1] As you can see it is very readable and simple to understand. Most of the constructs in Geb read similar to this making the language something that programmers can easily pick up. I will go more into actual features of Geb code later on.

Disadvantages – When to not use Geb

          Geb’s usefulness takes a hit on smaller projects. When your web application does not have layers of pages and many forms that require data entry you may find Geb actually costs you more time than it saves. Although you could still set up Geb to work with a smaller project it may take more time installing it, learning it, and coding a Geb test for every new piece of functionality that is added when a quick manual test would suffice. As you can see it really depends on the project at hand. There is no cut and dried project size threshold, but since Geb is fairly new and unknown it can be a bigger risk to integrate it into a small project. If Geb doesn’t save a lot of time it is really not worth taking the time to become familiar with because that time would increase the cost on the project.

            Another disadvantage of using Geb is it is very picky about what environment your website application uses. Geb needs to be properly integrated into a specific environment to be able to work. If you are already using some of these things in your project then Geb can be installed in a few minutes, otherwise it could be very tough. Geb interacts with specific web development environments like Grails, Maven, and Gradle. If your project does not use at least one of these in the first place it is probably not a good fit for Geb. It seems it would take a decent amount of work to switch over the environment to one of the ones I previously spoke about; the cost would be too great to even be worth trying to use Geb. However if your project uses these environments than Geb would probably be a great fit to use in your web application’s testing process.

            The last main disadvantage of Geb is the guaranteed learning curve. Since Geb is so new and unfamiliar to many programmers there is an almost certainty that newly integrating it into your project is going to require extra time for developers to learn. The up side is that Geb is fairly easy to learn once you commit to learning it but it is still going to take time away from other tasks to learn just like any other new language. Sometimes project teams are on such a tight time crunch that they cannot afford a few days to learn and integrate a new language into their project. However it would be worth those few days if you are spending more time on testing than Geb could save you in the end. Usage all comes down to software engineering management decisions and those are made differently on a project to project basis.

What actually is Geb?

          As I have previously described Geb is a browser automation solution. This means Geb can completely take control of your web browser and programmatically perform tasks that you would otherwise have to perform manually. As you can see this would be extremely useful for testing web applications. Now that I have previously described the advantages and disadvantages I will get more into the bare-bones of Geb. Geb’s features are based on combining features from WebDriver, JQuery, and the Groovy programming language.

WebDriver

          WebDriver is the main driving force behind Geb. The WebDriver integration is what actually handles the browser automation. WebDriver has the capability to modify document object model content on a web page [2]. Document Object Model (DOM) content is the specific interface components on a website. These are things like text fields, buttons…etc. This means that WebDriver can do things like insert text into a text field, since a text field is a DOM component.

WebDriver can also control the behavior of a web browser. You may be thinking why would anyone use Geb if WebDriver can do its own version of browser automation and DOM modification? The main reason is the readability and simplicity. As you will soon see Geb is a lot more readable and easy to learn than just using WebDriver itself. Geb takes its main functionality from WebDriver but combines it with other tools that make it simpler. Below is some java code that supports using WebDriver to perform a Google search (see Figure 1). Although it is not extremely complicated writing a WebDriver test it is still more work than writing a Geb test because Geb uses the language of Groovy which saves a lot of key strokes and is easier to understand

A Very Groovy Language

 Geb speaks in the language of Groovy. Groovy is a dynamic programming language for the java virtual machine. Although some consider Java to be a dynamic language Groovy behaves like traditional dynamic languages that programmers are used to like Ruby, Python, and Smalltalk [4]. Basically Groovy builds upon the strong features of Java but adds features that one would expect in dynamic languages like Ruby. One of the biggest advantages Groovy has is its readability and low learning curve. It also integrates easily with virtually every Java library [4]. Another advantage is that it simplifies testing because of its support for mocking and unit testing. This is why Geb uses groovy as the language of choice. See Figure 2 below for some basic groovy code.

As you can see above groovy is very similar to Ruby. Geb tests are written using this language and this allows for use of some unique testing keywords that really make testing simple and readable. But before I actually go into how to write a Geb test it is important to know the final piece Geb uses in its implementation: JQuery.

JQuery

JQuery in a nutshell is basically a content selector. Its purpose in Geb is to improve on the DOM content selection model of WebDriver to make Geb a more powerful browser automation tool. When automating a web browser a very important step is being able to quickly and easily locate content on the page that the automation tool will either use or modify. JQuery’s purpose is to provide that powerful selection feature. JQuery is a JavaScript library that can actually go into the html code and modify or find desired components. It is also able to handle events and provide its support for all the major browsers (IE, Firefox, Safari, Chrome…etc) [5]. Using JQuery with Geb makes the browser automation faster. Some of its language even makes its way into the syntax of Geb. This is why it is important to know.

Consult figure three below to see a basic use of JQuery. In this example JQuery is being used to prevent a link embedded in the html code of a website from working. Lines 11 through 16 on Figure 3 is actual JQuery code embedded into the html code. What this code does is overwrite the click event on the link defined in line 8 preventing it from taking the user to jquery.com.  Geb uses JQuery to make modifications to web pages in a similar matter.  

Figure 3: JQuery Example

   

Knowing the pieces of Geb are important before getting into using it because it makes it even easier to learn when you start realizing what pieces are being used where. WebDriver, Groovy, and JQuery all play an integral part in making Geb a powerful browser automation tool. Now that you have a background in the main pieces of Geb we can get into some examples and explanations of how Geb works.

Geb Examples

Geb can be combined with many testing frameworks all outlined in The Book of Geb and it can be found on the Geb website www.gebish.org. First one needs to see what Geb looks like by itself (without importing any frameworks.). After knowing what Geb looks like by itself one can see what a typical test looks like using the Spock framework. The Spock framework is included in the Geb package so a simple “import geb.spock.GebSpec” in your code should take care of the entire configuration. It is not something that requires a large amount of explaining but I will point out when the Spock framework is being used in following examples. It is recommended to use this framework when using Geb because you can write the most “clear, concise, and easy to understand test specifications with little effort” [1].

Let’s now dive into to a simple Geb example. Recall the WebDriver Google search example from Figure 1. Next you will see a Google search example in Geb and it will be compared with WebDriver. The following Geb code is an inline scripting style; it doesn’t use any predefined packages or frameworks, it just uses basic Geb. In the following example the computer is going to go to Google, enter Wikipedia in the search field, and eventually click the link to Wikipedia and go to the page.

Notice how all you need to do to go to the webpage is use the keyword “go” (line 4) followed by the url. In the case of WebDriver implementation you need to do a “driver.get()” with the url as the parameter. Geb’s version of this implementation is a lot simpler and easier to remember. You do not have to look through the methods of the driver to figure out which one goes to a url; you just need to remember the one word: “go.” Also notice how you can do an “assert” statement without defining any testing frameworks. This makes it very easy to check if you actually got to the right page. To do the same operation in WebDriver you would need to do a “driver.getTitle” and compare that string using the java “.equals” method. Geb simplifies WebDriver but is still able to keep the powerful functionality.

A third and final note about the above example is the lines that use the “$”. This is where JQuery comes in. If you recall the example from figure three this is how JQuery accesses content on the webpage. Geb uses that notation as well. It is able to find “q” which is the variable name for the text field on the Google home page and enter text into it all in one line. In our pure WebDriver example from figure one this process takes two lines to perform. You need to find the element then use “sendKeys” to programmatically type in what you want. As you can see Geb requires less coding than just using WebDriver straight up.

Page Object Model

Non-inline Geb programs are built on the page object model. Using this model is the preferred way to use Geb. If you need to write a quick test you can certainly use the inline style as shown in Figure 4 but using the Page Object Model makes your tests more readable and can save you time in future phases of your project. The page object model in a nutshell is based on defining page objects in the test code and reusing them whenever you need to refer to that page object [7]. If this model was used on the example in Figure 4 the programmer would not have to use the JQuery notation in the script; the programmer could simply call the pre-defined page object.

To do this you would define a page object in your Geb code. Inside of that specific page object class you would define all of the content on that page so you could easily refer to it later without having to use JQuery and look up the variable names of the desired content on the page you are working with. To do this you use the JQuery finder character ($) but store the result in a class variable that you can call when you are doing work with that specific page. Let’s look at what a typical page class looks like (see Figure 5 below).

Figure 5, above, is how you would represent a login page using the page object model. It is very simple: name the page, specify its url and content, define the content by using the JQuery notation to access the object on the web page but name it something meaningful so your code is very readable. Once you define your page you can refer to it as, for example, LoginPage anywhere in your code. Notice how the last line of actual code on Figure 5 actually refers to another page (AdminPage) since it needs to interact with that page as well. If you did not have AdminPage defined you would need to put in the url or use JQuery to find it. Geb’s implementation of the page object model is really what defines it and makes it more powerful than other browser automation tools. Let’s dive in a little further to see what a test script using the page object model looks like.

Testing

Seeing an example of a test using the page object model really brings everything together. WebDriver functionality is used in automation, JQuery is used in defining the content in page object model classes, Groovy provides the language support to code the page objects, and Spock is the testing framework we are going to import. Below is a test specification for the login page we defined above in Figure 5.

Figure 6: Geb Test Using Spock Framework and Page Object Model

The first thing to do when writing a test spec for a page is to use the def keyword to define the name of the test. In this case we are calling it “login to admin section.” You want to name tests very specifically to increase maintainability and readability. First what the test is going to do is try to go to the login page. If for some reason it cannot go there the test will be reported as failed due to the “given:” keyword. This will only go on if the browser is at the login page after the instruction is completed. The next instruction is going to add text to the user name and password text fields using the “with” method which will modify the state of the content on the page to whatever is specified (in this case we are adding text for username and password). Right after the state of the page is modified to include the information in the username and password fields, the test will then click the login button programmatically. Once this action is completed then it tests to see if the browser is “at” the admin page. Since the “at” function returns a Boolean, it will decide whether or not the test passed due to the state of the browser. If it is at the admin page, then everything is good and the test will be shown as passing, otherwise it will be reported as failed.

Concluding Statements

As you can see from the explanation of the test (figure 6) in the previous section, Geb code is very readable. This is why Geb is so powerful; it is easy to write, easy to learn, easy to modify, and it works! There are a few moving parts to get it going, but if it is right for whatever project you may be doing it can save a large amount of time and provide much more accurate test coverage. Using the page object model efficiently makes for simple test specifications that can cover a large amount of test cases. Defining all of the pages in your web application using the page object model can really make it easy to go from page to page in testing since all you have to say is something along the lines of “to LoginPage.” Also, using the browser automation techniques can save a large amount of time because you don’t have to keep doing data entry into text fields every time you want something to be tested. Type the information once in a test spec and then you can run it as many times as you need. If you decide that Geb is right for your project, more information on how to configure Geb in a project and further documentation can be found at www.gebish.org. I have had some experience using Geb and would highly recommend using it for in depth web application testing.

         

                                         Bibliography

[1] Geb - very groovy browser automation… web testing, screen scraping and more. (n.d.). Retrieved from http://www.gebish.org

[2] Getting started with webdriver. (n.d.). Retrieved from http://code.google.com/p/selenium/wiki/GettingStarted

[3] Gradle documentation. (n.d.). Retrieved from http://www.gradle.org/documentation

[4] Groovy - a dynamic language for the java platform. (n.d.). Retrieved from http://groovy.codehaus.org/

[5] How jquery works. (n.d.). Retrieved from http://learn.jquery.com/about-jquery/how-jquery-works/

[6] Ledbrook, P. (2010, Aug 28). The future of functional web testing?. Retrieved from http://blog.springsource.org/2010/08/28/the-future-of-functional-web-testing/

[7] Page objects. (n.d.). Retrieved from http://code.google.com/p/selenium/wiki/PageObjects

[8] Test automation for web applications. (2012, Dec 20). Retrieved from http://seleniumhq.org/docs/01_introducing_selenium.jsp

Agile process

1.       Agile Definition

When developing software using the Agile methodology:

1. The customer creates stories that describe the functionality of the software.
1. These stories are small units of functionality taking about a week or two to code and test.
2. Programmers provide estimates for the stories
3. The customer decides, based on value and cost, which stories to do first.
4. Development is done iteratively and incrementally
1. Each two weeks, the programming team delivers working stories to the customer
2. Then the customer chooses another two weeks worth of work
3. The system grows in functionality, piece by piece, steered by the customer. This means that progress is measured and tracked based on the observable behavior of the system, rather than judging design artifacts such as SDS, TSD etc.
   
   

Agile/XP relies on evolutionary design techniques to keep the software design good while adding new functionality. Given how fluid software requirements can be, evolutionary design is a critical practice for any software project. The trouble is that traditional development practices do not provide good techniques for safely evolving designs as requirements mutate.

2        Roles in Process

• Coach / Tracker – This role is truly a project manager.  This person is responsible for the following:
• Facilitating planning game
• Managing the releases
• Overall progress of the project
• What the individual team members are working on
• Giving project status to those within the project and outside the project
• Keeping the project tracking tool up to date
• Facilitating the daily standup
• Business representative
• Involvement in planning game
• Prioritize business requirements
• Be available on daily basis to answer questions
• Constantly reviewing the project, giving feedback at the earliest possible time
• Analyst
• Involvement in planning game
• Analysis for project / iteration / user stories / tasks
• Entering / maintaining user stories in Agile tool
• Work with Tester in review and execution of SIT cases
• Developer
• Following the agile / test driven processes
• development
• Involvement in planning game
• Tester (Q/A)
• Involvement in planning game
• Writing SIT cases
• Overseeing execution of SIT cases
• Managing testing effort across SIT / SAT / UAT
• Provide SIT status
• Track implementation steps for project
• Establish / maintain traceability between user stories and SIT cases
• UAT
• Involvement in planning game
• Writing UAT cases
• Execution of UAT cases

3        Project Process

3.1       Pre-Project

Before the project starts all the necessary resources need to be allocated and dedicated to the project.  Starting projects before the dedicated resources are all available will lead to problems in the long run.   The following list outlines what is necessary to get a project started:

• Resources
• Fully dedicated resources for the following roles:
• Coach / Tracker
• Analyst
• Developer
• SIT
• Resources that aren’t fully dedicated
• Business Representatives
• Architect
• UAT
• Optional resources
• Database Engineer
• We are currently using the following formula for the number of Analyst / Developer / Tester – 1 Analyst / 4 Developers / 1.5 Testers.  This is not set in stone and will change from project to project.
• Project room or area – the project team needs to be working together in a dedicated space where the team members will spend the majority of their time.  There are times when individual members need to leave the room/area, but this should be kept to minimum.
• Project Planning game

3.2       Project Planning Game

There should be planning game meetings that are for the overall project, these should discuss the overall requirements of the project.  The initial planning game’s purpose is to lay out the high level requirements for the project and to give an initial priority to the requirements.  These priorities will aid in laying out what will be done in each of the releases, and then each of the iterations that lead to a release.

The team needs to consider what they want to get out of each release to make sure that the iterations leading up to the releases are focused on the appropriate work.  While the release may be a significant driver towards what is being done in the iterations, the overall project must also be considered and the development should be aimed at finishing the work for the overall project as well as releasing logical groups of functionality during the releases.

This meeting should be attended by the Coach / Tracker, Tester, Analyst and a developer should be in these meetings.

3.3       Assumptions

• Most of the development will be done using Pair Programming.
• The entire process is team driven.  The Coach / Tracker needs to be moving the project
• Business is truly part of the team, there is a need to have

4        Working Releases

Planning for the release starts with the project planning game.  This is where the initial functionality will be initially laid out to hit individual releases.  Each iteration planning game should address how the release will be affected as well as what is being done for the current iteration.

• Project Planning Game
• Iterations
• Planning game
• SIT case creation / modification and execution
• SIT – This will be a 1 week period dedicated to test execution following the end of the last scheduled iteration and prior to SAT start.  All functional coding and SIT cases should be completed when SIT starts.  This is also the point when user requirements will no longer be accepted.
• SAT/UAT – This will be the 3 week period prior to the release date.  This is controlled outside of the agile process. 
• Post Release – This usually lasts for the 2 weeks following the release, if any problems arise the project team would need to be involved to resolve the issues.

The entire Technology team (Analyst, Developers, Testers) should be dedicated to the SIT phase to fix defects, help the testers execute SIT cases and participate in exploratory testing.  At least one pair of developers and one tester need to be assigned to the SAT phase of the project. 

The next iteration should be starting as the current release starts SAT.   This iteration will be working towards the next release, but the team needs to understand that the current release is the main priority.  It is important to set expectations that the team will be moving forward with the next iteration, but any or all of the resources on the new iteration may be pulled into the SAT phase or post-release if the need arises.

5        Working within Iterations

5.1       Planning Game

o    Coach / Tracker needs to determine the ideal hours that are available for the iteration.

§  First step is to determine the total hours available to the iteration, by putting everyone in at 40 hours per week, and then subtracting the vacation time and training time.

§  Once the available time is determined the ideal hours available can be calculated by multiplying the velocity by the actual.  The velocity is something that may change over time, currently we are using 75%.

§  An alternative is to just take the number of ideal hours that were completed in the last iteration or average of last iterations and use that as your benchmark.

§  This is purely an estimate to give the Tracker an idea of how many hours to plan for in the coming iteration, it is a meaningless number outside of this purpose.

o    Discuss stories as a team

§  Team should include the Technology Team (Analysts, Developers, Testers & Coach) along with the business partners

§  It is crucial to work out as much information as possible about the user stories so that the estimating that will come after is as accurate as it can be.

o    Have dedicated estimating as a Technology team

§  The entire technology team needs to be in this meeting and it should be outside of the normal work area to limit distractions.

§  Since everyone has heard the requirements from the users it should be a discussion about how to break the story into tasks and how long each task should take

§  Each story should have an estimate for how long it will take in ideal hours to Analyze, Code and Test.

·         Ideal Hours are defined by working in a vacuum, no distractions nothing else going on, just being able to work without outside issues.

·         These estimates should be on how many hours it will take 2 developers together to do it.  If for example it should take 4 hours for the 2 developers doing pair programming then the estimate for development would be 8 hours.

·         User stories should not be more than an average of a few days worth of work.  If there are a total of 2 weeks worth of work or more the story needs to be broken down to a more manageable size.

·         Tasks should have an average size of no more than one day.  If an individual task has a total of 2 days or more then the task needs to be broken down to a more manageable size.

§  Consider testability of stories.  If several stories are required to be completed for a function to be SIT tested, group these stories together and provide a technology priority within the function. The business can prioritize the function within an iteration but the stories identified must be completed as a group.

o    Once the estimates are complete the coach / tracker needs to re-prioritize the user stories with the business

§  The business’ priorities may change once the estimates have been completed.  A story may be a high priority if it takes 10 hours, but not if it takes 40 hours.

§  If there are user stories that have not been estimated yet and the business wants to evaluate them the coach would then ask the team to estimate only the stories that the business realistically thinks will end up in the current iteration.  If these stories were not discussed in a previous planning game, a short discussion on the story should take place prior to estimation between the Technology team and the business partners

5.2       Stand Up Meeting

There needs to be daily standup meetings within any agile project.  The stand up meetings should be at a set time of day every day, if it is possible; keep it consistent.  The meeting should be facilitated by the Coach / Mentor.  If the coach is not available there should be a known stand-in to take over facilitating the conversation.  The meeting should be limited to 15 minutes; people are encouraged to stand up during the meeting to keep it short.

The main purpose of the stand-up is to get everyone on the project up to date with what everyone else is doing.  Each person on the team will talk about what they have worked on since the last stand-up and what they plan on working before the next meeting.  This is a good opportunity for people to ask questions and to make helpful suggestions.

5.3       Unit Acceptance Tests

The SIT and Analyst resources assigned to the project are responsible for gathering and documenting the Unit acceptance tests (user cases) with the business partner.  These tests should be segregated by user story, allowing them to be applied when the individual user stories have been completed.  The Unit Acceptance Tests will be handed off to the developers for automation and execution.  Once the Unit Acceptance Test has passed, the code may be checked in

5.4       Development

o    Update user stories through tool at the end of the day or whenever an user story is completed

§  Accuracy of time is extremely important

§  Time needs to be entered for development, analysis and test

o    Pairing

• This follows the pair programming laid out in the XP book
• There should be goal of keeping pairing around 75% of the time
• Pairing should be promiscuous, in that our pairs are not set. 
• Every day pairs should evaluate if they will stay together or switch round
• If a pair is still working on an user story the only rule is that one of the members must remain on the user story, two new developers cannot start working on an existing story.
• Breaking up a pair during a user story should not be discouraged; this allows more developers to be involved and the knowledge of how to work on that area will be spread.   Also there will be another set of eyes on the code that may catch problems or issues with the process being followed.

o    Follow standards / process

o    How do we test earlier in the iteration?

o    Defects are assigned through inform throughout the project

5.5       Feedback from Business Representatives

Feedback from the business representatives needs to be gathered continuously.  Whenever an user story is completed the business needs to give their feedback on how the works meets their expectations.  This feedback should be gathered after the development has gone through the user acceptance tests. Along with the business, the tester should also be involved.

Done properly the work will be in a constant state of approval from the business users on functionality and form.  There will be need for actual testing by the user groups but the functionality coded should never be in question.  Beyond

5.6       Ongoing UAT

UAT testing is outside of the normal business representatives giving their approval of the product. 

5.7       Ongoing SIT

o    SIT Process

§  Participate in Planning games and estimation sessions for the iteration

§  During the first 2 weeks of the first iteration of a project

• Gather environment requirements and forward to environment services
• Identify Test Deliverables, provide estimates for test execution of deliverables and assign test case creation resources for all functions identified in the project planning game. 
• Begin writing SIT cases for functions discussed in the 1^st iteration Planning game

§  By week 3 of the iteration you should receive your first build.  If the SIT environment is not available, begin execution in the dev environment.  Testing should be happening in week 3 & 4 of the current iteration and week 1 & 2 of the next iteration.

§  During week 1&2 of iteration 2, you should be splitting your time between execution of tests from iteration 1 and SIT case creation for iteration 2.

§  Throughout the project, the SIT lead is responsible for tracking all setps that will be required to implement the project into production including, builds, schema, scripts, standalone deployments, etc.  Along with this, a list of dependencies on other projects and projects that are dependent on your project should be kept.

§  There is a 2 week SIT window following the end of the last iteration for the project to execute all remaining SIT cases, perform defect fixes, complete regression and perform exploratory testing.  All members of the Technology team will be participating.   Prior to this SIT window, all SIT cases should be documented in Quality Center and have been reviewed by the analyst and developer assigned to the function.

§  Review the functionality being planned for release with the SAT and UAT teams.  Coordinate production validation with UAT and provide any further assistance as needed.

§  Regression will also be required in the SAT environment if code merges or new builds are delivered for any component of the integrated environment that Portal uses.

§   

5.8       Weekly review meetings

The weekly review meeting is meant to insure that all teams are going through the test driven development process and agile process during the iteration.  This meeting needs to take place on Fridays after lunch.  A manager needs to facilitate going through the user stories that were completed this week.  It is imperative to make sure that the developers have stuck to the test driven model that is laid out in the TDD document.  If  a pair hasn’t followed the model and are missing test cases or there is another lapse in the process then they need to get this fixed by the stand up on Monday morning.

5.9       Wrap-up / review iteration meeting

This is basically a post mortem on the iteration.  This can cover agile, test driven or actual project issues and discussions.

6        Project Management

6.1       Project Management Tool

6.2       Weekly Status Reports

Status reports should be done at the beginning of every week, after the hours for the previous week have been updated.  The status report should contain the following information:

• Summary of the week
• Accomplishments
• Detail of any issues
• Plans for upcoming week
• What is currently known to be coming up
• Any milestones or issues that are about to happen
• User Stories
• All the user stories that are being considered for this iteration should be shown on the report
• There should be designation if the user story will be considered in the iteration or if it will be done if there is time
• The date that the user story was completed
• Resource Utilization
• This is based on the number of hours that were entered into the project management tool
• SIT Progress
• Functional Areas planned to be tested, estimate of effort for execution, assignments for test case writing and execution, planned and actual dates for cases and execution and defect statistics
• Issues
• A detailed list of the issues that are currently open including:
• Date opened
• Issue Description
• Owner of Issue
• Estimated date fixed
• Closed date
• The Issue should be listed on the status report until it is fixed and the fact that it is closed shows on one status report

 

7        Process Definition

The purpose of this section is to define a set of ideal practices for an agile software development project:

7.1       Agile Techniques

Agile is a collection of best practices

Customer Team Member – Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product.

Planning Game - XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimating the feature costs. Customers select features and package the development of those features into small iterations (typically 2 weeks). Iterations are combined into meaningful end user releases.

User Story – A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration.

Small Releases – Programmers build the system in small releases defined. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.

Unit Acceptance Testing – The SIT and analyst resources writes unit acceptance tests with the business partner. The tests demonstrate that the story is complete. The programmers automate and execute unit acceptance tests prior to checking in their code.

Open Workspace – To facilitate communications the team works in an open workspace with all the people and equipment easily accessible.

Test Driven Design – Programmers write software in very small verifiable steps. First, write a small test. Then we write enough code to satisfy the test. Then another test is written, and so on. – See Test Driven Development Document

Testing is conducted as follows:

• Using Test Driven development
• Each module developed should be testable and tests written for it
• Developer writes unit tests from within an automated unit testing framework (JUnit)
• Testing framework provides test coverage information. Coverage targets are established. Each module’s tests must at least reach the target before being checked in.

Metaphor – The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, making the software communicate to the programmers.

Simple Design – The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don’t build frameworks and infrastructure for the features that might be coming.

Refactoring – As programmers add new features to the project, the design may start to get messy. If this continues, the design will deteriorate. Refactoring is the process of keeping the design clean incrementally. Performed:

• During (Test Driven) development
• During bug fixes
• When the developer recognizes a code smell(Appendix A)

Continuous Integration – Programmers integrate and test the software many times a day. Big code branches and merges are avoided by provision of the following:

• The project should have an automated build, an automated deployment and automated testing
• A new build and test should be performed on a build server periodically
• The results should be reported to every team member and it should be an established team practice to immediately fix the build
• A working build is everyone's top priority

Collective Ownership – The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes.

Coding Standards – The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style.

Pair Programming – Two programmers collaborate to solve one problem. Programming is not a spectator sport.

Sustainable Pace –The team needs to stay fresh to effectively produce software. One way to make sure the team makes many mistakes is to have them work a lot of overtime

The following practices should also be considered:

Source Control:

• All code, non-code documentation, build scripts, database schema, data scripts, and tests should be stored in Clearcase
• Code should not be checked into the build until it compiles, has tests and is passing its tests with the prerequisite coverage.

Work-In-Progress:

• A working version of the latest iteration should always be available for customer feedback
• Customers can quickly identify deviation from requirements
• Shortening this feedback loop decreases the cost of change

Feedback:

• There should be a defined mechanism for project team members, including the customer, to provide feedback on the projects processes
• Hold a meeting at the end of each iteration to update/refine the process

 

A.1 Agile Checklist

Practice 1 - Refactoring:

• During (Test Driven) development
• During bug fixes
• When the developer recognizes a code smell

Practice 2 - Testing:

• Using Test Driven development
• Each module developed should be testable and tests written for it
• Developer writes unit tests from within an automated unit testing framework (JUnit)
• Testing framework provides test coverage information. Coverage targets are established. Each module’s tests must at least reach the target before being checked in.

Practice 3 – Automated Build and Deployment:

• The project should have an automated build, an automated deployment and automated testing

Practice 4 – Continuous Integration:

• A new build and test should be performed on a build server periodically
• The results should be reported to every team member and it should be an established team practice to immediately fix the build
• A working build is everyone's top priority
• Depends on Practice 3 above

Practice 5 – Source Control:

• All code, non-code documentation, build scripts, database schema, data scripts, and tests should be stored in Clearcase
• Code should not be checked into the build until it compiles, has tests and is passing its tests with the prerequisite coverage.

Practice 6 – Test Tracking:

• There should be a defined technique for recording and prioritizing development tasks and bugs
• The system should make it possible to assign responsibility for tasks to individuals.
• If tasks are tracked against estimates then the estimate should be performed by the person who will do the task

Practice 7 – Self Documenting Code:

• Code comments should be subject to the same quality requirements as the code itself

Practice 8 – Work-In-Progress:

• A working version of the latest iteration should always be available for customer feedback
• Customers can quickly identify deviation from requirements
• Shortening this feedback loop decreases the cost of change

Practice 9 – Feedback:

• There should be a defined mechanism for project team members, including the customer, to provide feedback on the projects processes
• Hold a meeting at the end of each iteration to update/refine the process