Many informative tips were published on SearchSoftwareQuality.com in 2010. Here is a countdown of the most popular tips of the year:
Used in conjunction with Selenium’s online tutorials, this tip provides additional guidance on how to start out with Selenium RC in Perl regardless of your platform or server. Once you have Selenium set up, learn how to create and run your first test.
Selenium, an open source automation testing tool, offers an Integrated Development Environment (IDE) plug-in that unifies the tool with desirable Web browser-based test features. Using Selenium IDE provides easy-to-use record and play back features, giving even those with no programming expertise, the capability to create simple scripts.
Web 2.0 and Rich Internet applications, though great functionality-wise. can place many complications in the way of Web security. In this tip, a Web security expert explains where problems can occur and what free tools are available to avoid issues.
Learn how to write load tests, TestCases and run them with soapUI in this expert tutorial. SoapUI is great for tracking test criteria statistics and locating problem areas are.
An expert tester explains seven useful tips for determining appropriate performance requirements that can be tested throughout the development cycle. Knowing the right conversations to have with stakeholders and project team members will lead to high-quality, quantifiable performance requirements.
Although POST and GET HTTP requests essentially perform the same command on a Web server, a security expert says there are inherent dangers in using one over the other. Learn why one type of processing request provides more security for your Web application in this expert tip.
Often called the daily stand-up, must everyone at the Daily Scrum meeting literally stand? Which rules are inflexible? How are the rules enforced? Find out the objectives of the Daily Scrum and how agile teams are operating to meet these objectives.
How will agile testing methods be determined? What are the best testing tools? Learn what agile project managers need to know to assure high quality in their tests.
Is your organization trying to decide whether to use a predictive methodology such as waterfall or an adaptive methodology such as scrum? Senior consultant David Johnson describes the history of software methodologies and the differences between these two models of software development. A hybrid approach combining aspects of both models may be a viable alternative as well.
After exploring the definition of a test case by surveying test experts, authors and students, consultant Robin Goldsmith learns that interpretations remain ambiguous and varied. Similarly, the level of detail thought to be needed to define requirements can vary and can often drive the level of detail of the test efforts.
This week on SearchSoftwareQuality.com, we explore two characteristics of ALM that are above and beyond what is talked about when discussing SDLC: extending the lifecycle to DevOps and collaboration.
In Extending ALM to deployment, Colleen Frye describes how ALM is now extending to release management, deployment and operations, areas often not associated with the traditional software development lifecycle. She quotes Forrester Research analyst Dave West as saying:
While traditionally ALM has focused on automating the software development lifecycle (SDLC), “increasingly we’re thinking ALM is a broader category that includes delivering the software, the ‘last mile’ of software. The point is information needs to be available to make effective [deployment] decisions.”
Similarly, SSQ contributor Chris McMahon also talks about the trend to extend the lifecycle to include “DevOps” in his tip, DevOps: Fostering collaboration in software development. McMahon notes the importance of collaboration between development and operations, a common theme in both ALM and agile methodologies.
In my tip, Collaboration tools: Communication trends in ALM, I talk about the prevalence of collaboration features in ALM tools allowing teams to communicate more effectively throughout the lifecycle.
Last week, software requirements management vendor Jama added collaboration features to their Contour product. Jama CEO Eric Winquest says Contour 3.0 adds features which will allow teams to stay more connected, be informed of changes and communicate more effectively. Winquest talked about the growing complexity of software and the many tools and processes that are available. However, he stressed the importance of the communication of the project team.
“At the end of the day, it’s not really the tools and methodologies that get projects done, it’s really the people. We believe it’s the human interactions that are missing from enterprise software tools.”
In my recent tip, Collaboration tools: Communication trends in ALM, I write about how collaboration in ALM tools is a growing trend in the industry. With distributed teams, collaborative features allow teams to have stronger communication, better change management, and better ability to store and archive all kinds of data and documentation and keep that documentation up-to-date.
Mace Volzing, software development manager at IntraPace, used Contour to help manage the requirements for IntraPace’s abiliti device– a medical device with embedded sofware used to help obese patients manage their eating habits. Volzing found the tracability features of Contour invaluable and necessary when doing development for a medical device.
“Each project has documents that are interrelated. All of them link together through Contour, which is incredible when you go to do any kind of maintenance later or any kind of change request later on.”
IntraPace used a waterfall methodology to develop the firmware for the abiliti device. However, web software is also under development that will allow for social networking among the patients using the device. For this, Interpace is using a Scrum methodology with success. Volzing believes that for the next release of firmware, they may use a hybrid approach. However, regardless of methodology, they’ve found that Contour is easy to use, providing the needed functionality to document and track their requirements throughout the lifecycle.
Volzing said they are looking forward to the upgrade to Contour and having the additional collaboration features in place.
The first time I heard about integrating CMMI and agile was at IBM’s Innovate conference last spring. I thought it an odd combination. My experience with CMMI, a process-improvement methodology, was that it was extremely documentation-intensive and all about process. When you look at the Agile Manifesto, you see these are “right-sided” values– the values that are considered less important than the “left-sided” values agile touts such as people, working software, customer collaboration and responding to change. Can these two seemingly conflicting methodologies really be combined effectively?
Paul McMahon, author of Integrating CMMI and Agile Development, says ‘yes.’ In a two-part interview, I pose some tough questions for McMahon.
In CMMI and Agile integration: Adding agility to CMMI-mature organizations, part 1, I start by questioning McMahon about the combination of traditional model emphasizing process and documentation with a model that claims success by practicing a rather opposite philosophy. I ask about the buy-in from agile organizations in Adding CMMI process maturity to Agile organizations, part 2.
McMahon answers these questions and more, giving me a new perspective on CMMI and insights into how the balance of these two, when done correctly, can be a great benefit to an organization.
I’ve heard from many agile experts, including Elizabeth Woodward and Steffan Surdek, two of the authors of A Practical Guide to Distributed Scrum, about the importance of test-driven development (TDD).
Even though I had been a software developer for many years, I wasn’t entirely clear about the difference between unit testing and test-driven development. It seemed that the primary difference was that with TDD, the tests are written before the code, but I still was unclear as to why that would really make much difference.
Writing tests takes time, for sure. However, writing tests also saves time by removing or vastly reducing other activities, such as manual or formal debugging and ad hoc bug fixing. TDD also has the ability of reducing the total time spent writing tests. When retrofitting unit tests onto a system, a programmer will likely occasionally encounter tightly coupled code that is either hard or impossible to test. Because TDD promotes the unit test to the front seat, testability is never an issue.
Recently, Watts Humphrey, an icon of software quality, passed away at the age of 83. Humphrey was probably best known for his work as one of the founding fathers of the Capability Maturity Model (CMM), a popular and well-known process improvement methodology.
Hearing about his death, I was curious about CMM. Had they been updated over the years? Was the process improvement methodology itself undergoing improvements? As a matter of fact, I learned that the Software Engineering Institute (SEI) recently released CMMI for Development, v.1.3. The new version does include some additions, taking into account the transitions many organzations are making to agile software development.
In CMMI for development: An overview of a process improvement model I give a high-level overview of CMMI for development, the process improvement methodology which has continued to evolve over time. Though I just cover the basics, the full 482-page document is available from the SEI website.
Humphrey, of course, left behind a much bigger legacy than his work on the capability maturity model with 12 books and hundreds of articles influencing topics of software quality. In fact, just a few months ago, SSQ published a chapter excerpt from his book, Reflections on Management. He was a scholar who will be missed, but his work will remain to guide and teach others in the industry.
The most popular blog post on SQI for the year has been: Methodology wars: Agile or Waterfall? Most people still take software methodology very seriously and can get quite vocal about the benefits of using a particular methodology or quite defensive when questioned about some of the pitfalls. I’ve heard words such as “zealots” and “cult mentality” bandied around describing people who feel strongly about a particular methodology. But what exactly are the differences?
This month SSQ is focusing on software methodologies, bringing to you a variety of articles that will help you determine which methodology might be best for your organization.
In Waterfall or Agile: Differences between predictive and adaptive software methodologies, David Johnson highlights the differences between a predictive waterfall approach versus the adaptive agile approach to software development.
And in Applying lean concepts to software development, Matt Heusser describes practices that originated in manufacturing that are becoming more popular in software development such as the concepts of flow and continuous work.
Whether your software development processes are predictive, adaptive, lean or maybe use a mixture of concepts from various methodologies, your answer is not the one and only “right” way to develop code. What’s most important is that it is right for your organization.
At last week’s Boulder Agile User Group meeting, Pivotal Labs’ Mike Gehard described a day in the life of working in a rather unusual environment.
At Pivotal Labs, the culture is very important. They start their mornings with breakfast at 8:45. Their working hours are a very strict 9am to 6pm and their schedule looks like this:
9:15-ish Team standups
9:15-6:00 Pair programming
6:00 End of work day
Having been in corporate America for my whole career, I felt this was a rather rigid schedule, particularly for working parents who have children to pick up. However, Gehard showed a photo of an empty workplace at 6:05. Though the schedule is rigid, it means you can count on being done with your work at 6pm.
Gehard spoke a lot of the Extreme Programming practice of pair programming and what a big part of the culture it is at Pivotal Labs. I explore the topic further in the tip Pair programming: Two people, one computer.
Listen in to this short video where Gehard describes the importance of pair programming at Pivotal Labs:
[kml_flashembed movie="http://www.youtube.com/v/tETzWJ6ukxA" width="425" height="350" wmode="transparent" /]
In a recent interview with Jeff Papows, author of Glitch, the Hidden Impact of Faulty Software, one of the reasons Papows noted for the increased number of bugs found in production systems is the sheer volume and ubiquity of technology. He writes in his book:
It’s difficult to understate the scale at which the IT industry has transformed productivity, stimulated economic growth, and forever changed how people work and live.
Complexity of code was further reiterated in an interview I had with IBM’s Sky Matthews: How do you test 10 million lines of code? Matthews talks about the enormous amount of software that’s being used in the 2011 Chevy Volt.
Once again massive code complexity was noted by Coverity Chief Scientist Andy Chou in an interview in which he went over the results of an open source integrity report as noted in the post: Open source or proprietary: Which is higher quality?
Can improvements in processes and methodologies lead to higher quality to compensate for increasingly complex systems? Trends are showing that when development and testers collaborate closely as a unified team, breaking down silos, quality does improve. This may not be enough to solve all the quality issues that result from complex code, but it’s a step in the right direction.