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 »

Are You Driving Talent Away?

Regardless of size, your business can ill afford a high employee turnover rate. That’s because restocking on talent is costly, with Forbes reporting how hiring a replacement costs employers 33% of the outgoing employee’s annual salary. So, if an employee who earns $45,000 annually resigns, replacing them could cost the company $15,000. Crucially, it takes new hires 8–12 weeks to get up to speed and be at their most productive best, which means your business isn’t just losing money with high employee turnover — you’re also sacrificing productivity.

It goes without saying that employee retention is vital, especially in light of work-from-home setups making things trickier and a lot more challenging. That said, you might be driving away members of your team unknowingly, and adversely impacting your company’s bottom line.

As such, it is now time to take a long, hard look at your management style, and check if there are practices or company policies that might be pushing even your best employees out the door. In particular, you might want to determine whether or not you are guilty of the following, which are sure to tick off your team and get them looking elsewhere.

Setting Unclear Goals


Chron contributor Jim Woodruff details how employees respond favorably when they know clearly and concretely what the company expects from them. In turn, they are more likely to be enthusiastic about work, and in working towards those goals. Setting goals is particularly important in this era of remote work given the difficulties of communicating company objectives to offsite teams.

Without clear goals to guide them, employees working from home can grow easily distracted, and will be tempted to look for either greener pastures or something more fulfilling. Business writer James Gonzales highlights how when working from home, the days tend to melt into each other and can become monotonous. This makes it crucial to have goals for employees to keep them motivated, and working towards the attainment of concrete goals. Whether professional (as in a promotion) or personal (like skills development), these goals will keep your team engaged, and much more likely to stay.


Micromanaging


Micromanaging is a surefire way to drive a wedge between you and your employees. This is none truer than in remote working setups, where micromanaging — as in requiring hourly work updates and tracking hours — is generally misconstrued as a lack of trust on the part of management. Whether that’s true or not is moot, as the mere thought of it is enough to demotivate your employees, to the point of making them consider leaving.

Moreover, micromanaging can put undue stress on your employees, who have to deal not just with work, but also with your constant check-ins, nonstop instructions, and grating leadership style. This results in increasing stress levels that can cause burnout and a host of physical maladies that will severely compromise your employees health, until such a time that taking time off or resigning become their only options.

Here are some tips for employees and managers alike –

Ideas for Self-Care when working from home

Tips to keep your Sanity and Productivity Intact when working from home

Not communicating enough


While employees don’t want to be micromanaged, they don’t want to be left in the dark either. They want you to check up on them from time to time, and will appreciate it if you do. This is most true for remote teams, as bumping up communication, according to a previous post on telecommuting by Nishi Grover Garg, is one way you can show engagement and build connections with your employees.

Your failure to communicate, however, can cause friction, confusion, and frustration, as well as a lack of clear direction. It can even stress out your employees, with 4 in 5 Americans admitting to being stressed out due to poor office communication. Tellingly, a 2017 Gallup report underscores the need for better engagement, as it found that excellent workplace communication increases employee retention and productivity by 24% and 17%, respectively.

Here are some tips on Ways to Stay Engaged with your team when Working from Home

exclusively written for testwithnishi.com

by Rowena Jill

Rowena Jill is an entrepreneur and writer who is passionate about inspiring leaders to be better. In her spare time, she loves to bake and tend to her indoor garden.

Image Credits – https://images.pexels.com/photos/3874627/pexels-photo-3874627.jpeg


Defining Your Definition of Done

The success of your team and the release depends on everyone getting their individual parts done in time. But how do you define being “done”? What indicates a finished task and differentiates it from a half-baked one?

It is all about having a clear definition of done established and agreed upon within the team from the onset of the project. Check out my article published at https://blog.gurock.com/definition-of-done/ – Here I talk about some good ways to define your Definition-Of-Done

Brainstorm with your team

The person who is going to work on each task is obviously the best person to comment on how and when it will be closed. So, the first step would be to discuss and list the obvious things these people deem would need to be done in order to be able to say that their task is done. Sometimes, you may be surprised how different these “obvious” points may be for different team members.

For instance, Tester 1 may say that after executing tests on their user story, they also spend an hour doing exploratory testing before completing their testing tasks, while Tester 2 did not consider that as part of the task. They completed the test execution task once done with scripted tests and later, if time permitted, would perform some exploratory tests.

By doing this exercise you are baselining your expectations from each task, independent of its owners.

Consider quality goals

If you are seeking to come up with a definition of done, there is probably an area you are trying to improve and some quality goals you are trying to achieve, so consider them now. Think of what seem to be your team’s problem areas, or the source of their delays at the end. Now add a part of those quality goals in the relevant tasks.

For example, let’s say your builds seem to fail too often, and that leads to a lot of rework and retesting within the sprint. After some analysis, you found that the build failed because of developers checking in buggy code, mostly lacking integration tests.

Read More »

Ways to Stay Engaged with Your Team While Working from Home

Many software teams were forced to work remotely because of the onset of the global pandemic of COVID-19. Months in, most teams have now found their pace and made their peace with it. Hopefully, you’ve gotten comfortable and set a routine for yourself in your new work-from-home setup.

But are you engaging enough with your colleagues? Or are your conversations limited to virtual meetings and video calls? It’s important to have other ways of staying connected with your team.

As an organization, it is important to realize that however close-knit or small your team may be, not having a proper open channel of communication may make people feel out of the loop. In my article published at Testrail blog, I have discussed some tips on how to keep yourself and your team engaged when working from home.

Bump up communication

Before, it may have been enough for the manager to have one-on-one conversations with team members once a month, but our new remote situation calls for a little more. Managers should increase the frequency as well as the quality of the conversations they have with their teams. Strive to understand what teams are struggling with, remove their impediments, and ensure a smooth workday for each person.

As a team member, you too now have the responsibility to stay in touch with your peers more often. It is important for you to participate more in conversations with others rather than just being a spectator in your group chats or calls. A simple greeting and an update about what you are working on today is a good start that helps others peek into your day, and it increases the chances of their doing the same.

Provide clear directions

Managers and leaders need to focus now more than ever on setting up open lines of communication within teams. Give clear directions about what is expected of everyone, share what you feel about their work in the form of constructive feedback, and ask them their opinions. It is important to be empathetic and understanding and to have a listening ear.

In the middle of this chaos, it is important for people to have specific instructions, tasks, and goals so that they can focus on achieving objectives and have some structure to their days. Achieving these small tasks will make their time more productive and motivate them to get more done!

Read More »

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 »

4 Exit Criteria your User Stories must have

Planning and developing new features at the fast pace of agile is a hard game. Knowing when you are really done and ready to deliver is even harder.

Having predetermined exit criteria helps you be able to make the decision that a feature is truly ready to ship. In my article published at TestRail Blog, I compiled a list of exit criteria you must add to your user story to make it easy to bring conformity and quality to all your features.

All Tasks Are Completed

This first one sounds obvious, but it may not be. I still see many teams struggling with getting their testing done within the sprint. Developers work on a user story and deem it done, while testers are left to play catch-up in the next sprint.

Put that practice to an end once and for all by making sure that no user story can be proclaimed done without having all tasks under it completed, including development tasks, testing tasks, design and review tasks, and any other tasks that were added to the user story at the beginning.

Ensuring all tasks are completed in a sprint also mandates that you begin thinking in depth about each user story and the tasks necessary for each activity to be completed, so that you do not miss out on anything at the end.

Tests Are Automated Whenever Possible

As our agile teams move toward continuous delivery and adopting DevOps, our testing also needs to be automated and made a part of our pipelines. Ensuring that test automation gets done within the sprint and is always up to pace with new features is essential.

By having test automation tasks be a part of a user story delivery, you can keep an eye out for opportunities to automate tests you are creating, allocate time to do that within the sprint, and have visibility of your automation percentages.

I have used the following exit criteria:

  • At a minimum, regression tests for the user story must be added to the automation suite
  • At least 50% of tests created for the user story must be automated
  • Automated regression must be run at least once within the sprint

Depending on what your automation goals are, decide on a meaningful standard to apply to all your user stories.

Read More »

Raise your Exploration Game!

Exploration is an integral part of testing. Exploring the application is a great strategy for learning about how it works, finding new information and flows, and discovering some unique bugs too! 

Many testers perform exploratory testing as a matter of course, and agile teams may make it an integral part of their tasks. But how can you up your exploration game? Simply going around the application and looking or clicking here and there surely cannot be called creative exploration.

In my article published at Testrail blog, I outline what do you need to do to bring structure to your exploratory tests and get the most useful information out of them?

Image Source- xenonstack.com

Designate time for exploration

As we get into the flow of agile and its fast-moving sprints, we focus on testing tasks for each user story and are constantly thinking of what needs to be done next. But with minimal documentation and limited time to design tests, it is imperative to understand that just executing the written or scripted tests will not be enough to ensure the feature’s quality, correctness, and sanity.

Exploratory testing needs to be counted as a separate task. You can even add it to your user story so that the team accounts for the time spent on it and recognizes the effort.

