Posted by Cirilo Wortel in the late evening: November 2nd, 2011
Last week I joined the QA&TEST conference in the beautiful town of Bilbao. In this post I’ll give an impression of some of the presentations I attended to and the idea’s I picked up. Most valuable sessions I attended were “Pushing the Boundaries of User Experience” by Julien Harty and “Automated Reliability Testing via hardware interfaces” by Bryan Bakker. Read about it in more detail in the article.
Posted by Gerard Janssen at around evening time: April 19th, 2010
Architecture can be divided into two categories : simple and complex.
And actually, it is the same with people. I prefer simple, humble and straightforward people. I find complex people hard to relate to, they often make a fuss about things that seem irrelevant to me and make life harder than it should be. In Holland we have a saying: “Such a person should come with a manual”. Only, I hardly ever read a manual. That is why I prefer people with a straightforward and ‘simple’ character that lack pretense and that you can take at face value. And it should be the same with architecture: let’s keep it simple. Simplicity is in fact a systemic quality that must be a driving force in architecture.
(more…)
Posted by Iwein Fuld in the early evening: April 14th, 2010
A lot of automated acceptance testing pioneers have come around and denounced their fate in heavy automated test suites. A recent article on InfoQ sums up the trend quite nicely. I am not going to jump on that bandwagon, but I will try to find the safe middle ground between the overzealously created maintenance burden and anarchy. The main point is that automating acceptance tests is the way to go, you just shouldn’t automate and maintain useless tests. The tricky part is to find out what tests are useful and what tests are not.
(more…)
Posted by Jeroen Borgers at around evening time: January 20th, 2010
Previous time I blogged about the last step of the seven steps, step 7: Share the responsibility for the whole chain, a non-technical but rather a communication and behavior thing which I found crucial for success. We now have reached the end of this series and I’ll sum up the topics we’ve dealt with and draw some conclusions. (more…)
Posted by Jeroen Borgers at around evening time: July 22nd, 2009
Last time I blogged about the importance of representative performance testing. Having production-like properties for hardware, OS, JVM, app server, database, external systems and simulated user load are essential to prevent bad performance surprises when going live. In addition, I described how cloud computing can be utilized to generate high loads on-demand without having to worry about the infrastructure.
Continuous performance testing
With a representative test as one of the last steps before going live we prevent that expensive bad-performance surprises will pop up in production. However, the same surprises will pop-up, only earlier and with less impact. To save costs and prevent large architectural refactoring, it is crucial to test for performance as soon as possible. This is just like any other software defects and Quality Assurance: the later in the development process defects are detected, the more costly these defects are.
At a popular web shop I had the following challenge: (more…)
Posted by Jeroen Borgers at around evening time: June 29th, 2009
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…)
Posted by Jeroen Borgers at around evening time: June 15th, 2009
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…)
Posted by Jeroen Borgers at around evening time: June 2nd, 2009
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…)
Posted by Cirilo Wortel around lunchtime: April 23rd, 2009
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.
Posted by Erwin van der Koogh around lunchtime: November 15th, 2008
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.