Introduction to ERP Testing and its Importance

<This is a guest post by Sohaib Zaidi>

In this era of cut-throat competition, global enterprises are facing tremendous pressure to enhance efficiency, reduce costs, increase sales and profitability. For this, more and more enterprises are embracing ERP (Enterprise Resource Planning) software. Apart from enabling enterprises to make accurate, informed and strategic decisions, ERP also helps them to stay compliant. Though the benefits of introducing cloud ERP solutions to your business are countless, yet these benefits come with several challenges.

Enterprises that have already embraced cloud are struggling to keep pace with the frequency of ERP software updates. ERP vendors like Oracle, SAP, Microsoft, Salesforce, etc are rolling out new releases and patches on monthly, quarterly, or biannually. Since cloud updates are rolled out at quick succession, enterprises are finding it hard to quickly test the updates and deploy these to production. Here arises the need of ERP testing

Why is it necessary to test ERP updates before deployment to production?

ERP updates bring new features and functionality, customer enhancement requests, and patches from previous releases. These updates need to be tested regressively since there are chances that they can impact a variety of functions that may cause disruption to business continuity. So, it is always recommended that before rolling out the ERP updates, QA teams should test critical business processes, validate reports, key workflows and test critical integrations with other applications.

Though manual application testing approach is still prevalent but it cannot be considered as a reliable solution in case of ERP testing. To understand this better, let us discuss an example of Oracle ERP. Oracle rolls out quarterly updates. These updates are first introduced to non-production environments. Oracle offers two weeks’ time to test these updates and raise issues. After two weeks, these get applied to the production environment. So, performing Oracle testing manually for these updates is non-feasible. Apart from time-consuming, manual testing is error prone, fragile and costly. Another disadvantage associated with manual testing is that it can adversely impact business continuity due to limited test coverage and its inability to identify change impact.

Embrace Automation Testing for seamless cloud adoption

Test automation not only reduces testing time of complex ERP systems but also ensures robust software quality. The biggest perks associated with test automation are maximum accuracy with minimum efforts, quick feedback, accelerated results, lower costs, and maximum coverage. Most of the test automation tools perform post release impact analysis to identify the impacted areas. Based on the impact assessment, QA teams can generate most relevant tests to execute validation. This not only defines the accurate testing scope but also delivers wider coverage which is not possible while performing manual testing.

When enterprises use test automation for security testing and constant maintenance, they get the opportunity to easily recognize defects. This approach significantly reduces vulnerabilities, helping enterprises to keep huge losses at bay. Automated testing also helps enterprises to overcome challenges of drowsy routine procedures crop up due to manual testing. Leveraging test automation tools, enterprises can accelerate routine procedures that consume time and cost to ensure a quick turnaround and superior ROI.

Author – Sohaib Zaidi – in his own words-
 
I am a technology enthusiast and professional writer with experience across niches like digital transformation, AI, IoT, & test automation. I love to write technology in simple tone so that readers can easily understand how embracing technology can deliver greater outcomes.    

Ways to Generate Quick Test Ideas

As testers, we look at everything with a critical eye. As soon as something comes up for testing, our instinct is to get down to examining it and looking for problem areas. After getting a written test script, a new tester would be tempted to begin executing scripted tests right away.

But stopping to gather our thoughts about possible test ideas first is a smarter approach that leads to better, more unbiased test coverage. However, we don’t always have a lot of time to imagine scenarios and different paths. Luckily, there is always some planning we can do beforehand.

In my article published at Gurock Testrail blog I shared some tips for generating test ideas in a time crunch.

Revisit classic test techniques

Our old, trusted test design techniques like boundary value analysis, equivalence class partitions, decision tables, and state flow diagrams are always a help when thinking about test cases. Although most of them are ingrained in the thought process of a tester and are mostly common sense, giving them a revisit, however informal, may still give us some more test ideas.

