Posted by Aman Arora just before lunchtime: September 30th, 2009
Nowadays paired programming concept is getting more and more common in the IT industry because of its benefits like design quality, overcoming difficult problems and better time management etc. Similarly a new concept of Paired Testing is getting famous now among the testers who are working in an agile environment. This concept of testing is similar to paired programming approach. In this approach the person doing the testing is called the driver while the other suggests ideas or tests, pays attention and takes notes, listens, asks questions, grabs reference material, observes or reviews etc.
(more…)
Posted by Aman Arora around lunchtime: August 27th, 2009
I joined Xebia India as a tester for one of the project. While validating the defects the biggest problem that I faced was regarding the understanding of defect report and trying to reproduce the said problem when there were no steps. Being a new member to the team and joining the application in between the sprints added to it. Every time when I had to validate the defect and steps to reproduce were not there I had to run to the developer for their help. Developers too were tied up with their own tight schedules and sometimes the validation for the defect had to wait for sometime which created a backlog for me and then I thought to come up with the solution to it which I am discussing below. Using the following approach helped us and can help all.
(more…)
Posted by Mischa Dasberg at around evening time: August 25th, 2009
Last week I ran into a problem while testing AjaxBehavior in Wicket.
Consider the following scenario: we have a FormComponent which has an AjaxBehavior added to it. We want to test that behavior. Depending on the selected value of for instance a RadioChoice, the Ajaxbehavior should show one component and hide another.
You would think that this would be out of the box behavior when using WicketTester, but unfortunately this is not the case. Triggering an Ajaxbehavior is easy using WicketTester, but setting the selected value isn’t. (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 Andrew Phillips in the early evening: July 21st, 2009
Recently, I was writing an Annotation Processor for the @Composite project. In good TDD fashion, that first and foremost meant writing some tests.
Although I in the end come across something that was fairly workable, it was trickier than one might have hoped for.
Posted by Vincent Partington around lunchtime: July 11th, 2009
In the previous blog in the JPA implementation patterns series, I talked about the three default ways of mapping inheritance hierarchies using JPA. And introduced one non-standard but quite useful method. This week I will discuss various approaches to testing JPA code.
What to test?
The first question to ask is: what code do we want to test? Two kinds of objects are involved when we talk about JPA: domain objects and data access objects (DAO’s). In theory your domain objects are not tied to JPA (they’re POJO’s, right?), so you can test their functionality without a JPA provider. Nothing interesting to discuss about that here. But in practice your domain objects will at least be annotated with JPA annotations and might also include some code to manage bidirectional associations (lazily), primary keys, or serialized objects. Now things are becoming more interesting…
(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 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 Sunil Prakash Inteti in the early afternoon: April 17th, 2009
SeamTest is a class we extend for the tests we write in our Seam application. It provides the seam environment in tests something analogous to WicketTester in Wicket Application.
I want to share some information on setting the property of Session bean, i came to know while using the SeamTest.
(more…)