Last time I blogged about the importance of benchmarking the architecture and new technology in a Proof of Concept for Performance. This time I’ll deal with the importance of representative performance testing.
Slowness of applications in development environments is often neglected with the rationale that faster hardware in the production environment will solve this problem. However, whether this is really true can only be predicted with a test on a representative environment and in a representative way. In such an environment, there needs to be more representative than just the hardware.
(more...)
Tags: JMeter, Performance, Testing, Tools
Filed under Java, Performance, Quality Assurance, Testing, Tools | No Comments »
Last week I blogged about setting your performance goals: defining your requirements. This time I'll blog about the importance of a Proof of Concept for performance.
The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.
(more...)
Tags: Architecture, Java, Performance
Filed under Architecture, Java, Performance, Quality Assurance, Requirements Management, Testing | No Comments »
Last week I blogged about the increasing load at web shops and the increasing challenges for developers and operators. The question to be answered was stated as: how can we prevent performance and availability problems; how can we assure that a web site is always quick and available? In this blog I’ll describe some of the forms in which I found performance difficulties to present themselves. (more...)
Tags: availability, business, frustration, hardware, load, speed., troubleshooting, web shop
Filed under Java, Performance, Quality Assurance | No Comments »
Recently I was challenged by a client to test a new web application in an Agile project. The team was new at working Agile and even more with working together with a functional tester, altogether this resulted in me getting very little development support from the team.
Because the lack of tooling and support I focussed my efforts on just recording test-scripts using Selenium IDE, hoping I would be able to reuse them once I got the development support I had been requesting. The plan was to integrate the pre-recorded scripts in a more extended test environment in a later stage of the project.
Tags: Agile, fitnesse, Scrum, Selenium, Testing
Filed under Agile, Quality Assurance, Testing, fitnesse | 6 Comments »
About 2 years ago I first heard the term "technical debt" from one of my coworkers. Well, I heard technical depth instead of debt first, which clearly did not help me see why it was such a great term for crappy code and quick and dirty solutions.
Filed under Quality Assurance | No Comments »
A new version of Xebia's open source maven-dashboard-plugin has been released. This version fixed some bugs. A quick guide on how to use the dashboard in your project please read this blogpost.
Keep an eye on this blog or checkout the roadmap in Jira for upcoming releases.
Tags: dashboard, Maven, plugin
Filed under Java, Maven, Quality Assurance | No Comments »
As you enter into Agile world, a statement welcomes you - "Just do enough documentation". For quite sometime, I was puzzled what we really mean by this. In my view "just-enough" is very ambiguous or abstract. You cannot quantify it. For some who are working for a development project, creating documentation may not make much sense as you can find people just across your table to answer your question and you can get away by doing "not just-enough documentation" (no java-docs, no project overview etc). However when you come in maintenance cycle of the project, it just sucks. Maintenance may implicitly means new people, a long project cycle and people who leave the project or even organization itself.
What do you do then? People who were in the project at the beginning may not be there anymore, either from customer side or from software developers side. Without having a knowledge repository, new people will try to reinvent the wheel, will go through the code (white box, which ideally should be a black box most of the times) or will look like people who enter in a dark tunnel without having clue on what they are supposed to do.
Tags: agile documentation
Filed under Agile, Multimedia, Project Management, Quality Assurance | 1 Comment »
Quality is an everyday part of the life of a Xebia software developer. One of the ways to get insight into quality is by looking at metrics like FindBugs, PMD, Simian, Code Coverage, etc. With large software products consisting of different modules, quality assurance can become quite a trying task. This means that tools which alleviate this burden are a welcome addition to our toolbox.
(more...)
Filed under Java, Maven, Quality Assurance | 7 Comments »
Many courses and books on requirements will tell you that a good requirement describes the “what” of a need of a customer (or more generally, stakeholder). They will tell you that you shouldn’t write down the “how” (they call that ‘design’) because it pushes you in a technical direction and causes you to miss out on other good solutions.
That’s good advice in the sense that you shouldn’t restrict yourself to a solution if another solution satisfies the needs of a customer better. But when is something a design, and when is it a requirement? If you’ve thought about it, you realized that it is hard to draw the line. (more...)
Filed under Quality Assurance, Requirements Management | 3 Comments »
Tonight, we organized our biweekly XKE (Xebia Knowledge Exchange), which is a forum where we update each other on interesting developments or have discussions on various topics.
One of the topics of tonight was: "what keeps us programming in Java"? The underlying thought about it was: what prevents us from programming in a different language, especially a dynamic language like Ruby on Groovy. Because I'm a little more into Groovy than I am into Ruby, I'll talk the rest of the blog about Groovy, but you can probably exchange it for any (dynamic) language.
One of the key factors (and this might sound like an open door) to stick to programming in Java is that we are all very familiar with the language. We have invested time learning it, we know the frameworks, and we have real experience that it works. Furthermore, people know how to manage a Java application, know how to deploy it on an application server, and as an added bonus, IDE's support Java really well.
(more...)
Filed under Agile, Groovy, Java, Quality Assurance | 4 Comments »