No comments yet

In today’s competitive digital landscape, businesses are under constant pressure to accelerate their software development cycles and enhance digital capabilities. Although automation has become a staple in the software development lexicon, a surprising number of organizations—only 30% according to recent studies—have fully adopted automation testing. This gap highlights a significant opportunity: many companies invest heavily in digital transformations but fail to integrate comprehensive testing strategies, limiting their potential gains. 

Continuous testing stands out as a critical methodology designed to align with the rapid pace of modern development cycles. This approach not only helps in detecting errors early in the development process but also ensures that software products consistently meet quality standards before reaching consumers. 

What is Continuous Testing?

Continuous testing is an advanced software testing strategy that involves evaluating software quality at every stage of the software development lifecycle (SDLC). This is done to identify defects early, thereby enhancing the quality of the final product while ensuring business continuity. It is a vital component of DevOps and Agile practices, integrating seamlessly with these methodologies to support continuous integration (CI) and continuous delivery (CD). 

Key Features of Continuous Testing:

• Immediate Feedback: Enables developers to receive immediate feedback on the impact of their changes. 
• Automated Testing: Utilizes automation tools to conduct tests repeatedly during multiple phases of development. 
• Quality Metrics: Provides ongoing insight into the quality and readiness of the product throughout its development. 

An effective continuous testing strategy is pivotal for organizations aiming to maintain robust software delivery pipelines. Here are detailed strategies and practices to enhance the efficacy of continuous testing frameworks. 

Challenges to an Effective Continuous Testing Strategy

Before exploring optimization strategies, it’s crucial to address the common obstacles that enterprises face: As organizations increasingly seek to accelerate their software deployment cycles, many grapple with significant challenges that hinder the effective implementation of a continuous testing strategy. Here are some key challenges: 

1. Balancing Speed and Quality: A primary challenge in continuous testing is striking a balance between the speed of delivery and the quality of outputs. Rapid releases often sacrifice thorough testing, leading to potential bugs and performance issues.
   
   
2. Integration with Existing Processes: Many organizations face difficulties integrating continuous testing into their established development workflows, especially those that have traditionally relied on manual testing. This shift requires significant changes in both the tools used and the organizational culture.
   
   
3. High Initial Setup Costs: Establishing a robust continuous testing setup requires considerable investment in tools, infrastructure, and training. This can be a significant barrier, particularly for smaller organizations.
   
   
4. Choosing the Right Tools: Selecting appropriate and effective testing tools is crucial and challenging, given the vast array of available options. The wrong choice can lead to inefficiencies and inadequate coverage.
   
   
5. Managing Test Data: Effective test data management is essential but challenging. Ensuring that data is relevant, secure, and compliant with regulations requires sophisticated strategies.
   
   
6. Environmental and Technical Limitations: Providing stable and scalable test environments that accurately mirror production settings can be technically complex and costly.
   
   
7. Flaky Tests and False Positives: Automated tests may sometimes return inconsistent results or false positives, which can undermine confidence in the testing process and cause real issues to be overlooked.
   
   
8. Keeping Up with Changing Technologies: The rapid pace of technological advancement means that continuous testing strategies must constantly evolve to accommodate new technologies and platforms, which can be resource-intensive.
   
   
9. Scaling Tests with Development: As applications grow in complexity, scaling testing processes without a corresponding increase in time and resources poses a significant challenge.

These challenges underscore the necessity of a well-thought-out continuous testing strategy that is adaptable, scalable, and efficient to support the dynamic nature of modern software development.

8 Tips to Optimize your Continuous Testing Strategy

Test automation strategy is the backbone of the final product that a business delivers. It should be strong and flexible enough to bear the impact of any change and every variable of the testing process. Let’s discuss how optimizing continuous delivery testing strategy helps improving the testing process and to increase the software quality: 

1. Complete Test Automation Strategy

