test techniques

TestOrigen Pvt Ltd's picture

Can I test an app on all devices without purchasing all devices?

Is there any way to test an app on all devices without purchasing all devices?

<em>No answers yet</em>
[article]

Endgame Testing: Exploring Your Agile Product End to End

Summary:
The main goal of endgame testing is to test the system end to end from the user's perspective. This should ensure continuity between components developed by different teams, continuity in user experience, and successful integration of new features. Endgame testing will often identify gaps that are difficult to discover inside agile teams, including flows across the product.

The main goal of endgame testing is to test the system end to end from the user's perspective. This should ensure continuity between components developed by different teams, continuity in user experience, and successful integration of new features. Endgame testing will often identify gaps that are difficult to discover inside agile teams, including flows across the product.

About the author

MIDHUN DAS's picture

Which is the best open source automation tool for desktop application testing?

MIDHUN DAS asked on September 12, 2017 - 3:00am | Replies (0).

I am in search of an open source tool so that I can automate testing of a Windows Desktop application.

 

<em>No answers yet</em>
[article]

Methods and Tools for Data-Driven API Testing

Summary:
Data-driven API testing can enable feedback much sooner and more often during development while being just as comprehensive as classic functional black-box testing. There are many methods of API testing, but that shouldn't intimidate you. Testers looking to advance their careers should consider learning some coding in order to test their programs at the API level.

Data-driven API testing can enable feedback much sooner and more often during development while being just as comprehensive as classic functional black-box testing. There are many methods of API testing, but that shouldn't intimidate you. Testers looking to advance their careers should consider learning some coding in order to test their programs at the API level.

About the author

[interview]

The Long Road to Test Automation: An Interview with Dorothy Graham

Summary:
In this interview, Dorothy Graham, a software test consultant and coauthor of four books, discusses the fact that many teams still have a long way to go with test automation. She explains why getting started in automation can be daunting and details which tools might be best for your testing needs.

In this interview, Dorothy Graham, a software test consultant and coauthor of four books, discusses the fact that many teams still have a long way to go with test automation. She explains why getting started in automation can be daunting and details which tools might be best for your testing needs.

About the author

[article]

Test Techniques for Today’s Telephones

Summary:
Telephones look very different today from when they were first invented, and their many capabilities and components make for some interesting test cases. Krishnan Govindarajan details his team's recent experience testing a phone, including its splitter, cloud backup, voicemail and answering machine, and VoIP, and gives some techniques to use when testing modern telephones.

Telephones look very different today from when they were first invented, and their many capabilities and components make for some interesting test cases. Krishnan Govindarajan details his team's recent experience testing a phone, including its splitter, cloud backup, voicemail and answering machine, and VoIP, and gives some techniques to use when testing modern telephones.

About the author

[article]

Start Trusting Your Test Automation Again

Summary:
The more you rely on feedback from your automated tests, the more you need to be able to rely on the quality and defect-detection power of these tests. Unfortunately, instead of being the stable and reliable guardians of application quality they should be, automated tests regularly are a source of deceit, frustration, and confusion. Here's how you can start trusting your automated tests again.

The more you rely on feedback from your automated tests, the more you need to be able to rely on the quality and defect-detection power of these tests. Unfortunately, instead of being the stable and reliable guardians of application quality they should be, automated tests regularly are a source of deceit, frustration, and confusion. Here's how you can start trusting your automated tests again.

About the author

Jo Rand's picture

End to End testing in Agile projects

Jo Rand asked on August 10, 2017 - 11:27pm | Replies (2).

I am interested in hearing your thoughts on how End to End testing across multiple applications could/should be managed across agile teams, where the teams are responsible for an application/system with integration with another application/system.

I'd be interested in knowing how other companies handle this from a strategic and project level.  Thanks

Praveen Chakravarthy D G's picture

As per me, it is a very critical topic for large agile programs that are executed. In fact if there are clear stories on interfaces and integrations, it can be kept in scope of a sprint and tested. Few more thougths from practical implementations

1. Add tasks in the beginning of the sprint keeping in view the interfaces that are available and can be tested.

