SOGETI UK BLOG

Agile

Image credit : Lynne Cazaly. Provided by Mediashift.

Agile development is clearly a growing trend. It’s positive impact on time to market and customer satisfaction make no doubt. However, involving off/near shore teams is a challenge. Some key success factors of effective agile developments are:

  • Frequent interactions between team members
  • High visibility of the tasks to complete (by using Kanban for example)
  • Simplified process allowing frequent deliveries

The question is : “How can I apply these KSF with my distant teams?”

Here are some ideas I tested with my own teams or shared by scrum masters I worked with:

  1. Identify the agility awareness of the offshore team: Do they know the main principles? Are they willing to change their way of working? If not, you can start with trainings.
  2. Identify your current communication means: calls/videos/e-mails? If your team members are mostly communicating using e-mails, then you should try to have people talking together.An introduction of each team member during a video conference could be a good start.An event during which team members would meet each other would be even better, and a good investment for the future: people tend to collaborate more if they know the recipients of their e-mails/calls.
  3. Identify the tools you can use to increase communication and visibility of the tasks: JIRA + Greenhopper can definitely help. But if you’re creative you can also find easy solutions: both teams may have their Kanban and send a daily picture of the current situation.
  4. Optimize your processes to increase time to market and make sure all teams are aware of the expectations and dependencies on each side.
  5. Ensure difficulties/blocking points of each team can be identified and shared to find global solutions. Retrospectives are helpful and should be conducted wherever you are located. Any issue slowing the deployment process down should be addressed with high priority.

But don’t forget that each Agile team has to find the solutions best suited to its way of working. So my main advice would be to  address this point during retrospectives and help the team proposing its own solutions. The acceptance and commitment will be much higher.

 

Lionel Matthey AUTHOR:
Lionel Matthey has been Senior Consultant for Sogeti Group since 2012. In this role, he is responsible for delivering Testing and Project management services to our clients. He is also in charge of the research on good practices about agile testing. Several knowledge sharing sessions have already been organized to present the result of his studies and practical examples of the lessons he learnt in Swiss banks. Lionel is also involved in the preparation of answers to clients’ service requests about testing (RFPs, RFIs…). Previously, he worked for other IT consulting firms as Test Manager, Business Analyst or Project Manager. In 2007, after a few months of testing automation, Lionel moved to Zurich to take over the management of the tests on a large project at UBS. He later came back in the French speaking part of Switzerland to strengthen his skills on many aspects of testing at different clients like Orange, Rolex, Givaudan or Nestlé. In 2010 Lionel accepted the position of Project Manager/Scrum Master on Nestlé’s third and largest agile Project at that time.

Posted in: Behaviour Driven Development, communication, Data structure, Human Behaviour, Human Interaction Testing, Infrastructure, Research, Scrum, test data management, Test Driven Development, Transformation      
Comments: 0
Tags: , , , , , , , , ,

 

usability-testingThis question may sound simple, but it isn’t. Over the last few years, I’ve noticed that more and more User eXperience Experts (UX) are getting involved in IT projects. This is definitely a growing trend: Expectations regarding usability are increasing, especially due to the soaring popularity of mobile applications. In fact, users now want to understand how a tool is working without reading any user guide.

Usability is part of the non-functional requirements. This means, it has to be tested and validated as any other requirement. However, UX best practices are usually not part of a tester’s technical skill set. So, how can we ensure high quality, even on the usability side?

Basically there are three options:

  1. Asking the UX expert to do the testing and to validate the usability requirements
  2. Asking the testers to take care of these tests based on UX recommendations, the style guide or any other documentation
  3. Combining points 1. and 2.

 

Point 1. may be a good option, however the UX expert usually can’t find enough time to validate all the graphical interfaces during a release. In addition, he/she isn’t always familiar with advanced testing principles.

Point 2. should be avoided: All usability concepts can hardly be described in documentations. Usually, the UX expert has to “play” with the graphical interfaces to see if the new requirements are matched or not. This kind of assessment shouldn’t be done by the tester to prevent any conflicts with developers or with the UX expert.

So there is only solution left: number three! And, it is the best one. Indeed, part of the basic UX concepts can be described efficiently in specifications. The validation of these ones can be transferred to a tester after a quick knowledge transfer with the UX expert. We are talking here about the main style guide rules, which should be part of the non-regression tests.

By transferring these validation tasks to the Testers, the UX expert will have more time to validate the new developments or complex interfaces. The best is to follow a shift left approach and to involve the UX expert as early as possible in the project. I recommend to conduct quick reviews of the new developments directly on the developer’s station and to involve the UX expert during the next validation phases (FAT, UAT).

This way you will ensure that your application is aligned with the requirements described in the style guide and your UX expert will have enough time to validate the usability of the new developments.