Research indicates that many organizations tend to prioritize specific testing approaches—some focus on API integration and UI testing, while others may address these areas separately. However, a critical gap often exists in their lack of a detailed, automated continuous integration testing strategy that encompasses all these testing types. While selecting a particular testing method may be appropriate for certain business scenarios, it’s crucial for companies to develop a versatile testing plan. This plan should be capable of incorporating any testing type as needed. Understanding the distinctions and applications of continuous testing versus test automation is essential, given the varying scales and needs of businesses.

2. Streamlined Initial Test Process

Incorporating unreliable and overly complex test cases early in the development process can result in significant waste of time and resources, as QA teams are forced to engage in ineffective analysis of each code commit. To avoid this, it’s advisable for QA teams to start with a minimal set of test suites. This approach helps mitigate major risks while allowing for incremental adjustments based on the impact observed. Over time, the focus should be on gradually integrating more robust and stable test cases. In a DevOps environment, the quality of test cases is far more critical than the quantity executed. 

3. Choosing the best test automation tool

In building a comprehensive continuous testing strategy, choosing the right test automation tool is not just a requirement—it’s a cornerstone for achieving complete stability in your development process. It’s essential to select a tool that not only fits the technical requirements of your projects but also enhances operational efficiencies.   

One standout category in the realm of test automation tools is that which offers codeless automation alongside self-healing capabilities. Codeless test automation tools are designed to enable users to create automated tests without writing extensive lines of code. This approach significantly lowers the barrier to entry for team members who may not have traditional programming skills but are nevertheless integral to the testing process. It allows subject matter experts, business analysts, and QA professionals to directly contribute to test automation efforts. 

In a continuous testing environment, where quick iterations and frequent releases are common, the agility offered by a codeless, self-healing test automation tool becomes even more valuable. By automating tests without requiring extensive coding skills, teams can rapidly create and adapt tests to evolving application features and requirements. The self-healing aspect ensures that these tests remain valid and reliable over time, even as the application undergoes changes, thereby supporting a truly continuous approach to testing and development. 

Moreover, such tools can significantly reduce time and maintenance costs associated with the lifecycle of automated tests. They enhance the reusability of test scripts and ensure a higher return on investment by minimizing the need for frequent manual updates and intervention. 

By choosing a codeless automation tool with self-healing features, organizations can enhance their testing capabilities, accelerate their time to market, and ensure that their testing strategies can adapt to the dynamic nature of modern software environments.  

4. Modularizing tests

For complex integrated applications, modular testing offers an effective strategy to simplify and manage functionality. By decomposing the application into distinct modules, teams can create a clear roadmap that aligns testing processes with different workflows. Modular testing facilitates the organization and restructuring of tests by separating test data, test flows, and element locator mappings. This approach not only streamlines the testing process but also enhances the adaptability and maintainability of the test suites. 

5. Leveraging Automated Screenshots

Automated screenshots are invaluable for diagnosing the reasons behind test failures. They provide a visual reference that can be crucial for in-depth analysis of issues encountered during test execution. A robust automation tool should be capable of capturing screenshots at key interaction points automatically. However, not all tools support this feature. If your current test automation solution lacks this functionality, it may be worthwhile to consider switching to another platform that does, to fully benefit from the diagnostic advantages of automated screenshots. 

6. Optimizing Test Automation ROI

With the rise of continuous testing, automation, and DevOps, alongside the demand for faster delivery, the standards for quality software have significantly increased. Companies are striving to stay competitive by refining their testing and development strategies, all while keeping costs low. Managing test execution costs is essential. As testing scales up, the use of cloud resources becomes necessary, which can be costly. An effective strategy would be to differentiate between high and low-level testing requirements—conduct more complex integration and compatibility tests on the cloud, and run basic tests on-premise. This approach helps maintain a cost balance while maximizing automation ROI. 

7. Tracking and Monitoring

