iOS 6 Recipes Is Out

January 11th, 2013 7 comments

Allright!

I’ve had this dream, for like ages, to become a published book author. Now I’ve done it. iOS 6 Recipes is out. (Actually, it’s been out since late november but I’ve been so exhausted that I haven’t been able to muster the energy to blog about it.)

iOS 6 Recipes is based on another book, iOS 5 Recipes, by Colin Francis and Shawn Grimes. My job was to upgrade that book with the new features of iOS 6, but as it turned out I had to rewrite most of the original content, keeping only the general structure and most of the old topics. I’m very proud of the result and although there are many ways in which it could still be improved, I belive I’ve accomplished the goal of producing a better book, valuable to its readers.

But I couldn’t have pulled this off if it wasn’t for the fantastic team at Apress, especially Anamika Panchoo (Coordinating Editor), Anselm Bradford (Technical Rewiever), Douglas Pundick (Developmental Editor) and Linda Seifert (Copy Editor).

If you’ve read iOS 6 Recipes and want to share your thoughts, or ask me questions, feel free to contact me, either through the comments here or by emailing me (you’ll find my email address in the book).

Cheers!

Categories: Anouncements, books Tags: , ,

New XCode Tutorial: Turning View-based Into Navigation-based

September 30th, 2011 No comments

The other day I started a new iPhone project to create an app that I had been thinking about for quite some time now. I meant to build a Navigation-based app, but for some reason I used the general View-based application template to create my project.

Nemas problemas – I thought – transforming it into a Navigation-based project should be simple enough. Call me stupid, or stubborn, but what seemed like an easy task took me the better part of a day to achieve; XCode can be very unintuitive some times, and the error messages not very helpful :-)

Anyway, I thought I’d better put my achievement down in writing in case some of you out there will have the same need one day. Then maybe you’ll thank me for writing the Turning View-base into Navigation-based  tutorial.

Cheers!

Categories: programming Tags: ,

New Tutorial: Getting Started With UISpec on XCode 4

July 8th, 2011 No comments

One of the most popular pages on this website is the tutorial that helps you getting started with UISpec; i guess there’s a great demand for acceptance testing frameworks on Objective-C.

Anyway, I have just made a switch from XCode 3 to XCode 4, a huge improvement. A lot has changed in the user interface so I decided to upgrade the UISpec tutorial, but kept the old one in case someone prefer the old IDE:

Cheers!

Incremental Development and Regression Testing Paper Released

May 17th, 2011 1 comment

As you might know I wrote about the regression testing problem in The Swamp of Regression Testing. One of the commenters of that post, Ricky Clarkson, thought that the extensive use of the agile word got in the way of the underlying message.

I’d love to see a copy of this article without “if you don’t do X, you won’t be agile”, because where I work, agile isn’t a goal, but quality and quick turnaround is. If I passed this around, the word ‘agile’ would get in the way of an otherwise great message.

That made so much sense that I decided to do just that. I wrote a new version, a complete rework of the original post, and published it as a separate document so that it can be easily passed around.

You find it under Shared Stuff on my website, or by following the below link.

Incremental Development and Regression Testing (PDF)

Please don’t hesitate to contact me if you have any feedback to share.

Cheers!

Categories: Anouncements, software development Tags:

Up and Running Again

March 8th, 2011 1 comment

Last weekend the server that hosted this website went flat line. At first I feared I’d face a severe data loss much like the one Jeff Atwood experienced last year; For one thing, my current backup strategy doesn’t include uploaded images.

Fortunately the good people of Joyent, whose service I can really recommend, have worked hard to restore the website. It should now be fully functioning.

Now I need to work on my backup implementation. Maybe you should too?

Cheers!

Categories: blogging Tags:

Automatic Acceptance Testing for iPhone

February 23rd, 2011 No comments

I’ve been playing around with XCode and iOS SDK lately, particularely with various alternatives for achieving automatic acceptance testing. (Which I belive is the only long-term solution to fight The Regression Testing problem.)

One of the most promising solutions I’ve found is UISpec, modeled after Ruby’s mighty popular RSpec. Even though it still feels a bit rough cut, UISpec provides an easy way to write tests that invoke your application’s user interface; no recording, just plain Objective-C.

