Global Team

On November 9, I’ll be hosting the Agile XXL: Scaling Agile for Project Teams webinar. I haven’t ironed out the details of this webinar yet, but thought it would be good to write a primer for the event.  While I have been practicing many Agile techniques on large, distributed projects since 2002, I didn’t start formally putting them together as a collection of practices in the form of Agile projects until 2007.  It was in 2007 that I say my Agile journey and passion for Agile software development officially began. Since then, helping organizations adopt Agile practices for large and/or distributed project teams has been of particular interest to me because most of my clients have fit into the category. Let’s take a look at some numbers.

Continue reading…

Thanks to everyone who joined us for the Requirements and Agile: Keeping up with Change webinar. If you missed the event, take some time to watch the Requirements and Agile: Keeping up with Change recorded webinar. Attendees asked several interesting questions, all of which we weren’t able to address during the webinar. To follow up, and invite others to participate, we’ve included the Q&A below.

Continue reading…

Requirements or user stories? Why not both? Attend our Requirements and Agile: Keeping up with Change webinar on October 4, at 1 p.m., to learn how to minimize gaps in verification and validation practices sometimes seen when using Agile methodologies. These gaps are typically a result of moving away from formal requirements in favor of user stories, which are quicker to develop but typically not as rigorously defined.  Continue reading…

Thanks to everyone who joined us for the Measuring Technical Debt with Load Testing webinar. If you missed the event, take some time to watch the Measuring Technical Debt with Load Testing recorded webinar. Attendees asked several interesting questions, all of which we weren’t able to address during the webinar. To follow up, and invite others to participate, we’ve included a complete Q&A below.

Thanks to everyone who joined us for the final webinar our TDD 101 Learning Series. If you missed the event, take about 30 minutes to watch the Beginning Test-Driven Development in a Legacy System recorded webinar.

If you missed either of the prior webinars, or want to brush up on your knowledge of test-driven development, browse to Learn Test-Driven Development at TDD 101.

Thanks to everyone who joined us for the second event in our TDD 101 Learning Series. If you missed the event, take about 25 minutes to watch the Writing Good Unit Tests recorded webinar. Attendees asked several interesting questions, all of which we weren’t able to address during the webinar. To follow up, and invite others to participate, we’ve included a complete Q&A below.

Writing Good Unit Tests Q&A

How do you start adding unit tests for existing code, which may not have been originally written with unit tests in mind?

The next webinar is Beginning Test-Driven Development in a Legacy System, and I’ll be covering this topic in much more detail. Even if you are just looking at unit tests, the next webinar should be helpful. The basic idea is that you’re going to have to refactor and there are quite a few tips and tricks you can use to reduce effort and boost results. Anything you touch should be refactored so that you can write unit tests. It can be daunting, so start small!

How can a unit test NOT depend on the interface of the unit it’s testing?

It is going to depend somewhat on the interface but you really don’t want it to be too heavily dependent. For example, if I have fifty places in fifty different unit tests where I am creating an object and then calling five methods on each to further initialize the object, I am really dependent on that interface. If any of those methods changes, I am going to have a lot of find/replace work to do. When you realize that you’ve got a lot of duplications in your unit tests, just like within code when you’re coding, that’s a great opportunity to go ahead and pull that logic out into one centralized place. For example, put the five function calls that initialize the object into a constructor that can be called once. If the interface changes, you just have one place (the constructor) to update and you’re all set to continue running your unit tests.

Continue reading…

Thanks to everyone who joined us for the first event in our TDD 101 Learning Series. If you missed the event, take 20 minutes to watch the Intro to TDD recording. We had some great attendees who asked several interesting conversations, all of which we weren’t able to address during the event. To follow up, and invite others to participate, we’ve included a complete Q&A below.

Intro to TDD Q&A

Who writes and owns unit tests—the development team or the test/QA team?

TDD is a programming technique, so the development team writes and owns the unit tests.

How can I measure the quality of unit tests?

The real quality of the unit tests can only be observed over time. Do the tests uncover issues during development instead of during testing? Do the unit tests define the correct behavior? Are there unit tests that test good data, bad data, and invalid/null data? Make sure you attend our next TDD webinar, Writing Good Unit Tests, on July 13 for more information.

Can we use TDD for code coverage? Or does the test team need to invest time in automation for code coverage?

The goal of TDD is clean code that works. A side effect of TDD is a high percentage of code coverage. Theoretically, if you write a unit test for every change, then you should have 100% code coverage, even though that’s not the goal of TDD. If you have a code coverage goal, you’ll still need a tool to examine the code coverage. If code coverage isn’t at your goal then you will need to add additional tests or work with development to determine why there are changes without unit tests.

Continue reading…

Last chance to join—Seapine’s TDD 101 webinar series starts on Wednesday! In case you haven’t heard, our latest webinar series is targeted at helping you improve your test-driven development skills. The series is being led by Katie Dwyer, who is an Agile Services Consultant in Seapine’s Agile Services group.

Katie is going to cover the following core topics over the course of three classes.

1. Intro to Test-Driven Development
2. Writing Good Unit Tests
3. Beginning TDD in a Legacy System

BONUS: If you’re not able to commit time to attending the free classes, download our new TDD Reference Card to help you start using TDD effectively.

Thanks to everyone who joined us for our Take the Pain out of Test Case Management webinar. The recording is now available on YouTube if you missed the webinar or want to watch it again.  It is also available on SlideShare if you want to view or download the slide deck. Q&A from the session follows.

As projects grow in scope, both testing complexity and demands on the testing team increase. Homegrown methods for managing those tests start letting you down. Even as you spend more time managing individual tests, it becomes clear that you’ve lost track of the larger picture—what the results of your testing mean for the quality of your software and the efficiency of your testing program.

Continue reading…