Android testing with Amplify presented at NYC Selenium meetup
Our journey towards continuous delivery
By Mona Soni
Deploying a software to production systems is sometimes more challenging and painful then building that software. Production deploys add business risks because a bug can bring an entire system down causing a hit on potential earnings. In addition if the approach is “Big Bang” release, the release would have a lot of built up changes so additional risk. Therefore historically companies preferred to do minimal releases at an annual or semi annual rate. But in today’s competitive world to stay ahead of the market product teams want to get their features out frequently and many companies are moving to continuous delivery where production deploys happen once or more in a day.
At Amplify our focus has always been to achieve continuous delivery with customer satisfaction. This journey towards continuous delivery has not been less than a roller coaster ride with various challenges. I will mention few of the challenges to better explain our solution.
Learning Automation: Selenium
Learning to be a Tester: Automation Testing
in previous post we went through the basics of software testing and now lets explore the automation testing. Functional testing is required to be repeated over and over with every new commit or change in the system. For an application with considerable features this could be a very lengthy and cumbersome process. Automating the functional tests saves time and provides frequent effective feedback.
There are various tools and frameworks used for automation. Lets look at first various types and level of automated tests. The best way to make sure that your test automation is going in the right direction is by following the automation pyramid conceptualized by Mike Cohn, I will be sharing it in the context of how we use it at Amplify.
We have majorly three set of tests to test the functionality as displayed in the automation pyramid below:
Note: There could be other types of automated tests to test non functional aspects like Performance. Here we are only talking about functional tests.
Lets look at various types of automation tests that we have in our pyramid:
Q:Hi there Mona. This message isn't so much a question but more of a kudos - thank you for your insightful and easy-to-understand blogs on testing. I especially like the post on automation testing. I just started a role in QA, and did not know where to begin my learning until I found your blog. Thanks again, and cheers! - Pauline from Seattle
Thanks Pauline, I am happy that I was able to help you out in your journey as a QA.
Learning to be a tester!
Recently I was searching good material that I can share with my team mates who have just taken up the role of a QA. Although there are hundreds of posts out there but I couldn’t find one concise article that would explain the job of a QA professional in an agile project. Here is the synopsis of what I think would be a first stepping stone of a QA.
As I explained in my previous post ‘Choosing to be a tester’, the responsibility of a QA is to assure quality of the whole system. A QA would achieve this by performing various tests on the system at various stages. Lets talk about types of testing that can be done on a software or a product. I will explain this by taking a non software example. I have been asked this questions many times and this is my favorite interview question as well.
'How would you test a pen?' or any random object, lets list out all the types of testing and various scenarios that can be performed to test our pen:
In an Ideal software development world there would be no QA team or a testing team, but we all know all the processes including software development are prone to human error. With an increasing demand for better software there is a rise in Quality Assurance jobs.
But most of the business or stake holders consider the QA team as an overhead and whenever their is a slump period the axe falls first on the testers. The development team as well often finds it difficult to fit in the testing team into their development phase and the teams usually end up on two poles of the process. And I can imagine the poor Project manager at the centre somehow managing and trying to get work done to get his billing correct. Facebook doesn’t have any software testing team but they do as well test their software through beta testers before launching a feature to the world.
How and where exactly does the testing team fits and can they really improve the software industry
Estimation and testing
After more than a decade since Agile Manifesto was published there is a wide spread adoption of agile practices in software industry. Although it had been more prevalent in small and start up companies but in last 2-3 years even banks and big companies have been learning the agile ways. With this increase in agile popularity there is a surge in failures attributed to agile methodology. As part of a research it was established that how unsuccessful Agile has proven to be, the key points from the report are available here. But there are reason for these failures, a great article "How To Fail With Agile:" explains possible causes behind these failures and how teams can avoid these pit falls.
Effective BDD with Cucumber
After attending couple of events in last few months I came across the reality of our BDD world. Most of the teams that use cucumber or any other BDD tool have adopted them as QA tools. There developers or business or product people never look at these tests and are sole responsibility of QA team. Does this sounds familiar? do you do it the same way? is cucumber killing you?
BDD is an evolution of TDD and by definition it aims to help focus development on the delivery of prioritized, verifiable business value by providing a common vocabulary that spans the divide between Business and Technology. There are various tools and frameworks that can be used to implement BDD and cucumber is by far the most used.
Before you decide that cucumber isn’t the right option for you, lets analyze different reasons that make using cucumber less effective:
Choosing to be a tester!!
During interviews I have always come across candidates who wanted to be developers but landed up in QA somehow or they started with QA considering it to be an easy job and want to move to development as they gain experience. I have always been supporter of changing profiles, trying different roles but this one not so much. As those I have seen taking this path are mostly doing this because either they think developers have better roles then testers or they think development is too difficult. According to me if you are working as a tester and believe in any of these two then you probably don’t know your art well enough.
I didn’t chose being a tester or would say that was the only road I had seen in my initial career. And I am happy that it out to be the right choice. But what about those who have choice? Given that the average developer to tester ratio is around 4-5 developers per tester, there are good number of testing jobs in the market. And the testing community is definitely in need of people who are passionate about their work. I am highlighting some points that I like most about being a QA: