Running Cucumber features across browsers

Tags

, ,

I use Cucumber and Capybara for testing my Rails application, it’s easier to write tests using Cucumber tool, like an example mentioned below:


Most of the time on CI (Continuous Integration) server we execute our tests in headless mode, but recently I had to run my tests across many browsers like Firefox, Chrome, Internet Explorer 8 and 9 and that’s when the need to run these test across multiple browser arise.
You can also configure your capybara to run on remote hosts, that means from your machine you can connect to browser installed on some other machine which is on same network, It’s really simple to configure on Rails application.
 
Install Cucumber and Capybara

To configure Cucumber and Capybara in your Rails application, add these dependencies to your Gemfile and then run bundle install:

If you don’t define the version, it will pick the most recent one when you run “bundle update”, Once these gems are installed then run the following command to generate your cucumber config:
Now, lets use the above mentioned example of Cucumber feature and get it working (assuming you will write step definition, use it for reference). By default  test run’s in Capybara’s headless browser, so before we test on real browser, lets get this test working on default one.
 
Run in default headless mode

To run the test, type this command from your web folder.

Now, when feature is passing in headless mode, lets try to do some configuration changes to run tests in various browsers.
 
Run tests on remote Internet Explorer (Windows Machine)
Use any windows machine on your network to set up.

Selenium requires Java so you should have it on your machine, you can download it from here. Open new command prompt (Start..Run…cmd) and run the java command to see it has installed successfully, if not then set the environment variable to get it working.

Now from Selenium page get the latest selenium-server-standalone.jar and from your command prompt you should be able to navigate to where the file is downloaded and run:

It should show some logs on command prompt and let you know its running.

It’s time to hook Capybara to Windows

To get your features running on that box go back to the Rails application, open up features/support/env.rb and add this snippet after capybara.default_selector line

Make sure you change the ip address in the snippet to the correct one and now when you type:
You should see IE browser launched on your Window’s box and test should pass.
 
Run tests on Firefox browser
To get your features running on your local Firefox instance go back to the Rails application, open up features/support/env.rb and change the default driver to be selenium instead of capybara.
Now type the same command and your tests should run on firefox browser.
 
Run tests on Chrome browser
To get your features running on your local Chrome browser go back to the Rails application, open up features/support/env.rb and change the default driver to be selenium_chrome instead of capybara and add following snippet.
Also on your machine you will have to install chromedriver before you run the test against chrome browser
Now type the same command and your tests should run on chrome browser.
I am yet to try it against Safari and will keep this post updated, let me know if you had any issues.
 
References and examples picked from:

Advertisements

My View of Specification by Example

Tags

,

It’s been few weeks I attended a 3 days Advanced Agile Acceptance Testing workshop by Gojko Adzic at ThoughtWorks, Sydney office. I am trying to put down some points which I feel might be helpful for my friends.

What is Specification by Example

Specification by example is just the concept underlying our test driven development, in theory each test should indicate how a system will be used to build the software. Many times we think tool is important for making our life easier, but the fact is best of the tools,will also not help us unless we define specifications collaboratively correct and clear requirements with examples.

Most of the time teams blindly start implementing solution on the requirements which are given by the business, but in order to build the right software, we should define scope by derving it from goals and business should tell us the value they are looking for, delivery teams should use their knowledge and suggest a easier, faster and cheaper solution to the business.

Specifying Collaboratively

Delivery teams should collaborate with business users in specifying the solution, each team members have their own capability and it can be leveraged, it also creates a collective ownership of specifications, making everyone involved and more engaged in the delivery.

Team starts writing these specifications using Natural languages so that it’s easier for other team members to understand, but  they can’t be concrete in first attempt, which leaves a gap in understanding of the consumers mind because each individual perceives it differently, so in order to make it concrete, team should be using examples. Teams identify the key examples to fulfil a specification and later they can be expanded to cover other edge cases which testers find, in this way everyone in the team will share the common understanding of what needs to be delivered, which will avoid any kind of rework and since key examples are easy to understand and communicate, we can replace the requirements with these key examples.