When development and operations teams collaborate, numerous operational challenges emerge. Developers aim to deploy updates swiftly, while testers focus on ensuring the reliability of service delivery. Bridging this gap requires continuous testing and integration within DevOps frameworks. To effectively manage these challenges, investing in system monitoring tools is crucial. These tools help identify the root causes of discrepancies and failures, enhancing overall efficiency. 

8. Benefits of Outsourcing QA

Outsourcing the QA process provides additional support, giving businesses a competitive advantage in delivering high-quality services. In the realm of continuous testing, outsourcing offers a significant boost by providing access to specialized areas such as impact analysis, performance, and security testing. This focused approach injects vital energy into specific phases of the development lifecycle, creating a mutually beneficial scenario for both developers and testers.

Continuous Testing and Delivery is not a luxury but a necessity in today’s era. A well designed continuous testing strategy is the foundation of continuous testing and quality service delivery. Although the journey is full of challenges if planned meticulously, the businesses would be able to streamline and reap the maximum benefits of test automation and continuous testing.

Comprehensive Test Coverage

Test your apps on 5000+ real device and browser combinations and ensure a complete test coverage.

 

Get a free demo

No comments yet

No comments yet

No comments yet

No comments yet

Testing framework plays a crucial role in the success of any automated testing process. Choosing the right test automation framework is important as it will maximize the test coverage and improve test efficiency which means a better return on investment.

There are some key points you need to keep in mind while choosing a suitable python testing framework. The framework should justify your testing needs and it should be easy to use. Check if the framework has integrations with other tools and frameworks that you might use. The features, support, stability, and extensibility are also important. So let’s compare the most popular python testing frameworks to make it easier for you to choose the right one.

Robot framework

It is still the most popular python testing framework that uses a keyword-driven testing approach and is used for acceptance testing. To run Robot you will have to install python 2.7.14 or any later version, python package manager, and a development framework like Pycharm.
Advantages

• Opensource
• Platform independent
• No need to learn a programming language to write Robot Framework test cases
• Automatic report generation after executing each built
• Supports behavior-driven, data-driven and keyword-driven approaches
• Easy installation

Disadvantages

• • Not enough support for parallel testing
  • It’s difficult to create customized HTML reports

Gauge

It is an opensource tool developed by the team that made Selenium. Gauge is immensely useful while integrating continuous testing in the CI/CD pipeline. It is gaining popularity as it supports many plugins like python runner, IDE plugins, build management, java runner, etc.
Advantages

• • • Quick defect detection
    • Easy to write test cases
    • Supports multiple programming languages
    • Command-line support
    • Supports all major plugins
    • Cross-browser tests can be automated

Disadvantages

• • • It is relatively new so it will evolve in the coming years

Pytest

Although Pytest is used for different types of testing, it is more preferred for functional and API testing. There are no prerequisites needed for Pytest, just knowledge of python will be enough to get started. It has a simple syntax which makes test execution easier.
Advantages

• • • Supports Fixtures and Classes that help in creating common test objects available throughout a module
    • It allows the use of multiple fixtures
    • It does not require a debugger
    • Xdist and other plugins support makes parallel execution easier
    • It supports parameterization, which is essential while executing the same test with different
    • configurations using a simple marker
    • Large community support

Disadvantages

• • • Test written in Pytest cannot be shared with other platforms

Pyunit

It is a unit testing framework much like Junit but for python language. Also referred to as unittest, it has five core modules. The test loader class is used to load all the test cases and test suites. The test runner shows the result of the test executed using an interface. The test suite is a collection of test cases that are clubbed logically based on the functionalities. A test case contains the actual implementation of the code and the test report contains the organized data of the test results.

Advantages

• • • No need for high-level python knowledge for test execution
    • Extensive report generation
    • Pyunit comes with Python package, no need to install any additional module
    • Simple and flexible test case execution

Disadvantages

• • • Requires boilerplate code
    • Pyunit is derived from Junit and so it still uses camelCase naming instead of snake_case naming method
    • It supports abstraction so the code intent sometimes becomes unclear

Behave

