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 »

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 »

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 »

Top 3 New Year Resolutions for Testers!

Here we are gearing up for another new year! As time flies by, we may start to feel stuck in one place, unable to move forward in our careers. Testers can get bogged down by too much to learn, too many directions to take, and so many tools and technologies.

But that’s no reason to stagnate. By making some goals now, you can aim to start improving yourself and your career development right away on January 1st.

Here are three goals testers should have for the coming year. Make it your New Year’s resolution to achieve them, and go for it with an action plan in hand! Read the full article at –> https://blog.gurock.com/new-year-resolutions-testers/

Improve your Mindset

The first resolution should be to create and maintain a healthy mindset. Mental peace and team harmony should be the goal.

Continue Learning

There must be a routine, a drive to better oneself and a constant search for improvement. All testers must resolve to take up some kind of continuing education so they can always be adding to their skill sets. Learning cannot be a one-time activity.

Get Better at Networking

The next resolution a tester must make is to participate in the community in some way.
The knowledge you have is better shared with others, and the pace of learning in a community will be much faster than alone.

Read More —>

Mental Health for people in tech

The technical industry is characterized by high stress, long work hours as well as workplace pressure. This demanding environment blurs the line between your professional and personal life.

Your mental health suffers a lot in the constant social pressure to network and make a name for yourself. Here, are certain ideas to implement at your workplace to take care of your mental health.

Speak your mind

Speaking your mind can help you maintain your mental health. Don’t consider sharing your feelings as a sign of weakness; it’s a part of taking charge of your wellbeing.

Though it’s hard to talk about feelings at work, but if you have colleagues you can talk to, it can really help. Find your tribe at work who can be your peers with whom you can share your day to day problems, issues and seek advice, or open up with family and friends outside work.

Identify triggers

Everyone has different triggers for anxiety in the workplace. It could be doing a presentation or writing reports or going to a company function. You must track situations that make you uncomfortable in order to prepare.

Read More »

Making the case for Usability Testing in Agile

My first experience with usability testing was on an agile team where the product we were building was being designed with the help of an in-house usability expert. He helped design the user interface (UI) of the application and conduct usability study on the beta version of the software to determine the ease of use of the application.

Though the experience was limited in terms of the interaction we had with the user representatives and the sessions conducted, the feedback we received opened up lots of new avenues for the tester in me around the learnability, understandability and attractiveness of the application I was testing.

Usability has matured a lot over the years. It’s now an essential software characteristic in today’s web and mobile applications. In my article published at the TestRail blog, I discuss ways of performing Usability tests and developing a mindset for Usability in an agile context.

https://blog.gurock.com/usability-testing-agile-projects/

We also discuss about Usability Study , how to set it up and achieve maximum benefits from it.

To read the complete article — (opens in a new tab)”>Click here –>


Prevention is the Best Cure- for Defects in Agile

The agile methodology focuses on building in quality from the very beginning of the software lifecycle. That is why we aim to find and fix defects early on: A defect found and fixed in an earlier lifecycle phase is a multitude cheaper than the same defect at a later stage.

But how can we more easily make it possible to prevent defects from percolating deeper in the software development lifecycle by fixing them in their nascent stages?

This is the main theme of my latest article for @Gurock TestRail blog – where I explore and explain ways to foresee, analyze and thwart defects in an agile context.

The main points discussed are-

Communication

Conduct Reviews

Demonstrate Often

Static Analysis and CI

Click Here to read the complete article –>

Please support by liking / commenting and sharing the article!

Cheers

Nishi

Look Back to Plan Forward – Learnings from 2018

Every year we see the software industry evolving at a rapid pace. This implies changes in the way testing is conducted within the software lifecycle, test processes, techniques and tools, and the tester’s skill set, too.

I’ve been into agile for more than a decade, and I’m still learning, changing and growing each year along with our industry. Here are five of my key lessons and observations from 2018. I hope they help you in the coming year!

https://blog.gurock.com/lessons-for-agile-testers/

In my article published on Gurock blog, I talk about the 5 key learnings for Agile testers from the past year and how they will be key in planning your road ahead in 2019. The key learning areas discussed are —

Testing Earlier in DevOps

Getting Outside the Box

Increasing Focus on Usability Testing

Enhancing Mobile and Performance Testing

Integrating Tools and Analyzing Metrics

Click Here to read the complete article — >

‘Just Enough’ documentation in an Agile Project

Agile poses many challenges to the development team, most of them pertaining to time. Teams are perpetually under pressure to deliver working software at a fast pace, leaving minimum time for anything else. When testing on an agile project, learning how to write lean documentation can save precious time. Furthermore writing lean documentation can help rework efforts by focusing only on what’s really necessary.

The Agile Manifesto emphasizes working software over comprehensive documentation, but most agile teams interpret this wrong and treat documentation as something to be avoided, owing to time constraints. The manifesto states a lesser focus on comprehensive documentation, but some documentation is still needed for the project and any related guidelines being followed. Attaining this balance is a challenge.

Documentation is a necessary evil. We may think of it as cumbersome and time-consuming, but the project cannot survive without it. For this reason, we need to find ways to do just enough documentation — no more, no less.

Read about how to focus on important areas like VALUE  , COMMUNICATION and  SUFFICIENCY when documenting in your agile project – in my article published at Gurock TestRail blog –> https://blog.gurock.com/lean-documentation-agile-project/

just enough

Click here to read the full article

For example, in a traditional test design document, we create columns for test case description, test steps, test data, expected results and actual results, along with preconditions and post-conditions for each test case. There may be a very detailed description of test steps, and varying test data may also be repeatedly documented. While this is needed in many contexts, agile testers may not have the time or the need to specify their tests in this much detail.

As an agile tester, I have worked on teams following a much leaner approach to sprint-level tests. We document the tests as high-level scenarios, with a one line description of the test and a column for details like any specific test data or the expected outcome. When executing these tests, the tester may add relevant information for future regression cycles, as well as document test results and any defects.

More examples and scenarios for learning leaner test document creation are included in the full article– Click here to read the full article

 

                 Are you interested in finding the right tool for your Agile processes? Here is a comprehensive assessment and comparison of the best agile tools available! 

https://thedigitalprojectmanager.com/agile-tools/

Prepared by Ben Aston, this list may be a useful guide for finding and selecting the best tool to support your agile journey. Check it out!

 

Happy Testing!

Nishi

The 12 Agile Principles: What We Hear vs. What They Actually Mean

The Agile Manifesto gives us 12 principles to abide by in order to implement agility in our processes. These principles are the golden rules to refer to when we’re looking for the right agile mindset. But are we getting the right meaning out of them?

In my latest article for Gurock TestRail blog, I examine what we mistakenly hear when we’re told the 12 principles, what pain points the agile team face due to these misunderstandings, and what each principle truly means.

 

Principle 1: Our Highest Priority is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software

What we hear: Let’s have frequent releases to show the customer our agility, and if they don’t like the product, we can redo it.

The team’s pain points: Planning frequent releases that aren’t thought out well increases repetitive testing, reduces quality and gives more chances for defect leakage.

What it really means: Agile requires us to focus on quick and continuous delivery of useful software to customers in order to accelerate their time to market.

Principle 2:

Check out the complete post here —- Click Here to Read more–>

 

Do share your stories and understanding of the 12 Agile Principles!

Cheers

Nishi