Good overview and analysis of Lollipop 5.0

Agile Net'Up

View original post

Advertisements

Some really useful observations made here, logical but often overlooked!

Technical Software Testing

It’s fairly safe to say that quite a lot of test automation efforts fail. It is also very safe to say that without test automation an agile team fails. So how can you make sure that while doing agile your test automation will not fail and thus your agile team will not fail? One of the ways to answer this question is by looking at why test automation often fails within agile environments.

When I am talking about test automation within this post, I am referring to testing that is done to reduce the amount of manual regression work, the so called functional test automation or automatic regression testing.

Moving target

Test automation quite often does not receive the attention it needs and deserves, also in agile teams. Quite some test automation efforts start off too late and without the appropriate preparation, resulting in organic test automation driven by a…

View original post 838 more words

If you have ever wondered which is the best smartphone OS to use then look no further than this article from Digital Trends which takes a look at the key wins for each of the Mobile OS.

The article covers many angles, and rates the OS accordingly in areas such as:

  • Affordability
  • Interface
  • Apps
  • App Store Usability
  • Battery Life
  • Updates
  • Cloud backups
  • Security

providing a balance view and highlights the key features in each section that the others provide in comparison. Though the article is behind in terms of the new releases of Apple, it still shows some useful analysis.

Through my work with Sogeti, and indeed through the promotion of the Sogeti Studio, our on-demand mobile lab, keeping up with the demand in the market place is a key challenge to ensure existing apps are compatible with the advances in devices and OS.

With the imminent release of iOS 8.1 due later this month and the suggested launch of Apple Pay; mobile decisions and utilisation of the features by businesses and app designers will provide another important rung on the mobile device market share ladder.

Good overview by Brian Wernham in his blog http://brianwernham.wordpress.com/2013/07/29/axelos-the-biggest-shake-up-in-project-management-good-practice-in-13-years/

More information available at http://axelos.gtml2.com/axeloslz/lz.aspx?p1=05735S1&CC&p=1&cID=0&cValue=1#building

And as outlined by Keith Richards (http://agilekrc.com) on day 1 of the Agile Business Conference in London, publications due for release in Q1 2015

Having worked in and around the testing industry for over 15 years, I have seen many changes in the World of testing. The importance of the tester over these years has gone through peaks and troughs. Potential business failures such as Y2K and the implementation of the Euro have seen companies invest heavily in “Career Testers”, paying increased salaries and bonuses to get the job done. Both Y2K and Euro had issues, but not the catastrophic impact that analysts predicted. The immediate aftermath of both events led to questions being raised around why testers were needed in such numbers and at such cost to projects.

That to and fro question continues, market events often play a big role in the answer to the question.

In more recent years, the popularity of agile, and in particular the rise of approaches such as TDD has raised the question of a testers value still further, with some companies relying on development led activity to provide the necessary quality. Other companies; such as Microsoft have invested in engineering roles for testers, or “Developers in Test”, people who can bridge the gap between testing and development.

So, with all these changes in approach, where does the humble tester sit? Do they become coders? Do they become business analysts? Some will, some won’t. Others may increase their skills by learning the basics of both in order that they can continue to contribute to ensure a development area covers the ‘what if’s’. We hear terms such as ‘Shift Left’, testers in this arena can still add value, static testing with respect to documentation or architecture diagrams will highlight risk areas and contribute to coverage models, environment management and performance strategies.

The technology World is becoming more service based, enterprise architects are looking at SOA services to provide efficiency. Testing is playing catch up again, defining a framework that provides optimal coverage of service calls is imperative, striking a balance between manual and automation coverage is key, supporting continuous integration is another way that testers can bring value back to the project life cycle. Complimenting development and business approaches, builds confidence and should contribute to companies meeting the business objectives around the cost, time and quality triangle.

But what if the tester doesn’t want to code? Doesn’t want to use automation frameworks? Well the digital age is here, and growing. The rise of consumerization in the market place is an important factor for companies when committing budget spend to projects. Consumers hold the key, demands for information to be displayed on multiple channels is leading companies to define their digital strategies. The technology race to bring newer and better wearable devices raises the question of consistency and quality again. Each device, whether static, mobile or wearable will need to portray consistent design and functionality to keep the consumer interested. Deviation in level of service will lead to the consumer voting with their feet (or fingers !) and move to a competitor.

Usability is key, device interaction and gesture support is vital to maintain market share. Can automation tools cover this? Not entirely, therefore the need for the humble tester is raised again, filling the gaps that automation frameworks cannot support, operating in an assurance role to keep products relevant and maintain consumer interest.

In short, the manual tester is dead, long live the manual tester !

Having spoken to various clients across various industries; there seems to be a general shift away from offshore test centres of excellence towards a more proximate solution. This is especially apparent with respect to mobile device testing. Companies want to call upon services, but don’t want to rely on ‘follow the sun approaches’.

Couple the instantly accessible device solutions with the experience of offshore partners and you have the foundation of a solution that covers the main elements of today’s society with respect to new device tests being performed onshore; with older; more unusual device configurations being performed by offshore partners; via a cloud solution.

With regard automation approaches, we are looking for frameworks that look at the multi-channel aspect of the digital transformation age.

Finding an automation framework that can be used across multiple devices, channels and browsers will provide stakeholders with great solace; as; in theory any expenditure in automation approach will result in greater ROI returns as, “one script fits all” across various desktop and mobile browsers.

Providing companies with a “script once” approach will be very appealing.

Tools and frameworks are trying to readdress the balance, providing efficiency in the framework space, but until verified; there will be the need for maintenance to ensure current framework is compatible.

However, for me the most important thing is that as testers, we need to be constantly innovating, and developing our skills. Technology is constantly changing and so must our testing methods, frameworks that limit maintenance and maximise channel coverage are a must; but the most important (for now) is that the individual must develop and keep pace with the ever changing technology landscape.

Wherever you go, whatever blog post you read, whatever company you do business with; there is likely to be a general journey theme when it comes to implementing agile; especially the transition from positivity through to surrender. “We are doing agile”; “my velocity is bigger than yours”, “I can’t believe our release is delayed because our downstream system isn’t agile”, “this agile thing sucks, it just doesn’t work, and now they want to use offshore”, “great, so now we death March every second week”, “my technical debt list is bigger than my backlog”.

Ok, so the last one I added a bit of poetic license to, but I think the point holds, at the outset of the bright new world, positive vibes and optimism are plentiful, as problems arise, if they are not dealt with, they escalate and confidence turns to confusion which leads to defeatism. This attitude isn’t an agile problem, it’s a standard project problem, if ‘risks and issues’ arise on a project they are managed or mitigated; in agile, the same holds true. For the purpose of this post, I’ll concentrate mainly on Scrum approaches

Let’s look at the statements outlined:

We are doing agile“are you sure? Asking the same three questions each morning, doesn’t mean you are “doing” Scrum (agile). How are you finding the journey, do all of your team members and sponsors understand the investment required in time and people to find the benefits of applying agile principles? Do they understand the role that each needs to play, especially during sprint planning and retrospectives?

“my velocity is bigger than yours” – great! So how are you using a backward looking measure to assist your future release train? How are you applying what you have learnt to road mapping the next set of features in the backlog?

I can’t believe our release is delayed because our downstream system isn’t agile” – is it really the downstream systems fault? Turn the situation round and ask “as a scrum team, why didn’t we understand our dependencies? Why didn’t we have an acceptance test that covered this integration? ” as a self organising team, each story that goes into a sprint needs to add business value, needs to have a clear objective (I.e the scrum team will agree what the expected sprint outcome is for a story, such that it will either demonstrate UI layout via the use of stubs or that it will be partly or fully integrated), needs to be technically feasible, has to be testable and needs to understand its dependencies. Having a project roadmap (the “Release Train”) will help visualise the technical priority, aligning development to fit with downstream or third party systems will keep the train moving, and allow stakeholders to apply pressure where necessary on suppliers to meet the demands of the train.

this agile thing sucks, it just doesn’t work, and now they want to use offshore” – again, does the scrum team and the stakeholders and sponsors understand the commitment required? What problems are being faced? Are the retrospectives being used effectively, to identify common problems in the approach, that can be tackled by the team to improve the collaboration and quality of the team? If these are addressed, what is the next area that “sucks”, continuous, manageable improvement builds confidence over widespread overhaul. In terms of offshore, what elements are being offshored? If it’s development, are the offshore team working in-sprint or are they feature based, complimenting the onshore development team; perhaps running a more Kanban; just in time approach, limiting the amount of work in progress to demonstrate progress? What about testers offshore? If we think about the obvious benefit and alignment to agile / scrum principles in terms of constant early feedback; utilising offshore resources means that developers create the nightly build, the offshore team test and feedback is available first thing when the developers arrive, they can fix and build and the onshore testers can retest and close the cycle down. Maybe the offshore team are focused on regression capability via automation, taking pressure off of the onshore team to focus on acceptance and collaboration? In short there are many ways to improve the approach, and find the approach that provides the benefits that the stakeholders envisaged when they decided to adopt agile.

great, so now we death March every second week” – if this is the case, we need to back to the sprint planning; what did we do wrong? Did we understand the complexity and dependencies? Was the product owner available to give us the insight; were the UX designs ready? What did we forget? For scrum to succeed, we need to manage the backlog and during the sprint not over burden through either underestimating or taking on too many stories; doing so will add to the technical debt either through “hacks” to get the function working or outstanding defects that cannot be fixed in sprint.

my technical debt list is bigger than my backlog” – following on from the last point, why are we building technical debt? How can we change? Is the technical debt related to new versions of development tools or architecture? Do we need to refactor the code to migrate new tools in order to achieve new business goals? If yes, then do we assign a technical sprint to refactor in order to kick on?

Only the team can decide ….. Well the team and the now fully educated stakeholders!