RSS Feed

Category Archives: Software Testing

5 Excuses Every Software Tester Must Stop Giving

5 Excuses Every Software Tester Must Stop Giving

I have unlocked a pattern from my experience of hiring around hundred testers over a period of time and interviewing some thousand others.

From all the discussions I had with fellow testers during interviews, I felt happy numerous times seeing the quality talent which we have in our community of testers.

But let me also share the other side of the story, the patterns I am talking about. It makes me sad. 

I never feel happy watching potential performers being locked into a virtual cage of responsibilities. I feel discontent seeing the rock stars performing on a controlled stage.

If you are still wondering what’s the matter and what is the baseline, it is this- Considerably big part of our testing community is not having enough growth on multiple fronts for years after they start their career as a Tester. Forget 360 degree, it is not even near half of that.

Sorry for being harsh, but it is real.

Who is to blame for this? Maybe awareness in the industry to some extent. Company policies and senior management too may be. But more than anything else, it is the Tester himself/herself.

Read it again, it is YOU. It is us. Because we become victim to the excuse.

Below are the few patterns/excuses I uncovered.

5 Excuses Every Software Tester Must Stop Giving

Note: I nowhere mean that this is the case with every tester and every organization. But I have seen enough examples to say most of us are victims here.

#1) We don’t control our Test Environment, we have (read ‘very’) limited access

I often hear the statements/excuses- ‘We have just Read-only access to the environment’. Even worst- ‘We only have access to logs and nothing else’.  Everything else is done by either a Development team or some other team.

The work which will give us so many beautiful and fruitful insights about testing and many other technical kinds of stuff is not done by us. And maybe we are happy this way, but we should not.

Tell me one reason why you shouldn’t control your test environment and take maximum benefits of same.

Here are few possible benefits if you are wondering what I am talking about-

  1. You have full control over your test environment to make sure personally that it is exact or near replica of the production environment. This will help you avoid few surprises at least when your deliverables hit production.
  2. You know all involved components, all software used along with their versions for your product to function. With time, trust me you will have many insights about their working, limitations and possible failure points.
  3. You have enough access to do at least first level debugging in case there are Infra level issues. E.g.: Setup running slow, Checking CPU, Memory utilization and logs at every level of flow are no rocket science.
  4. You own control over setup, so you know what you are changing and what build you are deploying. You are much more confident than before while shipping the release ahead.
  5. You learn it and you learn it all. Though it is Linux based or Windows based.

Makes sense? Let me continue if you have at least agreed that there are benefits.

Now the question is what change you can make in your team/organization to make this work. And how exactly you will do it.

Well, I Don’t Know. I don’t know your team, your leads/managers, and your organization so I won’t be able to help you on this. I can surely share few things which might work. You try working very closely with your Dev or whichever team owning this and see what and how they do stuff. Everything.

The way they login to the environment (server), the way they logout and everything in between. Once you gain some knowledge, you will have the confidence to say few words, give some suggestions when a similar situation occurs again or if a similar activity is to be done again.

Obviously sooner or later your this confidence will be seen by your developers/leads/managers. That is the time you can ask for the control. And tell me one strong reason why they won’t give you that? They should be more than happy to do so if you have shown the needed capabilities.

Believe me, they have much more work to do, so it shouldn’t be hard for them to release the control to you. At least I hope so.

#2) We don’t deploy a build, some other team does it for us

You come to office on a Monday morning. You notice there are few issues in build causing blocker. You need new build from your Build repository. You raise request or contact your Dev team or deployment team. Ohh, they are busy with something. But they manage and do it after some time.

Now tell me, why all this? It is not as complex as it looks.

When to take a new build is surely something a Developer can suggest as he is the one who will be committing a feature or a bug fix. But when you simply need to trigger it and deploy it, why should you wait or depend on someone.

Having ability and authority to deploy whenever you want makes your work lot easier without any wait. Do you see that? It will also increase your Turnaround time in daily testing. Though it is debugging some defect with added logger, or taking the new build to verify resolved bugs. Or be it taking fresh build and starting with testing of a new feature.

