Don’t Be Perfect

By Cameron Laird

Nice #dev | Don’t Be Perfect

via Tordf

Tales from the trenches: Essential test case design

by Darren McMillan

Blogged: “Tales from the trenches: Essential test case design” #softwaretesting #qa #testing

Via darren_mcmillan 

Testers!! know your Business (& don’t do that of others!)

By Joel Montvelisky

Posted: Testers!! know your Business (& don’t do that of others!) based on feedback by @jerryweinberg to an old post

Via joelmonte

Agile Brings Changes to Key Roles and Responsibilities

By Dave Moran

Posted: Agile Brings Changes to Key Roles and Responsibilities #Agile #pmiagile

via wvanrheenen



Bug statistics are a waste of time

By Gojko Adzic

 new blog post: bug statistics are a waste of time #agile #testing

via gojkoadzic

Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks

By Mike Kuphal

Blogged: Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks #Scrum #Agile #PMOT
via mkuphal

Does ATDD = Waterfall?

By Adam Yuret

Fantastic post! RT @AdamYuret New post: Does #ATDD = Waterfall? #softwaretesting

via darren_mcmillan

Revisited – Test Strategy

By Fiona Charles

 Just published: Basics Revisited – Test Strategy & #testing #softwaretesting

via FionaCCharles

Testers are fixing bugs!

By Trish Khoo

 Blogged: Testers are fixing bugs!

via hogfish

A Fair Witness

By Pete Houghton

 Nice post RT @pete_houghton: New blog post “A Fair Witness” #testing #softwaretesting

via adampknight

I’m part of the ‘Now Generation’

By Ewald Roodenrijs

 New blog post “I’m part of the ‘Now Generation’”: #testing

via ewaldroodenrijs

Change Management

How do you manage changes in your project?

The change is one of the most difficult things to deal with during a project. There are many reasons for this, you don’t have extra resources, the project timeline can not change, the budget is short, etc.

Small changes are easy to do with a few or no impact in project delivery. But when the requested change applies to a behaviour already developed or being developed, the problem becomes serious.

Project managers have three things they can change during a project life cycle. When they got a request to change the scope there are only two ways to go: add Resources or delay delivery date.

How can they avoid having to take such decisions?

As an example, imagine you are working in a project to develop a web application to manage a Quality System. After planning the project manager should be able to give a Ready To Market date to the stakeholders. The first step is to Plan! Yes, this involves a lot of steps and it is not my point to discuss it now. But Change Management starts right here.

Suppose your project has six iterations (or sprints), the last two spent in stabilization (meaning no more code only bug fixing).  You probably start by defining the scope of the project,  the requirements, architecture and design before you start coding and testing. The more advanced in iterations you are the more difficult is to manage the change.

But we all know that changes can’t be avoided, unless you prefer to delivery a product that is no longer what the client wants.

Now suppose your team is already coding and you find out that an important feature was not planned. The reason could be a missed point in design. Suppose this feature will affect the code already written. Panic? No need.

In this scenario two things might happen. If you spent a good time in design iteration, considering all conditions, then the probability to occur the scenario described is very low. Otherwise, the probability rises. To be prepared to this you should consider some time in your planning to use in case of a scenario like this occurs.

There should be a balance between the time consumed in design and requirements definition and the time reserved for design failures. This depends on the complexity of the application, the expertise of designers and developers, the experience in similar projects, the available resources, and the project budget, among others.

By my experience some of these change requests will happen during testing phase. When testers start working they have a product to test, or part of it, and it’s easier to see things when you have a product in your hands. Developers didn’t look at it the same way. Another reason is the ability a tester has to see things as a developer and as a user, at the same time. This is why it is so important to involve testers in all phases of developing process. They are good allies to analysts and developers.

Now consider another scenario. During a presentation of the application the client decided to include a new feature, or change an existent one, but he needs to keep the RTM date. Will you work during night? How can you add this new feature if you don’t have more available resources?

It is important to give this to the client, otherwise he will get a product that isn’t exactly what he would like to have.

You may use the same strategy of the first scenario or you may improve it.

Before you start planning try to negotiate with your client a Box that he might use to add or change features, during the project development. The Box can be an amount of time, number of resources, number of features, extra iterations, number of code lines, anything that you both can measure. The client must be able to pay for this and you have to include this in your planning.

My advice is that you should expect changes because they will happen for sure.



Each team will be involved ...

I seat in my desk and start the day reading my e-mails: Team Project messages, Automation reports, meetings schedules, nothing urgent. I go to the coffee machine and drink my first coffee.
Today I have a new task, I’m excited about it. I will test a new Change Set (a Change Set is a group of new features, or changes to existing ones, and can be split up in smaller units; each iteration, or Sprint, has a different number of CS, depending on its size; a Sprint is about one month long).

I will start to read all requisites in detail. It’s not the first time I look at it, I’ve already heard a lot about and discussed about it in previous meetings.
When a new Change Set is created all teams start working on it immediately.

First, the Product Manager introduces his idea, describing the new functionality and explaining the high level requisites. After this we start estimating. Each Team Lead will work with her team to estimate the cost.

Teams committed are: Configuration Management, Release Management, Development, User Experience, Quality Assurance, Documentation and Platform System. Most of the times only one person per team will be involved and some teams might not be needed.

Then we are ready to start and some teams start first. The Product Manager works together with Testers and Programmers giving answers to open questions and defining all details. And so Programmers start analysis and Product Managers write low level requisites. As for Testers start planning tests and writing Test Cases.

I’m a Tester and I’m at this point right now.

My readings

Learning to say NO!

by Joel Montvelisky

Are you a YESaholic?

#QATips: Great post by @joelmonte – Learning to say NO! #softwaretesting #testing #qa

via jayphilips

Social Networking and the Test Industry

by Sean P. Morley

The impact of social networking on software testing – interesting  point of view.

RT @Rob_Lambert: Good post on social networks and testing : #testing #softwaretesting #qa

via rvansteenbergen

Exploring Rapid Reporter

by Zeger Van Hese

Are you looking for a tool to document your exploratory testing sessions?

Freshly pressed: “Exploring Rapid Reporter” #softwaretesting #testing (Thanks @sgershon for creating RapidReporter!)

via TestSideStory

Combinatorial Testing: Complex Interactions

by Bj Rollison

A close look at a testing technique.

New blog post in series on combinatorial #testing; complex interactions

via TestingMentor

Caution! Canned Test Planning

by Lynn McKee

Interesting analysis about using test planning templates.

RT @lynn_mckee: “Caution! Canned Test Planning” New blog post on the limitations of test planning templates – #testing #qa #templates

via  andreachiou

Performance testing in Agile environments

by HP

A useful white paper.

White paper: Performance #testing in Agile environments #in #softwaretesting

via mpkhosla


by Alan Page

Leadership is needed wherever you have a team – applies to the testing community too. Good blog post.

Leadership by Alan Page

via Lubaia