To read the original post and add comments, please visit the SogetiLabs blog: Is your application usable?

Related Posts:

  1. Everybody tests with Agile
  2. Back to the future … of Testing!
  3. What are the best practices for improving the quality of an application?
  4. Seven Best Practices for Salesforce Validation Rules

Lionel Matthey AUTHOR:
Lionel Matthey has been Senior Consultant for Sogeti Group since 2012. In this role, he is responsible for delivering Testing and Project management services to our clients. He is also in charge of the research on good practices about agile testing. Several knowledge sharing sessions have already been organized to present the result of his studies and practical examples of the lessons he learnt in Swiss banks. Lionel is also involved in the preparation of answers to clients’ service requests about testing (RFPs, RFIs…). Previously, he worked for other IT consulting firms as Test Manager, Business Analyst or Project Manager. In 2007, after a few months of testing automation, Lionel moved to Zurich to take over the management of the tests on a large project at UBS. He later came back in the French speaking part of Switzerland to strengthen his skills on many aspects of testing at different clients like Orange, Rolex, Givaudan or Nestlé. In 2010 Lionel accepted the position of Project Manager/Scrum Master on Nestlé’s third and largest agile Project at that time.

Posted in: Application Lifecycle Management, Behaviour Driven Development, Big data, Business Intelligence, Developers, IT strategy, Opinion, Rapid Application Development, Technical Testing, Technology Outlook      
Comments: 0
Tags: , , , , , ,

 

Image credit: sqasolution.comPeople who have worked on Agile projects before would have probably noticed or heard this: Agile projects require… agility! But again, agility can mean several things. Of course, it involves following an iterative process, responding to changes, improving time to market and many other important aspects.

However, what people often don’t realise when joining an Agile team is that their usual duties will change. Indeed, with waterfall, each activity is clearly identified and segregated: A business analyst will gather requirements from its customers. Then, he/she will transform them into specifications and forward the documents to the developers. The developers on their side will build the solution from the specifications and deliver them to the testers, who in turn will validate the deliverables with the involvement of users/customers.

In Agile development lifecycles, activities and roles are more mixed up. Particularly in Testing, everybody (more or less) has to test! The main reason is to meet the objective of time to market improvement. If you want to deliver new functionalities, right at the end of the iteration, you will have to shorten testing periods as much as possible. And, as customers won’t sacrifice quality, you’ll have to modify the way you test to ensure quality is monitored and controlled during the whole product lifecycle. This requires business analysts, developers and customers to participate in the testing of the deliverables. Nevertheless, they will execute tests at different levels and different times.

First, it is essential that developers run unit tests (manual and automated) of their developments. If not, the number of defects found later in the process will be too high to allow a quick release. A good set of integration tests is also necessary to allow frequent and reliable deliveries. Once new functionalities are deployed in a quality environment, smoke tests can be executed by the tester, either manually or by running scripts. Then, if the quality is satisfactory, the validation process can start:

  • – The business analysts will start verifying what they specified to be actually available
  • – The testers will perform advanced tests (functional, performance, limits, etc.)
  • – The customers will execute the acceptance tests to confirm that the deliverables are aligned with their requirements

This raises some challenges about defects/tests duplicates and detailed planning of who does what and when. These areas will be addressed in my next article.

However, it cannot be denied that, the “everybody tests” approach strongly improves the time to market without compromising quality. It can definitely help optimise your project while increasing agility benefits.

To read the original post and add comments, please visit the SogetiLabs blog: Everybody tests with Agile

Related Posts:

  1. Agile (testing) – the final solution?
  2. Our Top 10 2014: Agile-Testers as the Trojan Horse in Traditional Development Projects!
  3. Agile Test Improvement: contradiction or two sides of a coin?
  4. Agile-Testers as the Trojan Horse in Traditional Development Projects!

Lionel Matthey AUTHOR:
Lionel Matthey has been Senior Consultant for Sogeti Group since 2012. In this role, he is responsible for delivering Testing and Project management services to our clients. He is also in charge of the research on good practices about agile testing. Several knowledge sharing sessions have already been organized to present the result of his studies and practical examples of the lessons he learnt in Swiss banks. Lionel is also involved in the preparation of answers to clients’ service requests about testing (RFPs, RFIs…). Previously, he worked for other IT consulting firms as Test Manager, Business Analyst or Project Manager. In 2007, after a few months of testing automation, Lionel moved to Zurich to take over the management of the tests on a large project at UBS. He later came back in the French speaking part of Switzerland to strengthen his skills on many aspects of testing at different clients like Orange, Rolex, Givaudan or Nestlé. In 2010 Lionel accepted the position of Project Manager/Scrum Master on Nestlé’s third and largest agile Project at that time.

Posted in: Business Intelligence, communication, Developers, functional testing, waterfall      
Comments: 0
Tags: , , ,