Let me tell you something from my personal experience. It is not only about time. Deployment teaches you so many things that you can’t imagine. The reason is, it fails often. The application stops working with new code sometimes. Many times deployment itself fails. And every time something fails, it pushes you to debug it. It pushes you to search for something on Google or ask someone a question or the best ask yourself a question.

It makes you think.

Of course, it is not really a software testing, but it surely is testing your abilities.

I will say a large portion of my learning apart from pure software testing are from Deployment and Maintenance of environments.

  • I don’t remember how many trial and error attempts I performed for something, count must be few hundred.
  • I don’t remember how many times I went to check some release manual of some software.
  • And I don’t remember how many times I hit that Google search button or navigated to that stack overflow link.

All I know is- it gave me a lot, taught me a lot.

The remedy for this is very similar to the first excuse we talked about.

Learn it, show it and ask for it. It might work.

#3) We don’t debug an issue, we find steps and log it

I won’t go very hard on this as in an interview you don’t get a chance every time to discuss particular defect from candidate’s own experience and investigation/debugging done by him/her.

However, I can surely say that not all of us challenge our senses before passing on the defect to the developer.

Many times the log says it all. Many times the pattern of an issue says it all. Many times it fails because some prerequisite service was down.

So in short, many times it is actually possible for us to get to the exact root cause or at least reach near it.

So please ask yourself a few questions, not for helping developer but for making your test cycles fast and for your own growth.

You are the remedy here. No one else.

#4) I don’t know why it happened. Developer resolved it and I simply verified it

Ohh, come on. Sorry but hearing this annoys me a lot.

Every single time, it annoys me when I ask Tester a question- Why particular defect was faced or what was the RCA (Root Cause Analysis) and he/she answers ‘I don’t know’.

Have we taken Black box word this literally? How can we not ask Developer about what exactly he fixed? Why can’t we ask it if the authority is an issue?

I am damn sure that 99% times we don’t know the Root Cause Analysis (RCA) or fix because we don’t ask for it.

Believe me, knowing the exact fix, module in which fix was done, whether it was in the front end or back end, whether it was injected in any feature development or some other defect’s fix, will always help you in your testing. Always.

Apart from this, this information helps you know a lot of technical stuff which may be otherwise you will never come across.

Remedy? Ask it. Demand it. Whichever works.

#5) I didn’t get the opportunity to work on anything else than Manual Testing

Maybe this excuse is valid to some extent considering the possible workload on you or restricted responsibilities given, but not completely valid.

The problem here is, we say that we didn’t get the opportunity to perform non-functional types of testing, or we are not supposed to do it or we don’t have time.

Agreed, learning always demands time. But isn’t there anything you can change?

While testing that new feature or while testing that one API,

  • Isn’t it possible for you to keep watch on the response time?
  • Isn’t it possible that you ask your Business Analyst about the load this particular feature/module/API is expected to handle in production so that you can test it?
  • Isn’t it possible to perform at least basic security checks like session expiry, URL tampering or XSS handling on that website form you are supposed to test?
  • Isn’t it possible to at least say that this particular ‘Submit’ or ‘Help’  button doesn’t seem to be properly located or not easily noticeable and play your small role in making the product more usable?
  • Isn’t it possible for you to start with something and then keep learning it more and more?

The answer is YES, small or big depending on various factors surrounding you but it is surely not NO.

If your responsibility doesn’t demand it (because there is some other team for it), no one will stop you investing extra time for your own learning. Self-learning in extra or free time is always possible I think. So find those possible extras, and start doing it. Now.

Conclusion

I hope I triggered some thought process and some learning ambitions within you.

Please forgive if you found any of my words harsh, but believe me, I wanted to be 100% clear so that it reach out to you all with needed seriousness.

Hope it works positively for you all.

I will be more than happy to know any uncovered aspect around possibilities I talked about.

Agile Testing Mindset And The Role Of The Agile Tester!!

Posted on

Agile tester in an agile team plays a very important role towards the end product quality testing. He or she should be able to collaborate well within the agile team members and other project’s stakeholders. In order to collaborate well with the team members, the tester is expected to have an agile mindset in terms of testing skills and other quality assurance activities that a tester should perform as being a part of the agile team.

Agile Testing Mindset:

To play a role of agile tester, the tester should have the Agile testing mindset which will help him to break free from the traditional project methodologies such as SDLC, V model, waterfall etc. In order to develop the correct mindset, the agile tester should possess the following characteristics.

  • Prevention is better than cure”. An agile tester should be focused on preventing defects rather than finding defects.
  • An agile tester should provide the Quality Assistance over the Quality Assurance.
  • An agile tester should not believe in enough testing but should believe in the continuous testing approach instead of starting testing at the last moment.
  • An agile tester should not play as an individual player but the agile team player and should work closely with the whole team in collaboration.
  • Responsibility wise in agile testing mindset, it should be team responsibility instead of an individual tester responsibility.
  • Testing focus should be on automation rather than manual testing when it comes to regression.
  • An agile tester should prefer the Exploratory Testing over the Scripted Testing approach.
  • It is not SDLC methodology therefore; agile user stories from product owner should be used for customer requirement gathering over the traditional requirements specification.
  • When it comes to web testing, the focus should be on Technical, API Testing and GUI Testing in order to ensure complete end to end testing.
  • The mindset of an agile tester is to make sure that the software is built correctly instead of breaking the software like Monkey testing.
  • An agile testing approach does not wait for the testing phase to start therefore, with the agile mindset the tester should be involved into testing as early as possible.
  • An agile testing approach does not require providing the detailed testing report after the end of testing instead Short Feedback helps the team to get the idea that they are building the software in the right direction. This approach gives lots of time to fix the defect if it is identified in the early stage as a short feedback.

After all it is “Attitude that makes the altitude”. Therefore, if a tester has the above Agile testing mindset then definitely he or she is a perfect fit to the project’s agile team.

Role Of The Agile Tester:

So far, we have discussed about the agile testing mindset, now let’s grill on the various roles of the agile tester. An agile tester is responsible for the following roles.

  • First of all, an agile tester should comply with the agile project methodology i.e. the active participation in daily standup meetings, joining session based on the grooming on user stories, retrospectivesteam meetings, continuous improvement suggestion to make the process the best.
  • Active collaboration with the agile team which involves the developers, business stakeholders, etc. which may help in making the requirements on the product functionality crystal clear and help the testing team to widen the scope of testability.
  • Clear understanding of the agile testing strategy at the project level.
  • Close working with the product owner in order to capture the acceptance criteria which will later evolve into the acceptance tests.
  • Measurement of the overall test coverage that the acceptance tests cover.
  • Well versed with the use and implementation of the automation testing tool in order to help in the regression testing.
  • Setting up of the test environments, test data for functional and the volume testing and the maintenance of the existing test cases and scenarios.
  • Execution and the development of the automation test scripts to automate the acceptance tests.
  • Preparing the test report and sending the report across the agile team. So that the team isinformed about the defect and the testing progress on the current product.
  • If as an agile tester you are leading a team then it comes under your role to coach or train the testing team so that they can collaborate well in the current testing expedition.
  • An agile tester should help in testing sign off from the stakeholders for the project release and should also participate in iteration planning for the product testing.

 

An agile tester should not forget that though it is working in collaboration with the developers as an agile team but still he or she is a tester and should comply with testing roles and health online pharmacy without prescription responsibility with the appropriate testing mindsets. A tester failed to follow the above roles and responsibilities may result in insufficient testing and hence the failed software end product.

The following could be the risk to the organization with the agile testing methodologies.

  • As we know, testers work in collaboration with the development team then it may happen that they lose their testing mindset and start thinking as a developer. Both has different mindset should follow their assigned responsibilities in order to develop the correct software product.
  • Being a tester, one should not hesitate to escalate inappropriate or ineffective practices within the team. No matter whether the tester is collaborating in the best way with the developer, the incorrect thing which cannot be made correct and therefore, should be discussed in the Daily scrum meetings.
  • In agile methodologies, the sprint is of the short duration. The small sprint may sometime result in sparing very less time for tester to test the developed product in the current sprint or to run the complete regression.