For example, creating a quick decision table for the interaction of two or more variables to observe the behavior of the system may reveal some unique combination that we might have missed. Or a quick boundary value analysis for the age field in our we form may show us a special case we might have missed.

Similarly, using state transition diagrams to draw end-to-end flows can help not only the testers, but also the developers in imagining the overall system flow and revealing problem areas.

Look at the history

The history of the project or the system can give us many insights into what we are dealing with, where the common defect clusters are, and the most problematic components.

If you are new to the test team, start by having a look at the defect tracking from past sprints or releases. You can then define and think of more test cases based on past defects and the components that have had the greatest number of defects.

If you’ve been part of the team for a while, you are probably intuitively bound to focus on these areas. But even then, it will help to consciously make an effort to list the most common types of bugs encountered and most problematic areas based on your experience. This will help not only you, but also your new and junior team members. Read full post->

Read More »

4 Tips to Create a Simplified Test Plan for Your Agile Project

Planning is an integral part of initiating any project or activity, including software testing. Although formal test plans may seem outdated and unnecessary to most fast-paced agile teams that prioritize cutting down on documentation, it’s still a good idea to keep a pared-down test plan that can guide the testing effort throughout the project.

In my article published on TestRail blog, I talk about four useful tips to create a simplified test plan for your agile project.

1. Include the basics

A test plan can be as detailed as the team requires, but at the minimum, it must contain the context, timelines, and a brief overview of the testing activities expected to be performed in the project, release, or sprint.

Based on what level of test plan you are creating, begin with a basic heading, like schedule and timelines, testing activities and types of testing expected to be performed, people involved in testing, or any new hires or training required for the project or release.

2. Build off the project plan

Most of the test plan can be derived from the context set by the overall project plan, so give that a thorough read and get the details of the project lifecycle, expected delivery schedule, interaction points with other teams, etc.

Note any specifics that emerge, like shared resources with other teams, sync points for integration tests throughout the project’s lifecycle, or special types of testing needed, like performance, load or security testing.

3. Define a clear scope

Let’s say your project is a mobile application that needs to work on both Android and iOS. It would be beneficial to list all the environments and OS versions that need to be supported. Including them in the test plan ensures you set up the test environments early and allocate testing tasks across all of them. It also ensures that you are not bogged down by repeated testing on numerous test environments at the time of release. What is not defined in the initial test plan can automatically be considered out of scope.

Continue Reading ->

4. Use visual tools like mind maps

A simple Agile Test Plan using a Mind map

Read full article here

Continuous Testing in DevOps

Agile testers need to constantly rethink their processes and tooling in order to move toward faster and more reliable software delivery. The key there is to embrace the continuity. Continuous delivery is necessary for agile development, and that cannot happen without having continuity in testing practices, too.

In my article published on TestRail blog, I discuss the various aspects of Continuous Testing in DevOps-

Continuous testing

Continuous testing can be defined as a methodology focused on continuous quality and improvement. It can use a number of practices and tools to help do that.

Continuous testing encompasses the verification and validation of each piece of the software under development to ensure:

  • Code quality — Are developers creating code of good quality?
  • Application correctness — Are developers creating the correct features?
  • Place in the pipeline — Can the application code flow through the pipeline and across environments and specified tests successfully and easily?
  • A good customer experience — Are users seeing value in the delivered application?

Continuous testing is the way toward continuous delivery. Teams that struggle with continuously delivering on time or with high quality often find the solution to their problems by setting up good continuous testing practices.

Read the full article for some tips to improve your continuous testing framework and help your DevOps succeed, like-
  • Ensure test automation is the best fit
  • Leverage automation benefits in all aspects
  • Select the right tools
  • The Typical Pipeline & what it requires

Continue Reading ->

Agile teams must strive for continuous improvement of their continuous testing strategy. If they’re successful, they can reduce their release times from months or years to weeks or days (or even hours!). By adopting the correct practices and embracing the spirit of continuous learning and improvement, we can help our testers to become champions of agile.

<Image Credits – manufacturingchemist.com>

My Contribution to the eBook ’21st Century Skills for Software Testers’

I am proud to announce another one of my contributions made its way to the eBook titled ‘21st Century Skills for Software Testers‘. This initiative was started by Emna Ayadi and Ard Kramer asking for contributions from various testers on their thoughts about the essential pivotal skill sets that benefit software testers.

🚀 This bilingual book made by software testers is all about:
How we apply 21st-century skills:
🔸 Critical thinking
🔹 Communication
🔸 Collaboration
🔹 Creativity
and also how we are going to use these skills in the future.

#21stskills4testers

This was a great initiative to bring together thoughts of many great testers from around the globe. There are some great pieces featured and a number of things to learn. I am super excited to feature in not one but Two sections in there –

Check out what I wrote in the First section of ‘Critical Thinking’ – Section 1.1.15 ‘Stories of Testers from the Present’ and Section 1.2.8 ‘Imaginations and Thoughts of Testers’

Find the eBook here -> https://leanpub.com/_21stskills4testers And you can download the book for free (fill out 0 dollars)

Glad to be featured along with so many awesome people from around the globe!

I am grateful for the opportunity and always welcome more such chances to contribute my thoughts for the betterment of the testing community!

Cheers

Nishi

Is Test Automation Alienating Your Business Testers?

With numerous test automation tools and frameworks available today, many in the software testing industry are focused on learning them all. It is important to stay updated with new technology. But are testers losing something in the race to become more technical and equipped with automation skills?

In my article published at TestRail blog, I examine ways to see if your test automation is becoming so technical and code-intensive that it’s in danger of alienating the subject-matter expert testers who best know the core of your business?

Technology should serve people

It is important to understand and remember that test automation tools have been designed to make testers’ lives easier and better. They are not intended to replace testers or overpower them. They make tests execute faster, with more accuracy and fewer errors, so if they eliminate anything, it is redundancy and repetitive work. This technology is meant to serve testers — to save their time and effort and give them more freedom.

To this end, the first intent behind adopting any technology must be its fitness for use in the project, not its popularity in the market. The skills needed to adopt the tool and begin using it in the project should be easily obtained by hands-on learning or training. Read full article ->

Testing is creative

Testing is a creative job, and it always has been. The advent of new tools and technology has not changed this fact. Tools can do part of a tester’s job, but they still cannot test. Although some people may argue on behalf of artificial intelligence and machine learning that can take over many actively creative aspects, we are not there yet. We still want and need a human to capture the creative tests, discuss the pros and cons of design aspects, peer-review test cases, and report problems.

Everyone can contribute to test automation

When we look at testers’ resumes, the tendency is to look for tools they can work with. But the more important skill we need is their ability to contribute to test automation in one way or another. We cannot judge this fact just by asking if a person is able to write test automation scripts or knows a certain programming language. They may be able to learn the Gherkin format to design and write feature files for Cucumber tests. Or if you decide to adopt a keyword-driven framework, they could pick up the keywords and begin writing tests so that the same test cases can double as test scripts.

Read More »

Read Along- ‘Agile Testing’ Chapter-18

“Coding and Testing”

  • The beginning of coding is a good time to start writing detailed tests.
  • As testers think of new scenarios to validate with executable tests, they also think about potential scenarios for manual exploratory testing. Make a note of these for later pursuit.
  • Some quick risk analysis can help you decide what testing to do first and where to focus your efforts.

The Power of Three Rule – When unexpected problems arise, you may need to pull in more people or even the entire team. Tester, Developer and Customer (or businesspeople) can together decide on correct behavior and solutions.

Explore It!

As soon as testable chunks of code are available, and the automated tests that guided their coding pass, take time to explore the functionality more deeply. Try different scenarios and learn more about the code’s behavior. You should have task cards for tests that critique the product both business and technology-facing. The story is not ‘done’ until all of these test types are done.

If your exploratory tests lead the team to realise that significant functionality was not covered by the stories, write new stories for future iterations. Keep a tight reign on “Scope Creep” or your team won’t have time to deliver the value you originally planned.

Technology-facing tests that critique the product are often done best during coding. This is the time to know if the design doesn’t scale or if there are security holes.

  • MANAGING DEFECTS
  • Leaving bugs festering n the code base has a negative effect on code quality, system intuitiveness, system flexibility, team morale and velocity.
  • Strive for “zero tolerance” towards bug counts.
  • Teams have solved the problem of how to handle defects in different ways.
    • Some teams put all their bugs on task cards
    • Some teams chose to write a cared, estimate it & schedule it as a story.
    • Some teams suggest adding a test for every bug
  • The more bugs you can fix immediately, the less technical debt your application generates and the less ‘defect’ inventory you have.
  • Try making the estimate for each story to include (atleast) two hours or half a day for fixing associated bugs.

If a bug is really missed functionality, choose to write a card for the bug and schedule it as a story.

Code produced test-first is fairly free of bugs by the time it is checked-in.

  • The Daily Stand-Up helps teams maintain the close communication they need.
  • Use Big, visible charts such as story boards, Burndown charts and other visual cues to help keep focus and know your status.
  • Having story boards gives your team focus suring the stand-ups or when you are talking to someone outside the team about your progress.

Communication

  • Testers can help keep the iteration progressing smoothly by helping make sure everyone is communicating enough. They can help programmers and customers find a common language.
  • Use retrospectives to evaluate whether collaboration & communication need improving and brainstorm ways to improve.
  • Teams in different locations have to make a special effort to keep each other informed.

Build Process

  • Teams take different approaches to make sure their build stays ‘green’.
  • The build needs to provide immediate feedback, so Keep It Short.
  • Tests that take too long, such as tests that update the database, functional tests above Unit level or GUI test scripts, should run in a separate build process.
  • Having a separate, continual ‘Full’ build with all of the regression suites is worth the investment.

During the iteration, you are automating new tests. As soon as these pass, add them to the Regression Suite.

As you start the iteration, make sure that test environments, test data, and test tools are in place to accommodate testing.

You may have brought in outside resources for the iteration to help with performance, security, usability or other forms of testing. Include them in stand-ups and discussions. Pair with them to help them understand the team’s objectives. This is an opportunity to pick up new skills!!

  • Consider what metrics you need during the iteration – Progress and Defect Metrics are 2 examples.
  • Whatever metrics you choose to measure – Go for Simplicity!

Read Along- ‘Agile Testing’ Chapter-17

“Iteration Kickoff”

  • Most teams kickoff their new iteration with a planning session. – where they discuss one story at a time, writing & estimating all of the tasks needed to implement it.
  • Task cards need to be written along with development task cards and estimated realistically.
  • When writing programming task cards, make sure that coding task estimates include time for writing unit tests and for all necessary testing by programmers.
  • Testers should help make sure that all necessary cards are written and they have reasonable estimates.

Your job as a tester is to make sure enough time is allocated to testing and to remind the team that testing & quality are the responsibility of the whole team. When the team decides how many stories they can deliver in an iteration, the question isn’t “How much coding can we finish?” but “How much coding and testing can we complete?”

Commit Conservatively – It is always better to bring in another story later than to drop a picked story.

  • Working closely with customers or customer proxies is one of the most important activities as an agile tester. Good communication usually takes work.
  • We want “big-picture” tests to help the programmers get started in the right direction on a story. High level tests should convey the main purpose behind the story.
  • Don’t forget to ask the programmers what they think you might have missed. What are the high-risk areas of the code? Where do they think testing should be focused?

When Testability is an issue, make it the team’s problem to solve.

One beneficial side-effect of reviewing the tests with programmers is the cross-learning that happens.

High level test cases along with executable tests you’ll write during the iteration will form the core of the application’s documentation.

People unfamiliar with agile development often have the misconception that there’s no documentation. In fact, agile projects produce usable documentation that contains executable tests and thus, is always up to date.