In Behave, test cases can be written in simple language and lets teams execute behavior-driven development (BDD) testing with ease. Behavior-driven development encourages quality analysts, developers, and business managers to work in collaboration to achieve higher efficiency.
Advantages

• • • Easy execution of all kind of test cases and easy coordination
    • Better clarity on the developers and testers output as the format of the spec is similar
    • Domain vocabulary that keeps the behavior consistent in the organization and the system behavior is expressed in a semi-formal language
    • Detailed reasoning and thinking promotes better product specs

Disadvantages

• • • Only for black-box testing

To sum it up

All the above-mentioned frameworks have their specialties like Pyunit is used for unit testing and Behave is good for behavior-driven testing. Although Robot framework is the best tool for a beginner to learn the nuances of automation framework. It’s always better to jot down your requirements based on their priority and then choose the right python testing framework.

No comments yet

Test cases are the first step in any testing cycle and are very important for any project. If anything goes wrong at this step, the impact gets proliferated in the entire software testing process. This can be avoided if the testers use proper procedure and guidelines while creating the test case template.

In this blog, I am going to share some simple yet effective tips which you could use for writing effective test cases. These tips will save you time and effort while optimizing the use of resources.

How to write test cases in a better way

Let’s have a look a the tips to write better test case template.

1. Detailed Domain Knowledge

Domain knowledge in information technology means deep knowledge of business and operational dynamics, the risks involved and the opportunities in that particular project. It is required to follow the best practices in the domain.

2. Break long test cases into many smaller ones

It is better to break the test case into a group of smaller ones if it has too many steps. It would be easier for the developer to backtrack and repeat the test steps if an error occurs somewhere in the test script. If not done than there are high chances that the developer will miss the bug.

3. Preconditions

Before starting on the test case it is suggested confirm all the assumptions that apply to the test and the preconditions that must be met before execution. There can be data dependency or the dependencies on the test environment or any other test cases.

4. Attach Artifacts

Relevant artifacts should be attached to the test cases. This can be done using a test management tool. At the time of product delivery, It will help to track the changes in the application. I will be easy to understand the flow of the function when there is a change at any step which will not be easy to relate otherwise.

5. Test data input

While writing a new test case a tester can share test data wherever applicable to be used for the Test Case within the test case description or add with the specific test case step. This will save time as there is no need to look for the test data anywhere else.

If the values are to be verified then testers can specify the value range or describe what values are to be tested for a particular field. Choose a few values from each class which will give good coverage for your test.
It’s better not to mention the real test data value but the type of data which is required to run the test. In projects where multiple teams use the test data and it keeps changing, mentioning only the type of data will be a wise choice.

6. Organize your work

Use a test management tool to manages your test cases instead of using a spreadsheet. There are many test management tools that can be used to organize the test cases in one place which will increase the productivity of the team.

7. Stop Assuming

It is better to refer to the specification document. Assumptions about the features or functionalities can lead to disagreements between the client and the developers. This gap between the client’s requirement and the application under development will impact the business.

8. Test Case Naming Conventions

To write tests which are easy to understand, we have to stop coding on autopilot and pay attention to the naming conventions. It is required to name our test classes, fields of our test classes, test methods and the local variables while writing automated tests for our application.

It does not matter which team member wrote the test, others will know what feature is tested under what scenario without even looking at the test code.

9. Meet Customer’s Requirements

If the testers miss a bug or write test cases that do not relate to the real world scenarios then it’s just a waste of resources and time. The goal is to meet the customer’s expectations and that can be attained only if the testers think from the users perspective.

10. Cover All Verification Points

It is important to write well-defined test case verification steps covering all the verification points for the feature under test. To make sure that the test Case covers all the verification points match your test case steps with the artifacts given for your project.

11. Avoid Repetitions

Do test automation when needed as it will reduce the manual effort and save a lot of time. The test scripts should be written in such a way that they can be used afterward for some other project.

12. Make it Reusable