All the above risks should be well discussed with the agile team as a part of the daily meeting.

Over to you:

In this article, we have discussed about the various roles and the agile mindset that an agile tester should possess in order to become an asset to the agile team.

Overview of SeeTestAutomation – Mobile Automation Testing Tool

Posted on

Mobile applications are being used for just about everything. Among the biggest players in this industry are large enterprises. Every business aims to deliver the most cutting edge version of their mobile application to an ever growing audience of mobile users.

Mobile applications work on multiple platforms, and over all main mobile operating systems. Testing these mobile applications to work flawlessly on multiple device, operating systems, and versions of each requires mobile test automation. A mobile automation testing tool enables the DevOpsteam who built the app to test it faster, while covering a larger test coverage area in the process.

Benefits of SeeTestAutomation:

SeeTestAutomation is among the top tier of mobile test automation tools. It has cross-platform capabilities developed and supported by Experitest to automate native, hybrid and mobile web applications running over Android, iOS, WindowsPhone, and Blackberry. In the last few years SeeTestAutomation has become a leading tool in the market to test the quality of an application. SeeTestAutomation is tested on simulators, emulators, and real devices.

SeeTestAutomation streamlines the automation script process by allowing you to plug in your mobile device, or reserve one from the cloud, and see a reflection of that device on your desktop screen. You launch the app, and perform the steps you wish to test by manipulating the reflection like you would use your mobile device, but this time with your keyboard and mouse.

As you perform a step, SeeTestAutomation will record the step as part of the test script. Once you are done executing the function you wish to test, SeeTestAutomation will have created a full test script. You can then edit the script to include if/then statements or loops. You can also export the script into other testing environments and programming IDE’s. SeeTestAutomation supports Java, C#, Selenium, QTP, UFT, Vugen, Microsoft Visual provigil online buy Studio, IBM RFT, SmartBearTestComplete, Java, Pearl, Python, and Ruby.

 

Advantages of Using SeeTestAutomation:

There are various advantages of using SeeTestAutomation for mobile application testing:

  • Easy to script –The ability to create scripts by “using” your app makes the process simpler.
  • Easier to resolve bugs and issues –SeeTestautomatically captures logs and information during the bugs report, and automatically attaches to your “Defect Management Solution” (f.e JIRA or Quality Center) device logs, incident video and a full detailed report with screenshots and description that allow developers to reproduce and resolve the issues faster.
  • Runs over all mobile devices and operating systems –You just need one tool to handle your entire test coverage.
  • Enables cloud access – You can rapidly scale up your test automation by running your scripts over a large pool of mobile devices based in SeeTestCloud.
  • Compatible with all major mobile testing environments – Your test scripts can be converted into scripts for Selenium, QTP, Microsoft Visual Studio, IBM RFT, SmartBearTestComplete, Java, Pearl, Python, and Ruby.
  • Works with functional and non-functional testing –Virtualize memory and CPU stress conditions on your mobile device, or simulate the network connection. SeeTestAutomation integrates with HP LoadRunner and allows load and performance end-to-end testing scenarios.
  • Continuous Integration (CI) compatible –SeeTestAutomation fully integrates with a variety of CI tools such as Jenkins, TeamCity, Hudson, Quality Center and many more.

Conclusion

SeeTestAutomation is a vital part of any end to end mobile application testing process. Experitest aims to make the transition from manual to automation as painless as possible by offering support for installation, integration into current systems, and troubleshooting along the way. With its flexibility to other DevOps platforms and all mobile devices and operating systems, SeeTestAutomation is an optimal tool for establishing or enhancing your mobile test automation.

5 Tips To Successful Mobile Testing

Posted on