Testers can use the time to focus on the feature at hand and try out how it works, its integrations with other features, and its behavior in various unique scenarios that may or may not have been thought of while designing the scripted tests. Having exploratory testing as a task also mandates that it be done for each and every feature and gives testers that predefined time to spend on exploration. 

In my testing days, this used to be the most creative and fun aspect of my sprints, and it resulted in great discoveries, questions, insights, and defects!

Read More »

Top Cross Browser Testing Challenges and How to Overcome them via Automation

Have you ever wondered how to successfully automate your cross-browser tests? With the number and type of mobile and tablet devices available in the market increasing daily and the crazy combination of browser types and browser versions making things even more complicated, if you are a website or web app developer then making sure your application renders and functions correctly on all those combination of browsers, devices and platforms is often enough to make you want to pull out your hair! Add things like compatibility and browser support for IE11 to the mix and things can get pretty tense. However, with the recent advancements in cross browser test accelerator technologies today we can perform these cross browser tests more reliably and more extensively than ever before.

Before we delve deeper into different approaches to automate your cross browser testing efforts, let’s first see what Cross Browser Testing is all about, why performing cross platform compatibility testing is often inadequate because of the various challenges associated with it, how to mitigate these challenges via test automation and finally, all the features to look for when comparing some of the best cross browser testing tools to automate such testing efforts.

What is Cross Browser Testing?

Cross Browser Testing is the type of testing where we verify to ensure that an application works as expected across different browsers, running on different operating systems and device types. In other words, by performing this type of functional testing a tester checks the compatibility of a website or web app across all supported browser types. Thus, by conducting specialized browser testing, you can ensure that the website / web app is able to deliver an optimal user experience, irrespective of the browser in which it is viewed or accessed.

Major Challenges with Cross-Browser Testing

Let us face it! Testing a web application across all major browser/device/OS platform combinations can be a seriously daunting task. One of the major pain-point with performing thorough Cross Browser Testing is that your testing team would have to test the same website or web application across all the different browsers, operating systems and mobile devices. This is when each browser uses their own different technology to render HTML. Mentioned below are some of the major aspects that make cross browser testing challenging.

1. It is IMPOSSIBLE to test in All Browser Combinations

Let’s assume that your contract with the client mandates that the website or web application being developed should support Chrome, Safari, Firefox, Opera, and Internet Explorer on Windows, macOS, and Linux operating systems. While this may rather seem a little too formidable at first, it actually is pretty manageable:

macOS: 4 Browsers (Chrome, Safari, Firefox, Opera)

Windows: 4 Browsers (Internet Explorer, Chrome, Firefox, Opera)

Linux: 3 Browsers (Chrome, Firefox, Opera)

That’s a total of 11 browser combinations.

But not all your end users are expected to be using the very latest version of each of these browsers. So it is often safe to test using at least the latest 2 versions of each browser.

macOS: 8 Browsers (Chrome, Safari, Firefox, Opera)

Windows: 8 Browsers (Internet Explorer, Chrome, Firefox, Opera)

Linux: 6 Browsers (Chrome, Firefox, Opera)


That’s a total of 22 browser types.

Now that we have taken the latest 2 versions of each browser type into consideration how about the latest versions of each OS? Surely, people upgrade their OS far less often than they upgrade their browsers, right? So to be safe, let’s test across the latest 3 versions of each OS platform.

macOS Catalina: 8 Browsers (Chrome, Safari, Firefox, Opera)

macOS Mojave: 8 Browsers (Chrome, Safari, Firefox, Opera)

macOS High Sierra: 8 Browsers (Chrome, Safari, Firefox, Opera)

Windows 10: 8 Browsers (Internet Explorer, Chrome, Firefox, Opera)

Windows 8.1: 8 Browsers (Internet Explorer, Chrome, Firefox, Opera)

Windows 8: 8 Browsers (Internet Explorer, Chrome, Firefox, Opera)

Ubuntu 20.04: 6 Browsers (Chrome, Firefox, Opera)

Ubuntu 19.10: 6 Browsers (Chrome, Firefox, Opera)

Ubuntu 18.04: 6 Browsers (Chrome, Firefox, Opera)


That’s a total of 66 browser combinations.

What started out as a manageable list is now already a substantial and daunting list of browser combinations to test against even for teams with a dedicated team of a good number of QA specialists. Add to the mix the possibility of testing across 32x and 64x variations of each OS type, testing across various possible screen resolutions and the fact that you’d need to retest across each of these combinations every time there is a bug fix, it is easy to feel frustrated and even give up!

Read More »