Refine the specification

Now these key examples can be refined by cleaning them, by removing all additional information, they should only tell us what the software is suposed to do, not how it does. Once the examples are refined they can be used as an acceptance criteria, so when team is doing development they have to make sure that software works correctly for for all these examples. These key examples identified plays a various roles as acceptance test, functional regression test and specification of work.

Now in order to get the quicker feedback we automate these key examples and this way we reduce the cost of fixing the failing examples earlier. An automated specification with examples is written in a human readable format and should be easily accessible to all members of the team. We can use these executable specifications as a target for development and easily check if the system does what we agreed and the same document can also be used by the business when needed to change the specification.

Living Documentation                                                                                                                                                                                                   

Now since we have these specifications documented we should ensure that they are well organised, easy to find and consistent, when business rules changes these specifications should also be updated so that gradually they become a living documentation for the team.

Living documentation is a reliable source of information which tells us how the system functions currently, It is much easier to read and understand by any user, Business can use it as a reference for analysis of new requirement, Developers in the team can use it for development and we testers can use for the testing purpose.

Collaborative analysis reduces testing efforts !!

Tags

,

Preventing defects is much more important than finding and fixing them, we can do that by doing a better analysis of requirements. It takes lot of effort and a higher cost to get the bugs/defects fixed at later stages in a software lifecycle  as compared to finding/fixing them much earlier in the cycle.

We all know that defects get injected into the software right from the requirement gathering stage, so if the requirements are properly analysed and cleared than it leads to developing the high quality software, whereas if it’s other way round then it leads to a bad code which may or may not work. Common example of poor requirement gathering is teams develop and test some piece of code, show it to business and then business realizes that the solution developed does not solves the problem completely, which generates some new requirements and the cycle continues, all this time we spend time in testing, re-testing the same piece of code. Getting the requirements right in the first place will greatly reduce the effort which in turn leads to less retesting.

Defects in requirements can be very costly for the organisation as it involves large amount of rework or may be project failure, so before the requirements get converted into design or get into implementation phase, it must be ensured that they are correct, complete, still valid, current, testable and relevant.

Since we work in collaborative environment, I would not leave the requirement gathering only on business analyst (BA) but to the entire team, specially quality analysts. I have tried pairing with BA’s on the team and found that BA-QA pairing helps designing the better requirements, In fact QA’s can think of the requirements to be testable or not which also helps in analysis.

Morale at Workplace

Tags

, ,

I do not have much experience as I started my carrier just 3 years back. There are various factors which motivated me to write this blog. I’ve fallen victim to it’s lows and have experienced the occasional highs.How strange that the one thing that drives a company the most is the one thing most companies don’t drive…”Morale”. Morale is often related to “Job Satisfaction”, But I feel, ‘Job Satisfaction’ is an individual phenomenon; while Morale indicates a group phenomenon. In better words, Morale indicates the happiness of the employees with the organizational environment.
Morale is also often believed to be all to do with ‘reward’ and it’s no wonder company directors are so dismissive of improving it. Better morale suggests better reward, and reward suggests ‘money’.What I have found by personal experience and reading various articles is that when poor morale finds a crevice to breed, it festers, grows and consumes all others. It has such a grip that it begins to cross teams, departments… entire infrastructures.

Do you want to know what morale is really about? It’s not money. It’s ‘Recognition’. Recognizing that someone is valuable. Sure, you could do that with money. But how many people do you know that say that they never earn enough. We live in a society that encourages us to live beyond our means. We will never earn enough. It’s not money. It’s recognition.

Morale is normally high when everything is going ‘just right’. When people come in to work, enjoy their job, go home feeling like they accomplished something, and are welcome home. Everything is just right.

What set’s off morale on a downward slope?