Create test case template which could be re-used in the future by other teams. Also, before writing a new test case for your module, find out if there are similar test cases written already for some other project. Doing this you will avoid any redundancies in your test management tools. Call the existing test case in pre-conditions or at a specific design step if there is a need for a particular test case to execute some other test case.

13. All-Inclusive Test Coverage

Test cases should include all the features and functionalities mentioned in the software requirement. Requirement traceability matrix will help in finding the untested functions of the application.

14. Group Similar Test Cases

A test run is a collection of test cases that testers should execute in a particular order. Test cases are often grouped in test runs. It’s preferred to put preconditions at the beginning of a test run rather than inserting them into each test case.

Actually, only a few of the test cases need preconditions, so the field is often left empty. A test management tool will help to customize your forms and create a test case template which will save your time and effort when writing test cases. Another thing to keep in mind is to avoid writing the same instructions several times by moving repeated preconditions to a test run.

15. Easy to Understand

The test cases should be well defined with comments where ever needed so that any other software tester can work on it in the future. Whatever project you work on, when designing test cases, you should always consider that the test cases will not always be executed by the one who designs them. Therefore, the tests should be easily understandable and to-the-point.

In a scenario where the person who wrote all those test cases leaves for some reason and you have a completely new testing team to work with, the entire effort spent during the design phase could go down the drain.

16. Test Case Description

In the description, the testers need to mention all the details about what is going to be tested, what needs to be verified, the test environment and test data.

The information mentioned below should be there in a well-written test case description:

• Test to be carried out
• Testing tools
• Test Environment Details
• Behavior being verified
• Any dependencies like preconditions and assumptions
• Test Data to be used

17. Maintenance and Update

All the test cases should be updated with the new requirements so it’s easier to execute them in the future if there is a need. Even if some other tester wants to use the test case he/she wouldn’t have to go through the details of the script.

Conclusion

The tester needs to have good domain knowledge and should write presentable test cases from the users perspective. A good test case template will make it easier for testers to write good test cases. If there are only a few test steps, consider making a checklist instead and have a look at some relevant test case examples before working on your test case. A test case example will be helpful in creating test case templates too. A test management tool will definitely help in improving the way test cases are created and managed.

Related Articles:

• Audio Interaction Testing On Remote Devices
• Selenium Testing For Effective Test Automation
• 5 Benefits of Parallel Testing
• How to Measure the Success of End to End Testing
• Mobile App Testing Strategies

No comments yet

Appium Mobile Test Automation

As we all know that Appium is the most preferred test automation tool for mobile applications. It is the first choice of the testers because of its flexibility i.e. it is open source, it has the best supported and highly active community of experts, Appium works across different platforms and works well with different scripting languages. Even after gaining such popularity and having a strong community base, surprisingly, the users still make mistakes while running the mobile test automation with Appium.

Here are a few common mistakes that Appium users encounter while using Appium Mobile Test Automation Tool:

1.Unrestricted X Path Usage:

Over usage of X Path could be found in case of Selenium as well but when it comes to Appium world, it has more outrageous effects because X Path is a more dynamic way to unearth the elements. But the biggest stumbling block in this scenario is its huge performance cost due to which it becomes elusive an area. This is because Google and Apple do not provide XML or XPath related queries in a way we would need them to be. All of this hospitalizes an unmanageable cost finding elements using X Path. Undoubtedly, X Path is the most trusted method but there are several other better locator methods like ‘Accessibility IDs’ that can be used in this sitch.

2. Neglected usage of Accessibility IDs:

The accessibility ID locator strategy is formulated to read a unique identifier for a UI element. For both iOS and Android, getting an element by their accessibility ID is the best method. Most importantly, it is preferable because it is quicker. It should be noted that semantically accessible IDs are different than the Web IDs. However, the two shouldn’t be combined. In many cases, the accessibility IDs are used only for the purpose of testing even though they have a larger purpose. So, in order not to spoil the accessibility of the applications just for the sake of testing, the bigger purpose of the accessibility IDs should be known. If the accessible IDs are set up on the elements to make the apps testable, the app accessibility also increases, provided that the accessibility labels are sensible to the users using them. But the foremost criteria not to make automation efforts a failure is to make the application testable in the first place.

