Only Software matters

Experiences in software development

Archive for the ‘continuous integration’ Category

20 +2 Subjects Every Software Engineer Should Know … and the books you need

Posted by Patroklos Papapetrou on July 19, 2012


I recently read an extremely interesting and useful article about the 20 subjects that every software engineer should know or learn….
What is really cool is that it’s not restricted to products, languages but it describes generally accpepted technologies, methodologies and practices.
It applies both to  junior and exeperienced software engineers. The former have a guideline about the fields that need to focus whereas the latter have the chance to re-evaluate their knowledge.
What’s missing, IMHO, is to give the reader a clue about which are the best book(s) related to these subjects so in this post I give my advices on that. Of course the list of books is not complete and it’s just my opinion based on my experience.

Hope you find it useful as well!

1. Object oriented analysis & design

2. Software quality factors

3. Data structures & algorithms: Basic data structures like array, list, stack, tree, map, set etc. and useful algorithms are vital for software development. Their logical structure should be known.
6. Software processes and metrics
8. Operating systems basics
10. Network basics
13. Dependency management
15. ORM (Object relational mapping)
18. Internationalization (i18n)

Posted in agile, cdi, ci, continuous integration, java, quality, software, sonar, testing | 10 Comments »

Best Agile Practices Blog Articles during September 2011

Posted by Patroklos Papapetrou on October 3, 2011


For September I have chosen to present a personal collection of articles that address / discuss one or more agile practices. Estimation, CI, Continuous Delivery and much more. Enjoy!.

4 Values of the Innovative Team
What does it take to have team be successful in an innovation?  All teams operate with a set of values, usually implicitly.  In this post,Paul Boos discusses the 4 primary values that a innovative team will exhibit and according to him,  these values are what allow a team to be creative in constructing and implementing an innovation.
http://agilescout.com/4-values-of-the-innovative-team

Estimating a full backlog based on a sample of it
My favorite article for last month. See how easy it is to have a full backlog estimation just by estimating only a portion of the total user stories. Mike Cohn offered to all agile practicioners another excellent post.
http://blog.mountaingoatsoftware.com/estimating-a-full-backlog-based-on-a-sample

The value of stable teams
Forget about multi-tasking. Forget about multi-project assignments. Bring your team members together and make them last ( forever!!! )
http://www.allaboutagile.com/the-value-of-stable-teams

Agile is NOT a game of perfect
Agile isn’t about perfection; it’s about bringing value to your organization and to your customers in the most cost-effective, team-centric, transparent way.

http://blogs.versionone.com/agile_management/2011/09/27/agile-is-not-a-game-of-perfect

How does QA fit in?
Do you have a separated department of testers. How can they work smoothly in an agile team? Or even better… how can they be a part of that team?

http://agileconsortium.blogspot.com/2011/09/how-does-qa-fit-in.html


How to introduce a Test-Driven Mindset
Test Driven Development is considered to be one of the most difficult agile practices to adopt and that is because is primarly a mindset problem and not a technology or tools issue. This post, by Mike Caspar, presents an excellent approach on how you can introduce a TDD mindset in an agile team
http://www.agileadvice.com/2011/09/07/uncategorized/how-to-introduce-a-test-driven-mindset

Continuous Deployment is Continuous Business Improvement
Why it is extremely important to achieve continuous deployment. It’s not about technology… it’s about business improvement

http://blog.recursivity.com/post/9992942239/continuous-deployment-continuous-business-improvement

Continuous Delivery – Why you don’t really “get it”?
Are you sure you understand what CI is?

http://www.urbancode.com/blogs/anthillpro-blog/2011/09/07/continuous_integration_why_you_dont_really_get_it.html

Feel free to add any article you found interesting in the list

Posted in agile, continuous integration, quality, software, testing | 1 Comment »

UDIAS – The 5 levels of an ideal agile and automated testing strategy

Posted by Patroklos Papapetrou on July 24, 2011


Recently my team started working on a new project which is actually a re-developing of a legacy system in a new platform. We decided to move from a windows based application to a new web-based J2EE application. It is a project that has all the odds against failure. We know the domain, we know the new technology, the team is working together many years and there is only one restriction about it. We ought to use the same database schema since it may be used in conjunction with the old windows – client. Good news since we don’t have to redesign the database. Bad news since we have to stick on some bad database smells of the past. Anyway we have the chance to complete a project on time with no serious risks. It is also a very good opportunity to apply in practice the testing strategy we dreamed for all these years. A strategy that is fully automated, repeatable with a single key press and covers all aspects of the system. We decided to use Jenkins as our build system and in the following lines I briefly describe the testing strategy

Unit  Testing

Since it is a Java system we had to choose between the two famous unit test frameworks. JUnit and TestNG. For no particular reason (maybe because we are already experienced with it) we have chosen JUnit. All unit tests run after each commit with our first Jenkins job (let’s call it app-trunk). If coverage falls below a predefined threshold (i.e <75%) the the build automatically fails,team members are notified and last commiter(s) strive to fix the build.

Database Unit Testing / Database Integration Testing

You can name the next level of testing as you wish. I prefer to call it Database Integration Testing since we test how well is our system integrated with the database. Remember that we had to keep the database unchanged so we have a double challenge here. Test our code (EJB3 entities) against an existing / productive database with real data and test our code against a database that is automatically created with sample data. If am not mistaken the only available mature framework for database testing is DBUnit. It provides some flexibility about database testing but we had some more requirements so we created a layer over it to automate things like data generation, testing of entity objects manipulation etc. Maybe in another post we will describe this layer in details. For each entity we test functions like create, edit, find, delete and some schema-related issues, such as indexes, foreign keys and primary keys. Due to the fact that there are some tables with many columns we would like to sure that all mappings (columns and relations are correct). All kinds of these tests run through an automated build-job,that is being triggered whenever app-trunk succeeds. There are two matrix jobs in Jenkins that test our code against all supported database platforms with existing and sample data. Obviously, if something goes wrong, again all team members are notified and try to fix the problem.

Integration Testing

Our system runs on an application server so we need somehow to test its behavior and how well is integrated with some services and frameworks like JSF and CDI. Here comes Arquillian to make our life much easier (with JSFUnit extensions). The idea of writing tests just like unit tests is brilliant and since we don’t have to learn a new framework we can adopt it quickly enough, from the day – one of our project. Each class that uses services within the container should be tested at this level. Same rules with unit testing about coverage apply here as well and integration tests run after the success of all database integration test jobs. We have created once again a matrix build job in Jenkins that runs all integration tests against supported platforms and application servers.

Acceptance Testing

Probably the hardest job because this is the point where we have to test our system if it meets the end-user’s requirements. It is also the step that requires the strongest hardware since the software has to be deployed in a real environment and automatically be tested for the most critical scenarios and the most used application flows. There are plenty of tools, however we have chosen to use Selenium, due to the fact that has a quite stable integration with Jenkins CI and has a very powerful add on for Firefox browser. We try to cover in depth not all possible user screens but those that are the most . All acceptance tests run during our nightly build once a day and only if there is an existing commit since last run. Although it is very difficult to test our system in all different environments we try to run the tests in the most commonly used. Obviously acceptance testing does not end with the automated build job. It is QA team’s responsibility to perform a complete acceptance test of all scenarios, but we strongly believe that core functionality should be always tested automatically to catch serious defects before QA team.

Stress Testing

Our application stores a large amount of data and is accessed by many users so we have to ensure that its performance is acceptable by them and does not fall below some predefined thresholds. Without any automation it would be very hard to achieve this, so to conquer the last frontier of testing we have used Apache JMeter. Although JMeter has no tight integration with Jenkins we have created a different project (JAR) that includes all performance and stress tests, triggered also during our nightly build job. Stress testing is not our number one priority, however at the end of each iteration we evaluate the usefulness of our existing tests and we modify them accordingly if some serious requirements change has occurred during the last iteration.

The UDIAS (unit, database, integration, acceptance, stress) testing strategy is probably not a silver bullet, but it covers all the different layers and views of an application. The time needed to set running all the above build jobs is significantly large but the ROI of investment worth the effort. I don’t think that there is something more important in a system under development / maintenance than an automated testing plan.

Thanks for reading this post and feel free to rate it, post your comments or share it with others.

 

Posted in agile, ci, continuous integration, jenkins, software, testing | 4 Comments »

 
%d bloggers like this: