I have been thinking about randomization and test data for quite some time. If you are interested, you can find my views on randomization here. I strongly believe that testing is a sampling exercise and randomization increases sample size. If used properly, test automation would not be a repetition and will have potential to uncover something new in every run.

Despite its numerous benefits, I haven’t seen randomization used in many automation projects. This could be because of the lack of infrastructure around it. Randomization needs reliable test data generation, logging, reporting, visualization etc and often teams do not have bandwidth, motivation or skills to do it.

I wanted to solve this problem and it got me started on my project Test Spicer - http://testspicer.launchrock.com/

My vision for the Test Spicer is to - Increase efficiency and effectiveness of testing & test automation projects

If you would like to ...

How much automation is enough in software testing?

It is possible to answer this question in many different ways such as -

• As much as possible in the available time and budget.
• As much as needed - fight for budget and time if required.
• Enough to cover all the acceptance criteria - make it part of delivery.
• Should cover all happy paths, odd cases and boundary conditions.
• Classic answer would be any number such as 75.67% of code, 80.23% feature, 66.66% branch or whatever..
• And there may be other interesting answers

I agree that it's difficult to answer this question without looking at the specifics, however over a period of time, I have realised that there is a value in keeping automated suites small and simple. Automation code, like any other code base can have serious maintenance problems. If not handled properly, automation can have a big (and negative ...

I mentioned in my previous post that I will focus on testing mobile applications and will share tips, tricks and tools which might be useful for testing mobile applications. Today I am covering a topic which is very important for the user. This feature, However, is invisible (most of the time) and is often not covered by conventional non-functional testing types (accessibility, security, performance etc..).

In my previous article I briefly mentioned that unconventional non-functional requirements are one of the main differentiator between mobile and desktop applications. Let’s explore one such requirement - Power Consumption and answer two key questions -

1. Why it is important to test power consumption of mobile applications?
2. How can you get insight on power consumption by the application and improve it?

Let’s get started.

We have witnessed transition from desktop to web and are witnessing another transition from web to mobile. I have been thinking about a blog series around testing mobile applications for a while and this is the first blog post in the series. In the coming few weeks, I will try to cover various topics / products / approaches related to testing mobile applications. I will focus on Android to start with and will move on to other platforms.

Before I dwell deeper into the subject - it is important to understand how testing mobile applications is different from testing browser / desktop applications. If we understand the distinction and challenges of testing mobile apps, it will be a bit more easier to tackle them.

Last week I went to Zurich to present at Swiss Testing Days. I started my day by attending keynote - The nine forgettings - from Lee Copeland. I had attended his keynote in the past as well and he is an excellent presenter and story teller. Have a look at the slides he used and video recording . It was the same topic but it's definitely worth the time.

I agree with pretty much all the points mentioned by Lee, except certifications and boundaries.

Lee mentioned that certification is a way to grow professionally and it shows that you are serious about the profession. Well, I am not a big fan of certifications - certifications do not show that person holding certification is serious about the job. It shows that person holding certifications has passed an exam - nothing more than that. However, Lee mentioned certification as part of “Forgetting to grow” and he ...

Conference season is about to start and this year I am starting my journey with Switzerland. I am speaking at Swiss Testing Days on 13'Th of this month. It’s a one day conference and programme looks pretty good to me.

So what am I looking for in this conference? To start with, I am looking forward to the keynote from Lee. I met Lee around 4 years back in London and was impressed with his knowledge & style. For the next session, I am planning to attend Ramakrishnan’s session on Mobile Testing. We have witnessed transition from desktop to web and we are witnessing another transition from web to mobile.

I consider test automation as indispensable part of most of the testing project and I would have loved to attend next session from Dr Illnca Mose, however my talk is scheduled at the same time.

At Swiss Testing ...

So what would be the ROI of reading this blogpost? It’s possible that you get an idea which helps you in your test automation effort or removes myths you may have about software testing or you find that you are in software testing field because of wrong reasons and you leave this field altogether.

There are many possibilities and all of them are difficult to quantify. In my opinion, it is difficult to quantify most of the activities we perform in our field - software testing.

I have never done ROI calculations for any testing activity. My take on most of the activities I perform is simple and based on the MoSCoW model

Must

Things like exploratory testing, robust test automation, Continuous Integration, NFRs etc are more or less MUST for projects I get involved in. We discuss and get agreement on how to to implement / manage them but never ...

If you are working in web application testing domain and are interested in test automation, you might have used, come across or heard about PageObject Model in test automation. If you haven’t heard of it, it might be a good idea to read this article.

In nutshell, a separate class is created for every page / screen of the application in the PageObject model. This class exposes methods to represent all the operations a user can perform on various elements on the page. For example, a class to represent LoginPage might have methods to enter userName, password and click on submit button. Tests can use this class to interact with the page instead of duplicating elements everywhere in the test scripts.

PageObject essentially decouples UI from the tests and as a result makes test automation suite a bit more maintainable. In my opinion, if you are not doing anything else ...