3. Not making a testable App:

Developing an app should be a forecasted move where in the developers, even before writing the first line of code, plan to develop an app keeping the automation in mind. This they can achieve by keeping in mind the hooks and the unique IDs for the elements in order to make the app more testable. This strategic approach would be a reason for a successful mobile app test automation. Apart from this, there should also be a concentration on the different testing scenarios in order to elude the chances of overlapping before even getting into Appium coding. An open discussion forum with the development teams to discuss the plotting of right accessibility IDs, labels or Unique IDs for the application’s elements would reduce many test automation reliability concerns.

4. Disregarding Application View States:

One of the challenge faced in Mobile Test Automation is not setting up the application. Most of the developers do not set up the application in order to access specific views and user states rapidly. To quote an example given by Jonathan Lipps,one of the key contributors to the Appium project.

A shopping cart functionality of the app might have ten different tests, and ninety percent of the tests might go through the same steps of logging in and searching items to be put in the cart which is a huge waste of time.

So, your team should be able to set up an app’s state and start the test in that apposite state, straightaway. This is highlighted in Appium scenario due to the fact that the mobile simulators and emulators are slow and take longer than usual to reach to the right position on the test.

5. Query for every element visibility:

Not querying for the visibility of every element is another way to speed up the run-time of the Appium test scripts. This leads to an additional load of calls and waiting time for Appium while in the every activity of retrieving an element. The lag can be reduced by only requesting the element attributes which are important in perspective of the test code.

6. Native Testing tools – Always better?

According to some developers, usage of the native testing tools is the best way to get unfailing mobile tests. For example- Espresso in case of Android and XCUITest in case of iOS. This is not good advice as neither of Google or Apple are going to release and new automation technology. When the question is of stability, the stability of code should be chosen rather than technology and in this scenario, Appium is the best choice!

As an exception, if the development team writes the tests and it’s most comfortable in mobile SDK language, using Google and Apple providers to build development environments. Also, when the constricted test-app or test code-app code integration is needed, then Appium might not be of much help. The utmost value is that Appium provides the WebDriver layer on top of the technology, which means the code can be written in any language and acts as a stable interface to that specific automation technology. Also, being a cross-platform tool, Appium allows to saves a lot of code and architecture in case of testing both iOS and Android devices.

7. Appium is slow:

Appium might be slower in some circumstances and also there are points in Appium codes where it does not seem efficient. Appium backs upon technologies that are slower than Appium and the curators of Appium have strategically chosen to utilize slower strategies for specific instances. For eg: Appium will certainly be slower if you are relying on XPath. The efficiency of the tool depends on how it is being used. Mostly, Appium is favored because of stability than the speed.

8. Not Using Appium Documentation:

The earlier Appium docs were not very user friendly. As a result, they weren’t used as much as they needed to be but the new Appium documents have been completely redesigned and reorganized. Information about the API reference to Appium, client libraries, supported drivers and Appium commands, code examples which was not provided before is all documented in the updated version. It deserves a revisit due to its newness and can be accessed at Appium.io.

9. Not creating reusable code

Repetitive or duplicate code can cause several issues for Appium mobile testing process. When the same code is repeated in several test scripts, any updates or modifications must be copied across all instances. This increases the chance of failures and complicates the debugging procedure. It also increases the maintenance cost for the organization.

Duplicate code makes identifying the primary reason for a test failure challenging. It can be difficult to pinpoint which occurrence of the code caused a test to fail if the same code is used repeatedly throughout several test scripts. This could increase the duration required for debugging the software and expand the market time.