Something inevitably goes wrong. Whilst morale is high, we tend to deal with it by happily going about fixing whatever it was that went wrong. If it’s a short fix. A small problem. We deal with it effortlessly with ease.

So it’s not when things go wrong? Or is it? No. It’s when we stop communicating. It’s when something goes wrong (or generally, when it’s about to (we’re all pretty intuitive to what upsets the balance of our happiness)), and we hold back communication.

Even in best of times, morale is delicate, unpredictable thing, Bad morale is insidious. It skulks, lurks, and it simmers just beneath the conversation at the water cooler. But if you keep your eyes and ears open, you’ll know when it’s there. Morale is a business issue, it also causes decline in productivity and quality. Morale is not a software program so can’t be fixed by service packs or patches. It won’t be solved by pizza parties, free gifts and functions.

Reason of Bad Morale

Lack of communication and bad management, or lack of confidence in management, are the two biggest cause of low morale. It doesn’t matter what the economy is like.
In tough times such as these, the people are looking for support, leadership and reassurance, If they are ignored or underestimated there is a morale problem on hands.
* First step to fix it is acknowledging that the problem exists.
* Second would be, realizing that it’s my responsibility to make it better.

Some steps should be taken for recognizing and rehabilitating low morale

a). Look, Listen, Take Nothing for Granted.
The biggest mistake you can make is to ignore the existence of a problem or rationalize it away. People shouldn’t be constantly uncommunicative. You should try to know them, what they feel, let them know about yourself. You might have open culture but people learn from their previous jobs to keep their mouth shut. Employees try to hide their feelings because they are afraid of a departmentative backlash if they say anything. The best way to counteract that kind of wariness is to talk to your staff in a consistent honest manner.

b). Honesty Is the Best Policy
The biggest mistake is to withdraw information and keep it yourself and don’t share information with the employees. It’s insulting to your employees’ intelligence, and it’s very destructive in terms of morale. As a leader, even if your own morale is down, you have to keep your head up even if it’s just by keeping a smile on your face.
Building morale through communication is more than smiling and keeping the doors open, however. It means developing the trust between you and your team and that kind of connection is made by opening up about yourself, both personally and professionally. Let them see you as you are. Hold a series of meeting with them to improve morale, update them on what’ being done and gather feedback on the process as it moves forward. By involving them, it will make them feel powerful and pat of solution rather then problem. By soliciting their advice, you demonstrate a level of respect and trust that they need to see.

c). Don’t take away Their Trainings
This is another effective way for boosting morale and solidifying a sense of commitment between you and your staff is to shore up your professional development and training program.

d). No cheap tricks.
You have to do something every day that will make them want to come to work. Employees are smart; if you treat them badly specially during tough times, they will remember. If you treat them well, they’ll be loyal and stick around. If not, they’ll leave for the better place as soon as they can.
Appreciate your staff as much and often as possible, treat them like they are the best. Do whatever you can, even in small ways, through emails, meetings, though one-on-ones, let them know you value them and the work they do. For such efforts to be effective, they have to be genuine.
People don’t stay for the cheap tricks, they stay if the environment is supportive and challenging, if business is functional and there are positive working relationships.

Improving Employee Morale

Improving employee morale benefits everyone involved in a workplace. Boosting morale means they will feel more pride in their work, call in sick less often and be more productive. Happy employee means happier employer. Improving employee morale can be accomplished fairly
easily.

Most people thrive on feeling appreciated, so you can improve employee morale by showing you appreciation in simple ways like saying “job well done”, “ good work”, etc. Another way to show appreciation is by being friendly and interested in your employees. A warm smile and sincere query about how one is doing will in turn motivate employee. Encouraging social interaction is another way of doing it, yet another way is by rewarding your employees.

A very important factor in improving employee morale is the work environment. Research shows that atmosphere greatly and directly affects the motivation level and feeling of well being of the employees in a workplace.