Being a mobile application tester for more than 5 years, I have learnt a lot about effective mobile testing. In this article, I am going to share my top 5 tips to successful mobile testing. Usually we followed the traditional V model software cycle in which the software was developed and unit tested by the developers before handing over to the test team. As soon as we used to get a new build, we used to run sanity test to make sure the build is stable to carry on the rest of the testing including regression, functional, non-functional and performance testing. Main testing was manual but performance was mainly done using automation.

Based on my experience, below are the 5 tips to successful mobile testing:

Thinking From User’s Perspective:

It is very important to think from the user’s perspective while testing the mobile applications. There could be different types of users using the same mobile for different purposes. For example, a small business owner would need all the apps related to his social accounts so that he can sell his products easily and conveniently whereas a student using the same mobile would prefer to have apps which are more on entertainment side. If you are clear on what your target users would be then thinking from their perspective would make your testing more focused and also would improve user’s experience. I would like to explain this with another small example, say I am testing an app which is mostly be used by user who loves music. I have to make sure that the user do not find any issues related to the quality of the music and the search of his favorite song. Also, I should make sure that playlist created should be saved properly and adding or removing songs should be easy. These were some of the cases when I am thinking from the end user’s perspective. This will not only give me proper directions to test but also help me in improving the overall quality.

Negative Testing Along With Exploratory Testing Is Important:

Before I explain this point, I want to mention the importance of the negative or boundary testing. If we are a mobile tester then we need to have test cases which test the breakpoints or the limit of the mobile device. For example, I had noticed this while testing a music application that after adding like 50 songs to the playlist, adding 51st song made the application crashed, so I knew that 50 is the limit which can be properly handled by the application but there was no notification for the user. Solution was either to increase the limit or notify user about the limit in advance so that he knows what to expect. Negative testing not only gives the clear idea about the expectations about the product but also, helps in knowing the product better and when it is combined with exploratory testing then quality would touch the sky. Exploratory testing gives the freestyle or freedom based approach where there are no pre-written test cases and you can test all the possible test scenarios based on your experience and thinking out of the box.

Performance Comes First:

Mobile is something we carry with us all day along. It is very important to test the performance of the mobile. It includes load, stress, battery and other aspects. Performance is something which makes the major difference. Let me give you some examples, when you go to any online mobile shop and see the user’s reviews, you will find that there would be lot many complains related to battery heat up or device hang up on a particular screen which hugely affects the rating and ultimately the business. People prefer to pay more for a mobile which is high on performance and that makes performance a key factor to test. When you know how much load the device can take or what is the expected battery life then you will have a clear idea what to convey to the users beforehand so that they will not have any surprises afterwards. Loading the mobile memory by 80% and see how it behaves or pressing a key or two like 1000 times and see if mobile works fine under stress. There are many automated performance tools available in the market today which will not only save a lot of efforts of a tester but also gives him more time to focus on different testing areas to maximize the test coverage.

Detailed Bug Reports:

Bug reports are the most important documents when we talk about the quality bugs and fixes. An ideal bug report will have all the key details like severity of the issue, steps to reproduce, expected result, actual result and other details. I have seen bug reports which were not detailed and due to that development team wasted a lot of time in reproducing the issue. When everything is clearly mentioned in the bug report, it becomes easy to find out the root cause and hence, it helps in fixing the bug properly. It would also give an idea about the areas which could be affected by fixing a bug. In short, detailed bug report makes tasks easier for both testing and development teams.

Sanity or Smoke Testing:

We all know how important sanity testing is! While analyzing the requirements and creating test cases, it is very important to know all the key applications and areas which have the highest priority i.e. without which the mobile is useless. For example, start or home screen, power button, home button, volume up and down, scrolling are some of the major areas. If any or more than one area has any issue then the severity becomes the highest and should be fixed as soon as possible. Build should be returned to the development team to fix and no further testing should be performed until the new fixed build is built. To run sanity or smoke test is the first step and to choose proper test cases for the smoke or sanity suite is important.

Mobile testing is not as complex as it seems, important thing is to learn from your experiences and pay attention to details. Users play the most important part here so is the thinking out of the box approach of the tester.

