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 »

I am speaking at the ‘World Test Engineering Summit’, Bangalore

I am pleased to announce that I will be speaking at the upcoming ‘World Test Engineering Summit’ being organised by 1.21GWs at Bangalore. It sure is an impressive lineup of speakers and I am glad to be a part of it! Check out the details of the event here-

https://1point21gws.com/testingsummit/bangalore/testengineering/

I will be speaking on –

“Layers in Test Automation – Best Practices for Separation and Integration”

About my topic –

Often a testing team consists of a mix of subject matter experts, some manual testers and testers with some automation experience. Writing tests in the language of the business allows all stake holders to participate and derive value out of the automation process. If you are a nervous beginner or an expert at test automation, you need to know and understand the layers of test automation and how to separate the code from the test. Let us discuss the best approaches and practices for creation of a robust automation framework with correct separation as well integration of these layers. We will also see a demo on how to implement this with a case study!

Also, Sahi Pro is partnering with the event and setting up a demo booth at the event! So, we’ll have our team there to showcase the capabilities of the unique tool and answer all questions.

Be sure to stop by the booth to chat and catch a demo!

Looking forward to a wonderful event! 🙂

Four Questions to ask yourself when planning Test Automation

Test automation poses its own challenges different from manual testing. Teams struggle to get the most out of their test automation due to many hurdles along the way.

Good planning can act as a solid foundation for your test automation project and help you fully reap the benefits. Consequently, there are many things to consider and discuss prior to jumping into test automation to ensure you are following the right path.

In my article published at Gurock TestRail Blog, I have discussed four main questions to ask yourself before starting with test automation-

  1. What is your team’s goal for test automation?
  2. What about implementation?
  3. What is your execution strategy?
  4. Who will focus on maintenance?

Read the full article here to find more on each of these questions and how these help to finalize on a test automation strategy which will help lead your team to success!

Please give this article a read and share your thoughts!

Cheers

Nishi

‘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