Therefore, it’s crucial to use appropriate coding principles to prevent these issues. This includes creating simple reusable code, utilizing libraries and frameworks, and modifying code to remove redundancies.

10. Ignoring the Test-driven Deployment

Test-driven deployment is an Appium mobile test automation approach that stresses developing automated test cases before writing application code.

It lets the developer test all the application features before being deployed. This way, they can detect and resolve any bug in the early stage. This saves not only the organization’s time but also valuable resources.

Not just this, Test-driven deployment also helps developers in developing more reliable and enduring codes. By allowing them to understand the needs and provide a solution accordingly. Which lets them create more modular, maintainable, and error-free codes.

11. Choosing the right tool for API testing

APIs may have several endpoints, each with a unique set of parameters, methods, and authentication requirements. Writing and maintaining tests that accurately reflect the behavior of the API can be challenging due to this complexity.

Another difficulty is the requirement to simulate various scenarios and inputs. Testing for different response codes, error messages, and payloads might be part of this. To ensure the API can manage a high volume of queries, developers might also need to simulate load and stress testing.

Developers use a testing framework or library like RestAssured and Postman, which provides integrated support for API testing. These tools streamline and simplify the testing process by providing pre-build methods for common API testing scenarios, these tools streamline and simplifies the testing process. Alternatively, they can mimic various scenarios and inputs using mock data or a staging environment.

Developers can test their API in a safe setting before releasing it for production. Moreover, they can evaluate the API’s capacity by simulating heavy requests using load-testing tools like JMeter or LoadRunner.

12. Need to follow a good design pattern.

In Appium mobile test automation, the Page Object Model (POM) and the Page Automation Layer Model (PALM) are popular architectural patterns. Both techniques increase automated tests’ maintainability, scalability, and reusability.

POM is a design pattern that emphasizes the creation of reusable and modular code by isolating the application’s user interface from the test automation code, making it simpler to update tests when UI changes are made. POM builds an object repository that holds all the web elements and methods.
PALM is another design pattern that builds upon the principles of POM. But unlike POM, which focuses on UI elements, PALM emphasizes creating an abstraction layer between the test automation code and the application’s business logic. This approach distinguishes the test automation code from the underlying implementation. Thus making it easier to modify the test code without affecting the business logic.

No comments yet

Technology and innovation are two sides of the same coin. Technology is the power that lets the mankind turn ideas into reality within no time. At pCloudy, the power of innovation has led us to stay aligned and be in pace with the dynamics of the mobile app industry. We cannot afford to let our customers stay deprived of any technological advancements happening in mobile app testing. Once again we are back with another new feature called QR code scanner and we are proud to announce that it is already launched on our platform.
 
Nowadays many mobile applications use QR code scanners for a product or user identification. The QR Code scanning feature in pCloudy enables users to test the QR code feature through mobile applications on multiple devices present in pCloudy. This feature ensures the smooth functioning of the QR code function present in the mobile application. To use this feature, all you need to do is upload the mobile app under test, a QR code image file, and with the help of some simple steps, you can smoothly perform testing of the QR code scanning function of your mobile application.
 

The app will scan the injected QR code. You can scan multiple QR codes while testing your app on different mobile devices. So from now on you can easily perform QR code testing in pCloudy. This feature is supported on Android 5.0 devices and later versions. Supported QR Code file formats are .png,.jpeg and jpg.

Watch our video on QR code scanner feature:
 

No comments yet

Android uses a centralized system for all logs and application programmers can also write custom log messages. The tooling to develop Android applications allows you to define filters for the log statements you are interested in. Log analysis is a phase of development and developers encounter it from time to time. Bug log helps in identifying the bugs in the Android application while in the development phase. Once the app is released into the market, the support engineers analyze the bug logs to resolve the issue. There are for different types of Logs available in the Android Eco-System – Application Logs, Android System Logs, Event Logs & Radio Logs.

The logging system consists of a kernel driver and kernel buffers for storing Android log messages, C, C++ and Java classes for making log entries and for accessing the log messages, a standalone program for viewing log messages (logcat) and the ability to view and filter the log messages from the host machine (via eclipse or ddms).

There are four different log buffers in the Linux kernel, which provide logging for different parts of the system. Access to the different buffers is via device nodes in the file system, in /dev/log. The four Android log buffers are main, events, radio and system. The main log is for the application, events is for system event information, radio is for phone related information and system is low level system messages and debugging.

Each message in the log consists of a tag indicating the part of the system or application that the message came from, a timestamp (at what time this message came), the message log level (or priority of the event represented by the message) and the log message itself (detail description of error or exception or information etc).

What Each Android Log Type Contains:

1. Application log
use android.util.Log class methods to write messages of different priority into the log
Java classes declare their tag statically as a string, which they pass to the log method
The log method used indicates the message “severity” (or log level)
Messages can be filtered by tag or priority when the logs are processed by retrieval tools (logcat)

2. System log
Use the android.util.Slog class to write message with different priority with its associated messages
Many Android framework classes utilize the system log to keep their messages separate from (possibly noisy) application log messages
A formatted message is delivered through the C/C++ library down to the kernel driver, which stores the message in the appropriate buffer(system buffer)

3. Event log
Event logs messages are created using android.util.EventLog class, which create binary-formatted log messages.
Log entries consist of binary tag codes, followed by binary parameters.
The message tag codes are stored on the system at: /system/etc/event-log-tags.
Each message has the string for the log message, as well as codes indicating the values associated with (stored with) that entry.

4. Radio log
Used for radio and phone (modem) related information
Log entries consist of binary tags code and message for Network info
Logging system automatically routes messages with specific tags into the radio buffer

Device Logs on pCloudy Platform.

Device Logs Filter Options

Log format on Android
A common log format in android:

tv_sectv_nsec priority pidtid tag messageLen Message

tag: log tag
tv_sec&tv_nsec: the timestamp of the log messages
pid: the process id of where log messages come from
tid: the thread id
Priority value is one of the following character values, ordered from lowest to highest priority:

V — Verbose (lowest priority)*
D — Debug*
I — Info*
W — Warning*
E — Error*
F — Fatal*
S — Silent (highest priority, on which nothing is ever printed)

Log-File locations
There are several directories where Android log (including those from crashes) stores and it are not standardized (i.e. some may be ROM-specific). I am putting some of common here.
/data/anr : Dalvik writes stack traces here on ANR, i.e. “Application Not Responding” aka “Force-Close”
/data/dontpanic : contains some crash logs including traces
/data/kernelpanics :- Stores “kernel panic” related logs
/data/tombstones :- may hold several tombstone_nn files (nn is a number from 0 to 10 and after 10 again repeat it)

‘Log’ command line tool
To capture Android log from the devices/emulator Below is the some command line tool. In real life project there are log capture application/tool used to capture the logs on user device and shared it back to Developer/maintainer for analysis .
adb logcat (shows all type logs for current android system
adb logcat -v threadtime (it will include date and time)
adb logcat -v threadtime> logfile.txt (Store logs in logfile.txt)

Useful filter patterns
You can use below filter in your adb command to filter logs. You can also use this filter to search your logs file(Android logs provided by user device).
adb logcat -f Save all logs into a file
adb logcat “*:E” Get all errors and fatals
adb logcat | grep -i “foo.example.” #get all logs related to “foo.example.*” tagname
adb logcat “application_or_tag_name:*” “*:S” Get all logs by application name
adb logcat -b events “gsm_service_state_change” “*:S” Get all GSM state changes
adb logcat -b radio Get all Radio events

Log Analysis
In this blog we got the basic understanding of the Android Log System. While analyzing the Android logs from your app you can divide it in two parts, debug Logs – file coming during development and testing phase and production Log – file coming directly from end user. The best way to do it is by using useful Filter Patterns and by using Some Tool like GoogleLogTool and SonyLogTool.

No comments yet