2. I have actually added a parallel team that works on the items that slip or constrined to be part of sprint. This parallel team does the interface testing, non-functional, e2e scenarios etc. This parallel team had stories that need to be tested and validated before each program increment. Basically sprint teams work in sprint and these parallel teams works outside the sprint but with in program increment.

FYI - Prg inc. is nothing but set of 4 sprints together that delivers a meaningful module at the end of it.

Hope this helps if not ignore :-)

 

Justin Rohrman's picture

This depends on how the integration works. When I have done this in the past, one team was responsible for creating data in a specific format that other services could comsume. The other team was responsible for testing that their product could consume data in that particular format. We also found that it can be useful to have a task on the work queue for a person to spend some time testing how different products integrate. 

2 Answers
[article]

Reduce Regression Issues by Establishing a Mobile Automation Lab

Summary:
If you have a spotty test automation strategy, you may get lots of regression issues every time you have a new release for your mobile app. A mobile device lab to run regular regression tests could be the key. Here's a plan to get a mobile automation lab up and running, as well as some practices that can help reduce the number of regression issues and improve your overall app test strategy.

If you have a spotty test automation strategy, you may get lots of regression issues every time you have a new release for your mobile app. A mobile device lab to run regular regression tests could be the key. Here's a plan to get a mobile automation lab up and running, as well as some practices that can help reduce the number of regression issues and improve your overall app test strategy.

About the author

Dilusha K's picture

Is it a standard practice to start all the Test Case Heading from the word 'Verify'?

Dilusha K asked on August 5, 2017 - 6:10am | Replies (3).

Is it a standard practice to start all the Test Case Heading from the word 'Verify'?
Ex :
Verify show .................
Verify Create................
Verify Edit................

Stewart Lauder's picture

i personally always try and avoid using the word "verify" at any point when writing test cases, as it suggests we are "checking" and not "testing" - i tend to make my heading as a clear statement aligned to whats being tested

Zephan Schroeder's picture

Starting test cases with "Verify ", "Check that the ", or similar boilerplate prefix statement is somewhat common but is not at all a standard practice or even recommended. I personally find such static prefixes counterproductive. They diminish human ability to quickly scan a list or alphabetically recognize a group of tests. It takes up valuable mental parsing not to mention screen/paper real-estate. It adds no value to the reader IMHO.

I strongly recommend using a standardized test case naming convention focused on conveying summary info so familiar tester can run without opening the details. I help drive consistency with the following naming convention:

Test Case Title Naming Convention:  
<Feature>: <Initial State> <Action[s]>[,] [Expect ]<Expected result>

Examples:

  1. Homepage: Login as Admin user with a clean browser cache. Website authenticates and shows Admin user homepage (Admin menu + admin home content section)
  2. Homepage: Login as Normal user with a clean browser cache. Website authenticates and shows Normal user homepage
  3. Menus: Edit submenus each open successfully
  4. Menus: File submenus each open successfully
  5. Menus: Login as Admin user, menubar contains File, Edit, View, Links, and Administrator menus
  6. Menus: Login as Admin user, Admin submenus each open successfully
  7. Menus: Login as Admin user, Admin submenus each open successfully
  8. Menus: Login as Normal user, menubar contains File, Edit, View, Links menus (but no Admin menu)
  9. ...

Notice above are sorted alphabetically and provide easy sorted by Feature and then by initial state. 

QUIZ #1: Did you spot the duplicate test case? 
QUIZ #2: Can you quickly spot the gap in these high-level menu tests?
QUIZ #3: Is it easy to do parallel testing by assigning Admin user tests to one tester and Normal user tests to a different tester?

Test case titles can get long. You can use terminology, length limits, and other guidelines to produce consistent test titles that meet any additional restrictions. The point I want to emphasize is that test case titles get plenty long without adding filler words that add no actionable information.

OPEN QUESTION: Have you seen or used different test case title naming conventions or have other test case heading best practices? Comment here!

Sriharsha ng's picture

No. Although testers use Verify, Check e.t.c its all depends on how the test case title should sensible against the steps and expectations.

3 Answers

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.