ETL Testing / Data Warehousing Testing

Introduction on ETL Testing:

ETL stands for Extraction, Transformation and Loading of data. In data warehousing, data from multiple data sources is extracted, transformed (as per the business logic and data definition of target database) and loaded into cohesive database. Data warehouse efficiently handles day to day data along with organization’s historic data which may be very useful in creating reports for audits and compliance’s, future market predictions, etc. Since data loaded is very critical to the organization therefore it is very important for ETL process to undergo testing whether the extraction and transformation logic of data is as expected and also the loaded data is meaningful and as per requirements. Therefore ETL testing is new testing field for testers to pursue their career and this is the correct time to gain knowledge about ETL and Data warehousing testing.

Importance of Data Warehousing:

As organization businesses are growing day by day which is creating more and more data therefore there is a need to retain data in well-organized manner so that it is available for company’s day to day business expectations. Thus organizations are required to practice best extraction, transformation and loading technologies to integrate historical, day to day and other business data into centralized target database. In order to achieve this, many companies are creating their own database using various ETL tools to make the process very efficient.ETL tools make the process of extractions from multiple data sources very comprehensive and then transformation is done based on the required business rules. This transformed data is persisted into cohesive database known as Data warehousing and process is known as ETL data warehousing.

In order to make sure that the scripts applied in the ETL tools for extraction, business rules for transformation and data loaded are correct, there is a need to prepare the required test plan and test cases. Organizations may gain confidence in their business after Smooth ETL process which can only be achieved by efficient testing of entire ETL process, which is well planned and executed by the team of test experts who are proficient in ETL testing.

ETL Testing Classification:

ETL-Data-Warehousing-Testing

Irrespective of using ETL tools, ETL testing can be classified into following types:

  • New Data warehouse project: This scenario involves testing of DW from scratch. Required test plan is created and functional points are identified in ETL functional documents. Accordingly test plans are prepared and executed by ETL testers.
  • Adding new source to existing Data warehouse: DW has multiple data sources. Data from these sources is transformed and persisted in cohesive DW database. Adding new data source involves addition of new data source to existing DW. Here testing expectations are to feed data from new source that is compatible with existing business rules and DW.
  • Migration of Data warehouse: Here underlying database is migrated, for example, say from Oracle to Teradata depending on clients trust on vendor. Here ETL test team is expected to run all the existing test cases and make sure all test pass without any roadblock. Moreover test team conducts the performance test to justify the fact that the migration project has benefits over existing database.
  • Change of Business Logic: Sometimes there is the need to change the existing business logic or add new business logic in data transformation. Test team here builds new test cases according to the new logic and make sure that old functionality is not affected by this new change (Regression).
  • New or Existing Report testing: DW is the best source to generate new reports for audits, compliance’s, etc. Thus testing of report generation procedure as well as report data is conducted by ETL expert testers to deliver the quality end product.
  • Platform Migration: Sometimes entire DW is migrated from one machine to another machine, for example, migration of database from low performance to high performance hardware boxes. In such scenario ETL tester are expected to execute existing test cases with additional performance tests to make sure ETL process is not broken and there are no roadblocks for business as usual.

ETL Testing procedure:

Testing procedures for ETL as follows:

  • ETL test team is provided with functional requirements documents.
  • Test team does the validations and come up with test estimates.
  • Test planning is started based on above information.
  • Test cases are developed according to the given ETL test scenarios.
  • After test cases are approved by senior member, they are executed by test team till the expected output is obtained.
  • Performance tests are also executed by ETL expert test team.
  • After successful completion of ETL testing, test summary report is prepared and handed over to the senior project team and testing tasks are signed off by ETL test team.

Over to you on ETL Testing / Data Warehousing Testing:

Like any other software application testing, ETL testing follows same testing principles and since this ETL testing is the niche skill required in the market therefore such resources are on high demand in the market. ETL testers are expected to have good knowledge of ETL procedures, SDLC, SQL queries and system performance testing. A human resource with all of these skill set is an expert ETL tester.

%d bloggers like this: