The Agile Tribe

The Quick and The Dead…………….

Author:David Greenless

In the ever changing world of IT it’s extremely important to stay on top of things.  To be successful at almost everything these days you need to ‘hit the ground running’.

It’s fair to say that the above is common understanding.  But what tasks do you undertake to achieve it?

It is especially important in the world of consulting… multiple projects, multiple clients, and an even greater need to avoid failure!

I think it’s even more important in the world of software testing consulting.  By nature we (software testing consultants) are called in towards the end of the project…

It may be behind schedule, or perhaps testing was an after thought (shock, horror… but it still happens).  Whatever the reason may be, it tends to happen quite frequently.  This leaves us very little time to gain the amount of knowledge required to introduce a successful quality control such as testing.  All of this and I haven’t even begun to think about entering an agile environment.

Does this make it even more important again?  By nature, true agile environments are fast paced so I would think it does.

Below is a small sample of the things I like to do which assist me to ‘get up to speed’ in a timeframe that suits the context and level of my engagement (in no particular order):

  •  Exploration – I find this is key, especially when engaged at the analyst level.  I find it very handy to request access to the applications/s under test (even if read only to begin with) and just get in there and dig around.  Take a tour of the application/s and note key areas/function points as you go and try some of the more common scenarios or use cases.  This will give you a great understanding even if only visual.  There will be many occasions when you attend meetings, etc. where the participants are talking about the application/s and you’d be surprised how much easier it will be to follow the discussion if you can visualise the areas they are talking about.  Michael Bolton wrote a cracker of a blog here, (http://www.developsense.com/blog/2009/04/of-testing-tours-and-dashboards/) and also take a look at the comments, specifically Cem Kaner’s.
  • Meetings – Schedule new ones, attend existing ones.  When you’re new to an organisation or a project you’ll normally find that introductory meetings are booked, however if not then book away!  Putting a face to a name is vital and will help you understand where you can go if you need a question answered (we can’t know it all unfortunately).  I also find it useful to attend existing meetings that would not normally be attended by your role.  Even if it is simply a one off in the first week or so, it will give you a greater level of understanding and a better appreciation of what others are facing.  This is often met with confusion by the meeting chair when requested, but nine times out of ten they will actually be all for it once explained.
  • Interviews – This does depend greatly on the level of your engagement, however one on one interviews are a great way of getting individual perspectives on project progress, team morale, etc.  Ask each of the Test Analysts how they feel about the application or what they think the biggest benefit will be from the new system, etc, etc.  You’ll discover many differing opinions which will assist in guiding your approach.
  • Reading – This one goes without saying.  On most occasions there will be hundreds of pages of reading… project documentation, organisational procedures, training, etc, etc.  Fitting all of this in is a big task.  Instead of simply reading everything I’ll usually ask the right person (whomever that may be) what I need to concentrate on, and what I can skim over.  Take a risk based approach like you would for testing.  We’ve all heard of exhaustive testing and how in real world contexts it’s not possible?  Well exhaustive reading isn’t either, not when the deadline is knocking on your door!
  • Build Relationships – I cannot stress enough how important this is!  Everyone does this differently, and your focus needs to be different depending on the type of relationship you’re trying to build.  Maybe you need to get on the developers side because you can see straight away there are going to be a large amount of bugs, or you’re going to need their help in developing stubs… maybe the architect because they know the business and technology layout like the back of their hands and will be able to answer any question you may have.  Whatever the need, get in early and build!  If you can identify with the ‘go to’ person in the initial few weeks, then things will be much easier for you.

Read the rest of this entry »

Advertisements
2 Comments »

The Evolution of Test Driven Developers

Author: Peter Sellars (Reprinted with thanks to Peter)

Evolution

Test Driven Development (TDD) since its rediscovery by Kent Beck in the early noughties has led to an evolution in the information technology developers of our species. So where on the test driven developer evolutionary tree do you or your developer kind sit?
Read the rest of this entry »

Leave a comment »

The Agile Journey – a Testing Experience!

Author: Kate Ellery

It’s quite hard to believe that a couple of years ago we were thinking “what’s this new fandangle ‘Agile’ thing they’re trying to push on us?”!!! And how far we have come since. Ask anyone in the team now if they’d ever go back to traditional waterfall projects… boy, if looks could kill!

In testing, we have certainly had many challenges. And we’re still perfecting some of our processes and tools, but looking back, we have come a long way since Agile was an unknown phenomenon!

Areas of Vast Improvement

  • Testers are being involved at the start of projects, instead of coming in when the first iteration is starting;
  • Acceptance criteria is being written against user stories by the entire team (often this was written solely by our Business Analysts), ensuring a common (and accurate) understanding of each story;
  • Collaboration and communication with Business Analysts and Developers has greatly improved, with all team members taking accountability for project tasks;
  • New automated testing processes – what we are actually automating, where we are automating (UI, functional code, shared services), and the tools we use;
  • Co-location – project teams seated together to encourage active collaboration within teams, ensuring any issues or changes are communicated to all as they happen, rather than finding out about them too late down the track;
  • We find that fewer defects are logged, due to the acceptance criteria being used for unit testing – the story must pass this criteria before the card moving to ‘in testing’.

However, this does not mean that we are perfect (yet!). There are some areas where we still struggle. We find the monthly brown bag videoconference sessions with other testing teams around the company beneficial to discuss some of our issues, and learn from others’ experiences.

Areas where we still face Challenges (with a capital “C”)

  • Time – fitting all the testing tasks into each iteration; the main tasks being – test execution (system, functional, integration & regression testing across several environments), planning for the next sprint, automated testing;
  • Meetings meetings meetings!– daily stand-ups, showcases, retrospectives, planning sessions – all very important, but they all take up our “maker’s time”;
    and
  • Getting one project finished before the next starts – we have a 6 week warranty period where the project team supports any production issues, which can eat into the new project tasks.

On the whole though, we all enjoy Agile and our testing team has become a busier, but happier team who are more supportive to each other, as well as supporting other roles in and outsdie the core team. We also feel more appreciated by our team members, as there is a better understanding of what each role does within each project which has resulted in a greater respect for each other as well.

3 Comments »

Let's start at the beginning – Testing and Agile

Author: Ben Arnott

Some random learnings from my experience of testing in an Agile environment –

  1. Quality is everyone’s responsibility
  2. Grey the lines of Developers and Testers
  3. Job titles don’t mean jack… it’s the role you play that counts
  4. NO MORE MINI WATERFALLS!
  5. Less focus on Defect detection rates and on quick to market software
  6. Advertise the “Sliders” and adhere to them
  7. Don’t be afraid to change the sliders, but make sure they are communicated
  8. Testers make great Interation Managers
  9. Automation isn’t a silver bullet, it is complimentary
  10. Tester and Tester pairing is great
  11. Tester and Developer pairing is great
  12. Tester and Subject Matter Expert (SME pairing) is great
  13. 80% of the Testing Effort is at the time of card elaboration
  14. Co-Locate wherever possible!
  15. If you are more than 10 metres away from a team member, you are NOT co-located
  16. It’s “Done” when it’s tested successfully
  17. Integrate Code Continuously and Continuously test integrated code.
  18. If Quality isn’t your number one slider… mitigate!
  19. If you smell a smell raise it
  20. If someone raises a smell, investigate
  21. Ask Why
  22. Ask Why again
  23. Communicate all changes with the entire project.
Leave a comment »