I suspect many of you have been impacted by CVE-2014-6271 (aka "shellshock" bash vulnerability.) We had our share of updates to do for various *.jenkins-ci.org servers.
Java application servers in general (including one that ships in Jenkins) do not fork off processes like Apache does to serve requests, so the kind of CGI attacks you see on Apache does not apply. We are currently unaware of any vulnerabilities in Jenkins related to CVE-2014-6271, and no plan to issue a patch for that.
That said, we did come up with one possible way attackers can exploit vulnerable bash through Jenkins, that you might want to be aware of.
When a build is parameterized, parameters are passed to the processes Jenkins launch as environment variables. So if you have a shell step (which uses bash by default), and if Eve only has a BUILD permission but not CONFIGURE permission, then Eve can exploit this vulnerability by carefully crafting parameter values, and have the bash runs arbitrary processes on the slave that run the build.
In most such scenarios, Eve would have to be an authenticated user on Jenkins. Jenkins also leaves the record of who triggered what build with what parameters, so there's an audit trail. But if your Jenkins fits this description, hopefully this serves as one more reason to update your bash.
Finally, to get notified of future security advisories from Jenkins, see this Wiki page.
With version 3.0 of the C / C++ plugin in August, 2014, support of the Objective-C language arrived.
Support of Objective-C in SonarQube was heavily awaited by the community, and has been in our dreams and plans for more than one year. You might wonder – why did it take us so long? And why now, when Apple has announced Swift? Why as a part of the existing plugin? I’ll try to shed light on those questions.
A year ago, there were only two developers in SonarSource’s language team, Dinesh Bolkensteyn and me. We’re both heavy hitters, but with more than a dozen language plugins, we weren’t able to give most of them, including C / C++, as much time as we wanted. Also we had technological troubles with analysis of C / C++. As you may know, source code in C / C++ is hard to parse, because… well, it’s a long story, which deserves a separate blog entry, so just take my word for it, it’s hard. And we didn’t want to provide a quick-win solution by locking ourselves and our users in to third-party tools, which wouldn’t play well in the long-term for the same reasons that third-party tools were a problem in other languages.
Today all that has changed. There are now seven developers on the language team (and room for more), with two dedicated to C / C++. We’ve spent the year not only on the growth of the team, but also on massive improvements to the entire C / C++ technology stack, while preserving its ease of use. At the same time, we’ve delivered eight new releases, with valuable new rules in each release. Since March, we’ve released about once a month, and plan to keep it up.
With solid new technical foundations in place, we were able to dream again about new horizons. One of them was Objective-C. It’s a strict superset of C in terms of syntax, so the work we had done improving the plugin also prepared us to cover Objective-C. Of course, with the announcement of Swift, actually covering Objective-C may not make sense to some, but there’s a lot of Objective-C code already out there, and as history has shown, old programming languages never die.
That’s why we decided to extend the existing plugin to cover Objective-C, and rebrand the plugin “C / C++ / Objective-C”, which is exactly what you see in SonarQube Update Center. Still, to better target the needs of the audiences we decided to have two separated licences: one for C / C++ and one for Objective-C.
And of course this means that out of the box, you get more than 100 Objective-C rules starting straight from the first version, as well as a build-wrapper to simplify analysis configuration. However, during implementation we also realized how unlike C Objective-C is, and for that reason we plan to add new rules targeting specifically Objective-C in the upcoming releases.
So don’t wait any longer, and put your software to the quality analysis!
There'll be several talks that touch Jenkins. The first is from me and Jesse called Next Step in Automation: Elastic Build Environment [CON3387] Monday 12:30pm.
Then later Tuesday, there's Building a Continuous Delivery Pipeline with Gradle and Jenkins [CON11237] from Benjamin Muschko of Gradleware.
Thursday has several Jenkins talks. One is The Deploy Factory: Open Source Tools for Java Deployment [CON1880] from Bruno Souza (aka the Java Man from Brazil) and Edson Yanaga. In this same time slot, guys from eBay are doing Platform Upgrades as a Service [CON5685], which discusses how they rely on automation to make platform upgrades painless. Then Mastering Continuous Delivery and DevOps [CON1844] from Michael Huttermann.
In the exhibit area, the Jenkins project doesn't have its own booth (JavaOne is too expensive for that), but I'll be at the CloudBees booth, so is Jesse Glick. Find us at the booth for any Jenkins questions or impromptu hacking session, which would really help us as we get distracted from the booth duties that way. Or just drop by to get stickers, pin badges, and other handouts to take for your colleagues.
And finally, Script Bowl 2014: The Battle Rages On [CON2939] gets an honorable mention because our own Tyler Croy is representing JRuby against other scripting languages, including my favorite Groovy. Hmm, who should I root for...
The usual suspects, such as CloudBees, XebiaLabs, SOASTA, PuppetLabs, et al are doing a Jenkins-themed continuous delivery event series called "cdSummit." The event is free, has a nice mix of user/vendor talks, and has an appeal to managers and team leads who are working on and struggling with continuous delivery and automation.
I've spoken in the past events, and I enjoyed the high-level pitches from various speakers. The last two events at Paris and London filled up completely, so I suspect others have liked them, too.
If you live near Chicago, Washington DC, or San Francisco, check out the date and see if you can make it. RSVP is from here. If you do, be sure to pick up Jenkins stickers and pin badges!
As was discussed some time ago, the workflow summit is being organized, and it's open for RSVP.
Due to the overwhelming demand, I've increased the capacity this time to 50, but this is an unconference where everyone needs to participate, which means we really cannot have too many people without changing the dynamics of the event.
So please make sure you are willing to participate, as in not just listening and watching, but actually willing to speak. We expect you to bring something to the table — opinions, experiences, rants, presentations, feedbacks, etc. If you don't please let others take the seat, and rest assured we will give a presentation about workflow in JUC Bay Area.
If you understand the criteria, please RSVP is from here.
If you’ve already taken a look at SonaQube 4.4, the title of this post wasn’t any news to you. The new version introduces two major changes to the way SonarQube presents data: the new rules space and the changes to the source viewer.
If you’ve been keeping up version to version, you’ve noticed new styling creeping in to the design. We formed a Web team this year to focus on transforming SonarQube’s interface into something as sexy as the underlying functionality, and the team is starting to hit its stride.
The new rules space is a reimagining of how to interact with rules. Previously, they were accessed only within the context of their inclusion (or not) in a single profile. Want to know if a given rule is present in multiple profiles? Previously, you had to hunker down because it could take a while.
Now rules have their own independent presentation, with multi-axis search.
All the search criteria from the old interface are still available, and several new ones have been added. The rule tags introduced in SonarQube 4.2 become searchable in 4.4, as do SQALE characteristics. And for most criteria you can search for multiple values. For example, it’s now easy to find rules in both “MyFirstProfile” and “MySecondProfile” simply by checking them both off in the profile dropdown.
At the bottom of the rule listing, you’ll see all the profiles it’s included in, along with the severity and any parameters for the profile. If you’re an administrator, you’ll have controls here to change a rule in its current profiles and to add it to new profiles. The search results pane on the left also features bulk change operations for administrators, allowing them to toggle activation in a profile for all the rules in the search results.
It’s also easy now to find clone-able rules such as XPath and Architectural Constraint in Java; they’re called “templates” starting in 4.4, and they get their own search criterion.
I shouldn’t forget to mention the second tier below the search criteria. It represents the categories the search results span: languages, repositories, and tags, and the search results can be further filtered by clicking on the entries there. (A second click deselects and unfilters). For instance, here’s the default search filtered to show C rules that have been tagged for MISRA C++:
The point of this radical overhaul is to give you, the user, a better way to explore rules; to see what rules are available, which rules are used where, and which rules you might want to turn on or ask your administrator to turn on.
One interesting aspect of this is the new ability to explore rule activation across languages. For rules that are implemented directly within a plugin, as opposed to coming from 3rd party tools like FxCop or FindBugs, you’ll see that when the same rule is implemented in multiple languages, it usually has the same key (there are a few historical exceptions.)
So, for example, now you can easily see whether the same standards are being enforced across all languages in your organization.
The new rules space is just one piece of our new attitude toward data. Next time I’ll talk about the complete rework of the component viewer. It’s a reimagining that’s just as radical as this one.
My apologies for the last minute announcement, but there will be a Jenkins user meet-up in Paris on Sep 10th 7:00pm, which is just next week. The event is hosted by Zenika. You'll hear from Gregory Boissinot and Adrien Lecharpentier about plugin development, and I'll be talking about workflow.
It's been a while we do a meet-up in Paris. Looking forward to seeing as many of you as possible. The event is free, but please RSVP so that we know what to expect.
JUC SF on October 23, 2014 is shaping up to be bigger and better this year.
Here’s what we have in store for you!Three Tracks
We’ve received a record high of 40 stellar proposals this year. To accommodate the many community proposals, we’ve decide to add a third track to the agenda. JUC SF sessions are now available for you to view. We have speakers from Google, Target, Gap, Cloudera, Ebay, Chicago Drilling Company, and much more. Register now for early bird price. The early bird price is only good until September 21, 2014.Live Stream
Have a beer while learning how to write Jenkins plugin. Steve Christou, Jenkins support engineer will lead this lecture from 3:30pm to 6:00pm. He will teach everything from how to get started, to techniques like writing a new CLI Command, to writing your own builder.Ask the Experts
Meet the Jenkins creator, committers, support engineers, and developers. We have dedicated time slot(s) for our attendees to get 1 on 1 access to our experts. Exact time is TBD. Ask them anything from plugins, configuration, technical support, to bug fixes.
Our current list of experts are:
- Andrew Bayer
- Gareth Bowles
- Steve Christou
- Jesse Glick
- Kohsuke Kawaguchi
- Dean Yu
Want to join our panel of experts? Contact Alyssa Tong firstname.lastname@example.orgExhibit Mixer
Sixteen technology sponsors will be showcasing their newest technologies during the exhibition hour from 2:25 – 3:30pm. Grab a beer, visit with sponsors and see how they are using Jenkins.
This is just a taste of what you’ll see at JUC SF. We look forward to seeing you there!!
Jesse and I will walk through the source code of the workflow plugin, highlights key abstractions and extension points, and discuss how they are put together.
If you are interested in developing or retrofitting plugins to work with workflows, I think you'll find this session interesting.
(This is a guest post from Michael Neale)
Recently at the Docker Conference (DockerCon) the Docker Hub was announced.
The hub (which includes their image building and storage service) also provides some "official" images (sometimes they call them repositories - they are really just sets of images).
So after talking with all sorts of people we decided to create an official Jenkins image - which is hosted by the docker hub simply as "jenkins".
So when you run "docker pull jenkins" - it will be grabbing this image. This is based on the current LTS (and will be kept up to date with the LTS) - but does not include the weekly releases (yet). Having a jenkins image that is fairly basic (it includes enough to run some basic builds, as well as jenkins itself) built on the LTS, on the latest LTS of Ubuntu seemed quite convenient - and easy to maintain using the official Ubuntu/Debian packaging of Jenkins.
Docker is a great way to try and use server based systems - it brings all the dependencies needed and the images actually are portable (ie anywhere docker runs you can run docker images). There are official images for many popular server platforms (redis, mysql, all the linux distros and so on) so it seemed crazy to not include Jenkins along with this list. "docker run -p 8080:8080 jenkins" is all you need to get going with LTS Jenkins now. You can also use "docker run jenkins:1.554" to get the latest of that lineage of LTS releases, or pick a specific one: "docker run jenkins:1.554.3" if you like. Leaving off a version assumes the latest. Check the tags page to see what is available.
You can read more and see how you can use it here.
There has been some questions and discussions on how to make use of Jenkins with the docker hub for creating new and interesting docker image based workflows for deployment. In fact, Jenkins featured in one of the first slides of the first keynote of docker con: To make this dream a reality some additional plugins had to be created - but this leaves the possibility of working with the docker hub (builds, stores images) and Jenkins (workflow, testing, deployment) to build out some kind of a continuous pipeline for handling docker based apps. I attempted to describe this more here.
It will be interesting to watch this grow and change.
I'll talk about my recent chef/puppet integration work in Jenkins. Sven from Perforce will talk about how to leverage Perforce features from Jenkins, and then James Nord will talk about workflow. It will be a worthy 2 hours.
If the line up of talks will not be enough to sway you, you should also know that I will bring some Jenkins give-aways!
I'm not sure how many people to expect, but there's a cap at 80 people, so if you are thinking about coming, be sure to RSVP. Looking forward to seeing many of you there!
Finally, if you are in London, the usual suspects (CloudBees, PuppetLabs, XebiaLabs, MidVision, SOASTA, et al) are doing a free event titled "How To Accelerate Innovation with Continuous Delivery" that you might also be interested in.
The team is proud to announce the release of SonarQube 4.4, which includes many exciting new features:
- Rules page
- Component viewer
- New Quality Gate widget
- Improved multi-language support
- Built-in web service API documentation
With this version of SonarQube, rules come out of the shadow of profiles to stand on their own. Now you can search rules by language, tag, SQALE characteristic, severity, status (E.G. beta), and repository. Oh yes, and you can also search them by profile, activation, and profile inheritance.
Once you’ve found your rules, this is now where you activate or deactivate them in a profile – individually through controls on the rule detail or in bulk through controls in the search results list (look for the cogs). In fact, the profiles page no longer has it’s own list of rules. Instead, it offers a summary by severity, and a click through to a rule search.
Another shift in rule handling comes for what used to be called “cloneable rules”. We’ve realized that strictly speaking, these are really “templates” rather than rules, and now treat them as such.
Templates can no longer be directly activated in a profile. Instead, you create rules from them and activate those.Component viewer
The component viewer also experienced major changes in this version. The tabs across the top now offer filtering, which controls what parts of the code you see (E.G. only show me the code that has issue), and decoration, which controls what you see layered on top of the code (show/hide the issues, the duplications, etc.).
A workspace concept debuts in this version. As you navigate from file to file through either code coverage or duplications, it helps you track where you are and where you’ve been.
A new Quality Gate widget makes it clearer just what’s wrong if your project isn’t making the grade. Now you can see exactly which measures are out of line:
Multi-language analysis was introduced in 4.2 and it just keeps getting better. Now we’ve added the distribution of LOC by language in the size widget for multi-language projects.
We’ve also added a language criterion to the Issues search:
To find this last feature, look closely at at 4.4′s footer.
We now offer on-board API documentation.
This is a guest post from Tom Fennelly
Over the last number of weeks we've been trying to "refresh" the Jenkins UI, modernizing the look and feel a bit. This has been a real community effort, with collaboration from lots of people, both in terms of implementation and in terms of providing honest/critical feedback. Lots of people deserve credit but, in particular, a big thanks to Kevin Burke and Daniel Beck.
Current / Old Look & Feel
New Look & Feel
Among other things, you'll see:
- A new responsive layout based on <div> elements (as opposed to <table> elements). Try resizing the screen or viewing on a smaller device. More to come on this though, we hope.
- Updated default font from Verdana to Helvetica.
- Nicer form elements and nicer buttons.
- Smoother side panels e.g. Build Executors, Build Queues and Build History panes.
- Smoother project views with more modern tabs.
You might already be seeing these changes if you're using the latest and greatest code from Jenkins. If not, you should see them in the next LTS release.
We've been trying to make these changes without breaking existing features and plugins and, so far, we think we've been successful but if you spot anything you think we might have had a negative effect on, then please log a JIRA and we'll try to address it.
One thing we've "sort of" played with too is cleaning up of the Job Config page - breaking into sections and making it easier to navigate etc. This is a big change and something we've been shying away from because of the effect it will have on plugins and form submission. That said, I think we'll need to bite the bullet and tackle this sooner or later because it's a big usability issue.
Starting with Java Ecosystem version 2.2 (compatible with SonarQube version 4.2+), we no longer drive the execution of unit tests during Maven analysis. Dropping this feature seemed like such a natural step to us that we were a little surprised when people asked us why we’d taken it.
Contrary to popular belief we didn’t drop test execution simply to mess with people. :-) Actually, we’ve been on this path for a while now. We had previously dropped test execution during PHP and .NET analyses, so this Java-only, Maven-only execution was the last holdout. But that’s trivial as a reason. Actually, it’s something we never should have done in the first place.
In the early days of SonarQube, there was a focus on Maven for analysis, and an attempt to add all the bells and whistles. From a functional point of view, the execution of tests is something that never belonged to the analysis step; we just did it because we could. But really, it’s the development team’s responsibility to provide test execution reports. Because of the potential for conflicts among testing tools, the dev team are the only ones who truly know how to correctly execute a project’s test suite. And in the words of SonarSource co-founder and CEO, Olivier Gaudin, “it was pretentious of us to think that we’d be able to master this in all cases.”
And master it, we did not. So there we were, left supporting a misguided, gratuitous feature that we weren’t sure we had full test coverage on. There are so many different, complex surefire configuration cases to cover that we just couldn’t be sure we’d implemented tests for all of them.
Plus, This automated test execution during Java/Maven analysis had an ugly technical underbelly. It was the last thing standing in the way of removing some crufty, thorn-in-the-side, old code that we really needed to get rid of in order to be able to move forward efficiently. It had to go.
We realize that switching from test execution during analysis to test execution before analysis is a change, but it shouldn’t be an onerous one. You simply go from
mvn clean install
mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install -Dmaven.test.failure.ignore=true
Your analysis will show the same results as before, and we’re left with a cleaner code base that’s easier to evolve.
Software projects often publish comparisons with other projects, with which they compete. These comparisons typically have a few characteristics in common:
- They aim at highlighting reasons why one project is superior – that is, they are marketing material.
- While they may be accurate when initially published, competitor information is rarely updated.
- Pure factual information is mixed with opinion, sometimes in a way that doesn’t make clear which is which.
- Competitors don’t get much say in what is said about their projects.
- Users can’t be sure how much to trust such comparisons.
Of course, we’re used to it. We no longer expect the pure, unvarnished truth from software companies – no more than from drug companies, insurance companies, car salesmen or government agencies. We’re cynical.
But one might at least hope that open source projects might do better. It’s in all our interests, and in our users’ interests, to have accurate, up-to-date, unbiased feature comparisons.
So, what would such a comparison look like?
- It should have accurate, up-to-date information about each project.
- That information should be purely factual, to the extent possible. Where necessary, opinions can be expressed only if clearly identified as opinion by it’s content and placement.
- Developers from each project should be responsible for updating their own features.
- Developers from each project should be accountable for any misstatements that slip in.
I think this can work because most of us in the open source world are committed to… openness. We generally value accuracy and we try to separate fact from opinion. Of course, it’s always easy to confuse one’s own strongly held beliefs with fact, but in most groups where I participate, I see such situations dealt with quite easily and with civility. Open source folks are, in fact, generally quite civil.
So, to carry this out, I’m announcing the .NET Test Framework Feature Comparison project – ideas for better names and an acronym are welcome. I’ll provide at least a temporary home for it and set up an initial format for discussion. We’ll start with MbUnit and NUnit, but I’d like to add other frameworks to the mix as soon as volunteers are available. If you are part of a .NET test framework project and want to participate, please drop me a line.
Webinar: Solve Performance Bottlenecks and Function Problems In Your
February 22, 2012
Source Test Workshop for Developers, Testers, IT Ops - Learn how
the Open Source Test Tools Make Test Development and Operation Easy
February 23, 2012
Source Test Workshop for CIOs, CTOs, Business Managers - Learn how
to bring Open Source Test tools and methodology into your organization
March 21, 2012
soapUI, Sahi, TestMaker Workshop for Testers, Developers, IT Ops
March 22, 2012
Open Source Performance Test Workshop for CIOs, CTOs, Business Managers
- Load and performance testing without hassle and cost
March 28, 2012
Open Source Performance Test Workshop for Developers, Testers, IT
Managers - The PushToTest Calibration Test Methodology explained
March 29, 2012
Selenium, soapUI, Sahi, TestMaker Performance Testing In Your
April 17, 2012
Open Source Performance Test Workshop for Developers, Testers, IT
April 18, 2012
Source Test Workshop for CIOs, CTOs, Business Managers
May 2, 2012
soapUI, Sahi, TestMaker Workshop for Testers, Developers, IT Ops
May 3, 2012
The Selenium Tutorial for Beginners has the following chapters:
- Selenium Tutorial 1: Write Your First Functional Selenium Test
- Selenium Tutorial 2: Write Your First Functional Selenium Test of an Ajax application
- Selenium Tutorial 3: Choosing between Selenium 1 and Selenium 2
- Selenium Tutorial 4: Install and Configure Selenium RC, Grid
- Selenium Tutorial 5: Use Record/Playback Tools Instead of Writing Test Code
- Selenium Tutorial 6: Repurpose Selenium Tests To Be Load and Performance Tests
- Selenium Tutorial 7: Repurpose Selenium Tests To Be Production Service Monitors
- Selenium Tutorial 8: Analyze the Selenium Test Logged Results To Identify Functional Issues and Performance Bottlenecks
- Selenium Tutorial 9: Debugging Selenium Tests
- Selenium Tutorial 10: Testing Flex/Flash Applications Using Selenium
- Selenium Tutorial 11: Using Selenium In Agile Software Development Methodology
- Selenium Tutorial 12: Run Selenium tests from HP Quality Center, HP Test Director, Hudson, Jenkins, Bamboo
- Selenium Tutorial 13: Alternative To Selenium
I wrote a Selenium tutorial for beginners to make it easy to get started and take advantage of the advanced topics. Download TestMaker Community to get the Selenium tutorial for beginners and immediately build and run your first Selenium tests. It is entirely open source and free!
Distributing the work of performance testing through an Agile epoc, story, and sprints reduces the testing effort overall and informs the organization's business managers on the service's performance. The biggest problem I see is keeping the testing transparent so that anyone - tester, developer, IT Ops, business manager, architect - follows a requirement down to the actual test results.
With the right tools, methodology, and coaching an organization gets the following:
- Process identification and re-engineering for Test Driven
- Installation and configuration of a best-in-class SOA Test Orchestration Platform to enable rapid test development of re-usable test assets for functional testing, load and performance testing and production monitoring
- Integration with the organization's systems, including test management (for example, Rally and HP QC) and service asset management (for example, HP Systinet)
- Construction of the organization's end-to-end tests with a team of PushToTest Global Professional Services, using this system and training of the existing organization's testers, Subject Matter Experts, and Developers to build and operate tests
- On-going technical support
The key to high quality and reliable SOA service delivery is to practice an always-on management style. That requires on-site coaching. In a typical organization the coaches accomplish the following:
- Test architects and test developers work with the existing
Team members. They bring expert knowledge of the test tools. Most
important is their knowledge of how to go from concept to test
- Technical coaching on test
automation to ensure that team members follow defined
Agile, Test Management, and Roles in SOA
Agile software development process normally focuses first on functional testing - smoke tests, regression test, and integration tests. Agile applied to SOA service development deliverables support the overall vision and business model for the new software. At a minimum we should expect:
- Product Owner defines User Stories
- Test Developer defines Test Cases
- Product team translates Test Cases into soapUI, TestMaker Designer, and Java project implementations
- Test Developer wraps test cases into Test
Scenarios and creates an easily accessible test record associated to
the test management service
- Any team member follows a User Story down into associated tests. From there they can view past results or execute tests again.
- As tests execute the test management system creates "Test
Execution Records" showing the test results
- To what extent will large organizations dump legacy test tools for open source test tools?
- How big would the market for private cloud software platforms be?
- Does mankind have the tools to make a reliable success of the complicated world we built?
- How big of a market will SOA testing and development be?
- What are the best ways to migrate from HP to Selenium?
The Scalability Argument for Service Enabling Your Applications. I make the case for building, deploying, and testing SOA services effectively. I point out the weakness of this approach comes at the tool and platform level. For example, 37% of an application's code simply to deploy your service.
How PushToTest Uses Agile Software Development Methodology To Build TestMaker. A conversation I had with Todd Bradfute, our lead sales engineer, on surfacing the results of using Agile methodology to build software applications.
"Selenium eclipsed HP’s QTP on job posting aggregation site Indeed.com to become the number one requisite job experience / skill for on-line posted automated QA jobs (2700+ vs ~2500 as of this writing,)" John Dunham, CEO at Sauce Labs, noted.
Run Private Clouds For Cost Savings and Control. Instead of running 400 Amazon EC2 machine instances, Plinga uses Eucalyptus to run its own cloud. Plinga needed the control, reliability, and cost-savings of running its own private cloud, Marten Mickos, CEO at Eucalyptus, reports in his blog.
How To Evaluate Highly Scalable SOA Component Architecture. I show how to evaluate highly scalable SOA component architecture. This is ideal for CIOs, CTOs, Development and Test Executives, and IT managers.
Planning A TestMaker Installation. TestMaker features test orchestration capabilities to run Selenium, Sahi, soapUI, and unit tests written in Java, Ruby, Python, PHP, and other langauges in a Grid and Cloud environment. I write about the issues you may encounter installing the TestMaker platform.
Repurposing ThoughtWorks Twist Scripts As Load and Performance Tests. I really like ThoughtWorks Twist for building functional tests in an Agile process. This blog and screencast shows how to rapidly find performance bottlenecks in your Web application using Thoughtworks Twist with PushToTest TestMaker Enterprise test automation framework.
4 Steps To Getting Started With The Open Source Test Engagement Model. I describe the problems you need to solve as a manager to get started with Open Source Testing in your organization.
Corellation Technology Finds The Root Cause To Performance Bottlenecks. Use aspect-oriented (AOP) technology to surface memory leaks, thread deadlocks, and slow database queries in your Java Enterprise applications.
10 Agile Ways To Build and Test Rich Internet Applicatiions (RIA.) Shows how competing RIA technologies put the emphasis on test and deploy.
Oracle Forms Application Testing. Java Applet technology powers Oracle Forms and many Web applications. This blog shows how to install and use open source tools to test Oracle Forms applications.
Saving Your Organization From The Eventual Testing Meltdown of Using Record/Playback Solely. The Selenium project is caught between the world of proprietary test tool vendors and the software developer community. This blog talks about the tipping-point.
Choosing Java Frameworks for Performance. A round-up of opinions on which technologies are best for building applications: lightweight and responsive, RIA, with high developer productivity.
Selenium 2: Using The API To Create Tests. A DZone Refcard we sponsored to explain how to build tests of Web applications using the new Selenium 2 APIs. For the Selenium 1 I wrote another Refcard, click here.
Test Management Tools. A discussion I had with the Zephyr test management team on Agile testing.
Migrating From HP Mercury QTP To PushToTest TestMaker 6. HP QTP just can't deal with the thousands of new Web objects coming from Ajax-based applications. This blog and screencast shows how to migrate.
10 Tutorials To Learn TestMaker 6. TestMaker 6 is the easier way to surface performance bottlenecks and functional issues in Web, Rich Internet Applications (RIA, using Ajax, Flex, Flash,) Service Oriented Architecture (SOA,) and Business Process Management (BPM) applications.
5 Easy Ways To Build Data-Driven Selenium, soapUI, Sahi Tests. This is an article on using the TestMaker Data Production Library (DPL) system as a simple and easy way to data-enable tests. A DPL does not require programming or scripting.
Open Source Testing (OST) Is The Solution To Modern Complexity. Thanks to management oversite, negligence, and greed British Petroleum (BP) killed 11 people, injured 17 people, and dumped 4,900,000 barrels of oil into the Gulf of Mexico in 2010. David Brooks of the New York Times became an unlikely apologist for the disaster citing the complexity of the oil drilling system.
Choosing automated software testing tools: Open source vs. proprietary. Colleen Fry's article from 2010 discusses why software testers decide which type of automated testing tool, or combination of open source and proprietary, to best meets their needs. We came a long way in 2011 to achieve these goals.
All of my blogs are found here.