Tips to write better Bug Reports

Writing defect reports is a constant part of a tester’s daily life, and an important one too! How you report the bugs you find plays a key role in the fate of the bug and whether it’s understood and resolved or ends up being deferred or rejected.

It is imperative for every tester to communicate the defects they find well. In my article published at TestRail blog, I discuss four simple tips to help you write better bug reports.

Study past bug reports

If you are new to your team or new to testing itself, the best way to learn about good bug reporting is to read the team’s past bug reports. Try to understand the bugs and see if you could reproduce them. 

By doing this exercise you learn the best way to present bugs so that the team can understand them. You’ll get a feel for the business language and the project’s jargon to be able to describe features and modules.You may also see some imperfections in the past reports, so you can think about how to improve them and what other information would be useful to include.

Create your own game plan

Create a shortcut for yourself, like writing down a summary or title of each bug you find as you go about testing and saving the screenshot. When you get down to reporting, you can quickly fill out the steps, as well as expected and actual results, and attach the saved screenshots. Doing this could be faster and save you the effort of repeating steps just to get the needed screenshots and logs. Continue Reading–>

Read More »

Read Along- ‘Agile Testing’ Chapter-9

“Toolkit for Business-Facing Tests that Support the Team”

  • As agile development has gained in popularity, we have more and more tools to help us capture and use them to write executable tests.
  • Your strategy for selecting the tools you need should be based on your team’s skill set, the technology your application uses, your team’s automation priorities, time, and budget constraints. Your strategy should NOT be based on the latest and coolest tool in the market.
  • In agile, simple solutions are usually best.
    • Some tools that can help us illustrate desired behavior with examples, brainstorm potential implementations and ripple effects and create requirements we can turn into tests are—
      • Checklists
      • Mind maps
      • Spreadsheets
      • Mockups
      • Flow diagrams
      • Software based tools
  • A picture is worth a thousand words, even in agile teams. Mock-ups show the customer’s desires more clearly than a narrative possibly could. They provide a good focal point to discussing the desired code behavior.
    • Visuals such as flow diagrams and mind maps are good ways to describe an overview of a story’s implementation, especially if it is created by a group of customers, programmers, and testers.
    • Tools such as Fit (Framework for Integrated Tests) and FitNesse were designed to facilitate collaboration and communication between the customer and development teams.
    • Finding the right electronic tools is particularly vital for distributed teams (chat, screensharing, video conferencing, calling, task boards etc.)
    • Selenium, Watir and WebTest are some examples of many open source tools available for GUI testing.
  • Home-Brewed Test Automation Tools
    • Bret Pettichord (2004) coined the term ‘home-brewed’ for tools agile teams create to meet their own unique testing needs. This allows even more customisation than an open source tool. They provide a way for non technical customer team members to write tests that are actually executable by the automated tool. Home-brewed tools are tailored to their needs, designed to minimize the total cost of ownership and often built on top of existing open source tools.

The best tools in the world won’t help if you don’t use them wisely. Test tools might make it very easy to specify tests, but whether you are specifying the right tests at the right time is up to you.

Writing detailed test cases that communicate desired behavior is both art and science.

Whenever a test fails in Continuous Integration (CI) and build process, the team’s highest priority should be to get the build passing again. Everyone should stop what they are doing and make sure that the build goes ‘green’ again. Determine if a bug has been introduced, or if the test simply needs to be updated to accommodate intentionally changed behavior. Fix the problem, check it in, and make sure all tests pass!

Experiment – so that you can find the right level of detail and the right test design for each story.

  • Keep your tests current and maintainable through refactoring.
  • Not all code is testable using automation but work with programmers to find alternative solutions to your problems.
  • Manual test scenarios can also drive programming if you share them with the programmers early. The earlier you turn them into automated tests, the faster you will realise the benefit.

Start with a simple approach, see how it works, and build on it. The important thing is to get going writing business-facing tests to support the team as you develop your product.