Anyway, in case you’re interested, I published a tutorial on how to set UISpec up for your project: Getting Started With UISpec.

Categories: software development, test-driven Tags:

Steve and Nat: Encapsulate Generics

February 21st, 2011 No comments

I’m reading Growing Object-Oriented Software, Guided by Tests, by Steve Freeman and Nat Pryce. I was happy to find that the authors share a similar view on constructed generic types as I do.

Our rule of thumb is that we try to limit passing around types with generics [...]. Particularly when applied to collections, we view it as a form of duplication. It’s a hint that there’s a domain concept that should be extracted into a type.

A less blunt way of saying what I tried to say in my own post.

If you’re interested in the book I can strongly recommend it. Although I’m only half-way through it I can already tell it’s the best TDD book I have read so far. I’ll have a brief review up in a coming post.

Cheers!

Categories: books, Comment, programming Tags:

The First Rule of Holes

January 26th, 2011 7 comments

We don't have time for reevaluation. Keep digging!

At some point someone made a promise. Now the team is in a bad position and struggling hard to meet the deadlines of the original plan.

I’ve been in that position more than once, and as a Scrum Master I have used the same strategy:

  1. Working with the customer to lower expectations and make the plan more aligned with reality.
  2. Find more time for the team to do its work.

The second part would make me cancel everything not immediately helping the team accomplishing its short-term goals. The retrospective meetings were always the first thing that went out the window, and I felt like I was helping the team by doing it.

That was before the first rule of holes was brought to my attention (by Henrik Kniberg).

The first rule of holes: When you’re in one stop digging.

That wonderful quote by Molly Ivins really got me thinking. To bring a derailed train back on track, the solution is not to make the engines run faster. Instead we need to make a careful evaluation of the situation, and find solutions that will help us achieve the end goal of getting the passengers and cargo reach its destination on time.

In software development terms, when the going gets tough, we need our retrospectives the most.

Another way I’ve violated the first rule of holes is the thing I wrote about in my previous post. Although I know that automated tests is one of the best ways to increase productivity, I came up with all sorts of excuses why “it wasn’t for us”. So, I’ve let my teams dig deeper holes and making a bad situation worse.

Yet another common violation is the building up of technical debt. We’re so busy digging for new features that we forget that we have to be able to ascend from the pit. We need to stop digging and clean the small messes before they become drainers of effort.

What holes have you created or ended up in? What did you do about it? I’d love to hear your stories.

Cheers!

Categories: learning, project management Tags:

The Swamp of Regression Testing

January 17th, 2011 14 comments
Have you ever read a call for automation of acceptance testing? Did you find the idea really compelling but then came to the conclusion that it was too steep a mountain for your team to climb, that you weren’t in a position to be able to make it happen? Maybe you gave it a half-hearted try that you were forced to abandon when the team was pressured to deliver “business value”? Then chances are, like me, you heard but didn’t really listen.
You must automate your acceptance testing!

Why? Because otherwise you’re bound to get bogged down by the swamp of regression testing.

Regression Testing in Incremental Development

Suppose we’re building a system using a traditional method; We design it, build it and then test it – in that order. For the sake of simplicity assume that the effort of acceptance testing the system is illustrated by the box below.

Box depicting a specified system

The amount of acceptance testing using a traditional approach

Now, suppose we’re creating the same system using an agile approach; Instead of building it all in one chunk we develop the system incrementally, for instance in three iterations.

The system is divided into parts (in this example three parts: A, B and C).

An agile approach. The system is developed in increments.

New functionality is added with each iteration

Potential Releasability

Now, since we’re “agile”, acceptance testing the new functionality after each iteration is not enough. To ensure “potential releasability” for our system increments, we also need to check all previously added functionality so that we didn’t accidentally break anything we’ve already built. Test people call this regression testing.

Can you spot the problem? Incremental development requires more testing. A lot more testing. For our three iteration big  example, twice as much testing.

The theoretical amount of acceptance testing using an agile approach and three iterations, is twice as much as in Waterfall

Unfortunately, it’s even worse than that. The amount of acceptance testing increases exponentially with the number of increments. Five iterations requires three times the amount of testing, nine requires five times, and so on.

The amount of acceptance testing increase rapidly with the number of increments.

This is the reason many agile teams lose velocity as they go, either by yielding to an increasing burden of test (if they do what they should) or by spending an increasing amount of time fixing bugs that cost more to fix since they’re discovered late. (Which is the symptom of an inadequately tested system.)

A Negative Force

Of course, this heavily simplified model of acceptance testing is full of flaws. For example:

  • The nature of acceptance testing in a Waterfall method is very different from the acceptance testing in agile. (One might say though that the Waterfall hides behind a false assumption (that all will go well) which looks good in plans but becomes ugly in reality).
  • One can’t compare initial acceptance testing of newly implemented features, with regression testing of the same features. The former is real testing, while the second is more like checking. (By the way, read this interesting discussion on the difference of testing and checking: Which end of the horse.)

Still, I think it’s safe to say that there is a force working against us, a force that gets greater with time. The burden of regression testing challenges any team doing incremental development.

So, should we drop the whole agile thing and run for the nearest waterfall? Of course not! We still want to build the right system. And finding that out last is not an option.

The system we want is never the system we thought we wanted.

OK, but can’t we just skip the regression testing? In practice, this is what many teams do. But it’s not a good idea. Because around The Swamp of Regression Testing lies The Forest of Poor Quality. We don’t want to go there. It’s an unpleasant and unpredictable place to be.

We really need to face the swamp. Otherwise, how can we be potentially releasable?

The only real solution is to automate testing. And I’m not talking about unit testing here. Unit testing is great but has a different purpose: Unit-testing verifies that the code does what you designed it to do. Acceptance testing on the other hand verifies that our code does what the customer (or product owner, please use your favorite word for the one that pays for the stuff you build) asked for. That’s what we need to test to achieve potential releasability.

So, get out there and find a way to automate your acceptance testing. Because if you don’t, you can’t be agile.

Cheers!

Benefits From a Software Testing Job

January 12th, 2011 No comments

This is a guest post by Janet J. Fleming.

Are You Going to Get Benefits from a Software Program Testing Job?
 
This is a good question….initially you must see if you have a certain type of personality to accomplish software testing. You ought to be organized, logical and thorough. You will be writing test cases depending on business and functional requirements – or in other words you should do. 
 
Then you’ve to implement those tests – often repeatedly. Your primary goal is always to be sure that no software goes out to your customer without all the bugs found. It’s rarely achievable, but should be your main goal. I always prefer to believe that your 2nd goal must be to have every developer hate you because you keep finding bugs inside their code :)
 
The answer if software testing is an excellent career option is dependent upon who’s asking the question. I’ll answer it as if my audience is definitely an engineer.
 
I’m flip, but sincere – my working practical experience has proven to me that the theory of software development never comes about in reality.
 
Theoretically, software testing is:
– Validating and recording that software program performs the functions it’s supposed to.
– Making sure and recording it doesn’t do anything whatsoever it is not designed to
 
This presupposes you have been told what it is supposed and not supposed to do. People you’re working for don’t always do this – they might not necessarily rely on you not to run away with their secrets.
 
Because software program is a business (except when you are doing work for the military) business guidelines apply a lot more strongly than engineering principles. Software testing is expensive, and so the decisions about goals and how much to do can be extremely based on ROI considerations.
 
Inside the end-user relationship, the user’s perception just isn’t necessarily directly related to the physical world, and it’s also the user’s perception of whether your system works that finally rules inside the minds of management, whose job is purely to ensure no one is complaining concerning the software.
 
Therefore, the truly practical explanation of software testing could be summarized as 3 goals:
 
1° Verify the people that use software believes it’s doing whatever they require it to accomplish
 
2° Verify that this software doesn’t do anything immediately detectable that is not desirable for the user.
 
3° Verify that any undesirable action has a sufficient length period that the software will look to perform properly long enough for you to make it to another round of VC investment or sell the business :) 
 
And you? Do you consider Software Testing could be the right career path?

Who am I ?: Janet J. Fleming is writing for the software testing course online blog, her personal and non-commercial in nature hobby web site to offer free strategies for software testing novices/specialists to help them get a new work.

Categories: guest posts, testing Tags: