Sunday, August 24, 2014

Agile or Traditional is not just your preference

Many of us have been through mainstream both types of development: traditional and Agile. I am not going to speculate on which one is best because no one but you can answer this question with due probability. The choice depends on many parameters that no one can advise you on. In short, Agile works best in the situation of volatile requirements whereas traditional shows better results backed by steady specifications.

Still many people try to use Agile in all cases, mostly because it is "more fun to do". Well, if it was about having fun we would probably spend our time riding a roller-coaster rather that sitting in our offices. So it is not about fun you get in the process, it is rather about the fun we get successfully launching the system, seeing it doing something useful and helpful. This is the kind of fun that I personally prefer.

The road to this goal itself is also important but as much as it does not compromise the goal itself. For example, choosing Agile for a mission-critical system may become fun in development but a huge frustration in the end. The devastating effect will be so big that you would not remember a minute of fun you have had in the process.

Agile is definitely attractive to the developers because it allows to jump into the coding not bothering doing boring routine work. It allows to skip the hardest efforts such as trying to think ahead, measure risks and probabilities. But it comes at the cost of missing important aspects of system design or requirements which will be hard to add on later, when the shortage is revealed. So be flexible. It is good to have more then one tool if conditions change.

Quick turnover cycles also attract stakeholders. They can see results quicker and try out the system earlier. It enables them making corrections if their understanding of the business processes was not optimal. Which in turns makes unsteady requirements even more volatile and Agile even more efficient. But this is only in theory. The reality is more complex as stakeholders fail to understand what it takes sometimes to convert a prototype into a production solution. It may not be easy to convince your boss that the system that he can see working is not ready to be released after few fixes. You must be prepared and keep delivering the message about what they see consistently. Otherwise you have a big chance to lose this battle and deal with evolving prototype kind of project with no time available for refactoring. I have been thought a project that took few weeks to be coded into Alfa but costed us six months to fix up and refactor. You have a good chance not to repeat our mistake.

All in all, Agile or not should not be your personal preference. It is not a religion or us against them. This is simply a tool that you should be using wisely. You have choices and whether you make them right will most likely define the success of your future project. So, choose insightfully and enjoy project success.



Friday, August 15, 2014

Need more automated tests? - No problem

Many want to add automated test harness to their tool-set. Some start. Few succeed. There are many reasons for this unfortunate trend to develop, but I want to focus on just one - automated tests are expensive on resources. You simply need to invest more time and efforts into making it happen or you are most likely set to fail.

Despite hiring more engineers to write tests looks like an obvious option, unless your are Google and do not really care about money, it is rarely something that you can sell to your bosses. So, the point is to make the best use of the resources you already have. All those people who are working hard running manual tests could have been used as an additional workforce. Not only would it increase the number of tests dramatically, it would probably increase their motivation and enthusiasm by doing really cool stuff and learning a bit of programming.

This is good that we advanced so far in thinking but there is another problem. What if those people do not have the required experience? Indeed, I would not expect them to start writing an effective and reliable locator method from the start. But as far as they know how to write a cycle - they are good enough. All you need is to re-balance the tasks so as to make the best use of either 1. highly technical personnel, guru and 2. people capable of doing some of coding.

In case when first group of engineers is involved in all stages of automation you probably waste their time and experience on dealing with tasks that can be performed by group 2. Moreover some tasks in automation may be even more suitable for people with manual testing experience, like creating new test scenarios. So it seems like creating test sequences is better to be done by people from the group less experienced in automation, but more savvy in manual test design and execution, knowing concepts of equivalent portioning and boundary conditions. Whereas technical aspects, such as locator engineering and test architecture design should be left in hands on gurus.

This will allow you automation champions to spend more time doing more complex tasks, leaving the simple stuff to their colleagues from manual testing wing.

In practice this schema can be implemented by doing test design with stubs created by automation team, followed by test case implementation by manual testing team. Tests do not work until automation team implements all the accessibility and validation functions. Until implemented the function should report themselves as not implemented.

I have successfully employed this schema more than once. Hopefully this will be of help for someone else out there.

Happy test automation!