Most professionals in the software development industry recognize the need for Configuration Management (CM). CM has been around long enough for people to have experienced problems when CM was either not in place or when the level of CM was insufficient for the needs of the work. CM values of identification, control, audit, and report are meant to ensure integrity of the product under development. These days, almost everyone has, at least, version control practices which include a version control tool and a simple checkout/checkin process. However, as with any engineering discipline, the level of the CM implementation (since CM is much more than just version control) will depend greatly on the culture along with the methods and governance that exist within the company.
Statistical Process Control (SPC) has been an integral component of the Software Engineering Institute's (SEI's) maturity models for about nineteen years. This article describes an intellectual journey in which the primacy of SPC applied to software development processes is challenged.
Various white papers have been published on test automation
framework; however, test automation developers are often left wondering how to implement the framework. This article provides an overview of how the hybrid test automation framework can be implemented using QTP with example.
Back in the day of cross-Atlantic boat travel, luggage that wasn't needed during the long journey was labeled "Not Wanted on the Voyage" and stowed away below decks. In this week's column, Fiona Charles suggests that testers can also be viewed as heavy baggage and not exactly welcome by some parties during the journey of software development. To understand why others might think this way, Fiona takes a good, hard look at what testers do that could possibly make them undesirable team mates.
In the first article of this three-part series, Dean Leffingwell describes a nuanced approach to the role of the agile Product Owner in the enterprise setting, concluding that the enterprise is likely to need both agile Product Owners and agile Product Managers to achieve success.
When we schedule too many variables, things start to slip and soon the schedule is out the window. Paying attention to your project's constraints can help you set realistic scheduling goals that you will actually be able to stick to.
A hallmark of truly agile teams is an unquenchable desire to continually find new and better ways of developing software. These teams believe that there really are no "best" practices, only practices which work better or worse for them. This line of thinking is even apparent in the first line of the agile manifesto stating "we are uncovering better ways of developing." In this article I will explore two of the most widely accepted agile development practices, test-driven development and continuous integration, and question how these practices can be made better with continuous testing.
The hyper-productive teams we have observed apply high rates of practical collaboration. We believe that fostering Collaborative Interaction leads to increases in productivity, yet performance is recognized at the individual rather than team level. In environments where collaboration is required, managers should avoid assigning project work and accountability to individuals. Inappropriate rewards for individuals are additional distractions from their collaborative project duties.
Despite our best efforts we need to know what we are going to code before we write the code. And as much as we might like to test before we write the code we can't really run tests until we have some code. Agile overlaps requirements discovery and implementation so coding can start with minimal or outline requirements but there is still a sequence.
The following article is an excerpt from "Agile Testing" by Lisa Crispin and Janet Gregory.
When software development organizations implement agile development, the testing or QA team often takes the longest to make the transition. Independent QA teams have become entrenched in many organizations. When they start to adapt to a new agile organization, they encounter cultural differences that are difficult for them to accept. In Part II, we talk about introducing change and some of the barriers you might encounter when transitioning to agile. Training is a big part of what organizations making the transition need, and it's often forgotten. It's also hard to see how existing processes such as audits and process improvement frameworks will work in the agile environment. Going from an independent QA team to an integrated agile team is a huge change.