Language menu for mobile

Agile

At LogiGear, we pride ourselves not only on providing world-class service to our clients, but on contributing to the development of the software testing industry as a whole.

Over the years, we've generated and collected a great deal of valuable information on Agile. The Agile and Testing Resource Center has been created to provide you with the information that can help you in your understanding and application of Agile. Below you will find links to articles, book reviews, interviews and videos from some of the industry's foremost thought-leaders and expert testers such as: Scott Ambler, Michael Hackett, Jonathan Rasmusson and Guido Schoonheim.

We're actively seeking additional resources to add, so if you've written about Agile and think your piece would be valuable to your peers, please feel free to submit an article by emailing logigearmagazine@logigear.com.

Agile Articles

As CTO of Xebia and highly experienced in offshore testing in India, Guido articulates his methods in addressing common challenges faced by the in-house and offshore teams. He weighs heavily on strategic tactics as well as key cultural aspects to execute efficient and effective Agile methods.
Agile is a philosophy focused on delivering constant value to customers incrementally and frequently, based on communication and feedback. These two ingredients are vital to a successful Agile recipe.
This article presents ten tips for Agile testing based on our experience. However, don’t expect to find the perfect test approach for your company or software project in this article. That is still something you will have to find out yourself!
Agile stresses instant and easy communication and is built on teams working efficiently together. This necessitates an open work space environment.

Agile, in terms of software development, has incorrectly and for too long come to mean fast and “getting product out the door quicker.” But Agile is not about speed; it is about being flexible.

When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them.
Agile methods were developed as a response to the issues that waterfall and V-model methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed.
Writing code that is easy to read and easy to test is difficult to achieve. The fact that poorly written code can function often leads to coding practices that are effective but not necessarily efficient. Too often, many programmers fresh out of school write code in the manner that was effective for passing their courses, but contains a lot of spaghetti.

Do testers have to write code?
For years, whenever someone asked me if I thought testers had to know how to write code, I’ve responded: “Of course not.”
The way I see it, test automation is inherently a programming activity. Anyone tasked with automating tests should know how to program.

In order to make the right choices among tools, you must be able to classify them. Otherwise, any choice would be at best haphazard. Without functioning classification, you would not be able to understand new tools fast, nor come up with ideas of using, or creating new tools.
Testing is often looked upon by many as an unmanageable, unpredictable, unorganized practice with little structure. It is common to hear questions or complaints from development including:

Continuous Improvement and Short Feedback loops (think: Test Driven Development; Sprint Demo/Review; …) are at the core of any Agile process. Without a structured improvement process it can be difficult for teams to improve and without improvement we stagnate. For methods like Scrum, XP and et al, Retrospectives are that tool.