ezeetester

Archive for the ‘test case’ Category

Gamifying life of a software tester using AI/Machine learning

In Automation, Games, test case, Tools on August 15, 2022 at 8:06 am

The life of some software testers simply seems to

1. Open their machine, look at instructions open a tool and

2. Start executing test cases (which are either written by them or by someone else) repeatedly

I have seen many testers simply having a routine, and executing the same tests – especially the ones that cannot be automated (sometimes several). This is so demotivating!

A pragmatic appraisal of several things can lead to a solution.

Gamifying testing – make testing habit forming.

How? While we may not have tons of content for a machine learning algorithm we do have some test cases as a dataset. However each test case can be subjected to tons of tiny variations, a simple change in settings, to change in a tester’s/user’s behavior towards the app. Each and every change in setting/different behavior can be used to make a recommendation to the tester to be tried out. A good natural language algorithm should do the trick.

Rewards: Tester can be rewarded for various reasons ranging from attempting to execute a recommended test just as it happens in many engaging, habit forming apps. Giving them some points, rewards, badges, certificates etc.

The situation should be something like, the tester opening the gaming app – the application recommends a test case with some variation/technique.

Hope it becomes habit forming. Can we make one such app? Are you game?

One more expected result to your test case

In Automation, Expectation management, Software Testing, Software testing training, test case, test case design, test case template, Uncategorized on May 23, 2020 at 3:30 pm

One of the most common test cases that we see is

Test Step: 

  1. Launch the url of the app under test
  2. Enter valid credentials in the login and password fields
  3. Click Login

Expected result: User should be able to login

Alright, you just have one expected result.  Is that all there is to it?

The answer is a big NO.

As testers we need to have a 360 degree view.  One part of which is to look at the logs just for the login test written above

The expected results could contain the standard apis, and any ‘stuff’ that should  be running in the backgound for the login feature.

Unfortunately, most of us look at logs only when we see a bug.

Automation can definitely help for a lot of test cases.

Manually, for High priority cases to start off with.