Thursday, June 29, 2017

The Art to Create a Quality Product Backlog | Supreme Agile

The product backlog is probably the most important artifact in scrum, it contains a list of prioritized stories (description (High-Level) of the both the functional and nonfunctional requirements) that determines the work necessary to develop and deliver a working product. The product owner (PO) poses the responsibility to prioritize, managing and determine the best ROI for the customer.

תוצאת תמונה עבור ‪agile backlog‬‏

To make it even more easy for you to understand, I also want to add another definition created By Scrum Alliance:

The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities.

A healthy product backlog will include twelve main qualities that will help the team to achieve their goals to deliver an incremental version of the product per iteration.

Everyone is involved

Although the product owner has the main responsibility to add stories and maintain it, it does not mean that the scrum team is not allowed to add their own stories (Workflows, Technical debts Etc.). In addition, the scrum team should take a decisive part in the process of maintaining, managing and updating the product backlog.

Estimated

The product backlog stories should be created with a high-level estimation, that determined by the scrum team during the backlog grooming sessions or during the planning meeting prior to starting a new sprint.

The stories can be estimated both by Story points or days of work (Each version has its own advantages and disadvantages that I will not cover now).

Once all stories for a sprint are ready with estimations, the scrum team will have the knowledge to determine the amount of work and commitments they can take during the upcoming sprint.  

Flexible to absorb modifications

The product backlog is determined by the product owner that will determine the stories based on the Clint requirements, once the backlog is built with the first list of stories we should expect it to be flexible enough to absorb the stories modifications, new stories that are added and frequent changes in the prioritization.

Prioritized to achieve the best ROI for the client

All stories in the product backlog should be prioritized and develop in a specific order that will help the team to provide the best ROI for the customer, therefore the most important stories will receive the highest priority and implemented first.

The stories can be prioritized based on these four simple factors:

Costs - What are the costs that it will take to develop the story.

Risk – What is the amount of risk that it will take to develop the story and in addition what is the Risk that we will remove once it’s developed.

Uncertainty - What is the degree of uncertainty of developing this story.

Effort and Time – What is the effort and time that the team should invest to develop the story.

Visible and Accessible

The product backlog can be based on a dedicated application such as JIRA/TFS and sometimes even in the old fashion way of Paper-based backlog, once you create it, it should be visible and accessible to all stakeholders that are relevant to the project.

Epic, Features and Stories

To help the team achieving the project goals, the product backlog should be designed with a dedicated section for each type of this items, Features divided to Epics that are translated into informative, clear, small and realistic stories that the team can commit and deliver in each sprint.

Creating stories in that approach are the only way to help the team to deliver an incremental product at the end of each sprint, if the stories are too large, the team will fail to finish them in a single sprint, if the stories are not clear the team will constantly ask the PO questions during the sprint which consumes time, just remember that when you creating a new story in the team backlog.

Detailed in an appropriate level

As you know the product backlog is a container of user's stories that the scrum team will use during the iteration cycles, once the stories are added and prioritized, the team can understand which stories are more likely be implemented first, those stories that are prioritized in the TOP list should always contain more detailed than the stories that have a lower priority.

Wait! Although we will add more information in the TOP prioritized stories, it does not mean that we will write a full SRS doc, the story should contain a High-level description of the requirement and in some cases a reference to the specific part in spec/HLD.

Remember that there is no sense to invest the time and effort of the team to add this information because there is a great chance that those stories will be changed until they become (Or not) relevant in future sprints.

Independent Stories

The best way to work with stories is to make them independent, a good product owner will design the backlog stories in a way that will allow the team to accomplish each story at a time and with a specific logical order.

Contains different types of items

The product backlog contains stories that are reflecting specific client requirements, but in addition to that stories the team must add another type of stories that will not contribute directly to the product incremental release.

These stories are mostly written by the scrum team to reflect technical aspects such as investigation, Defects, Design, features and research that they will need to perform during the upcoming iterations.  

Proactively managed by the team

The product backlog should be Proactively groomed by both the product owner and the scrum team, the work should be done together with high collaboration and synchronization, new customer insights and requirements should be added, an hold and not relevant stories should be modified, this is the only way to keep your backlog updated and as a direct results it will reduce the time consumed in the planning meeting due to the fact that the team is familiar with the backlog stories and what it will take to accomplish them.

Know when to say NO!

The product owner can contain a mixed of requirements and technical stories, to keep the product backlog in a good shape, the product owner should know when to Decline/Approve new stories that are added from both directions (Customer/Team).

Without this ability, the product backlog will most likely be updated with stories that will affect the release goals and will make it more difficult for the team to deliver an incremental product at the end of each sprint.

Wait there is more, although the PO can say NO once the team/client want to add modified stories, he should perform it during a dedicated negotiation, each story should be discussed in a way that the other side can share is thoughts and explain why and how this story will help/contribute to the overall effort.

One product, one product backlog

It does not matter what is the scale of the project, we should always make sure that we follow the simple rule of one product is always managed in a single product backlog
To make more sense in that rule, I will add and say that there is a specific hierarchy that we can implement in enterprise projects:

Enterprise Backlog – The TOP backlog in the project hierarchy, contains a large-scale Features of the product, this backlog is managed by a dedicated product owner.

Area Backlogs – A backlogs created based on the features determined in the enterprise level, usually will contain EPICS that are just too large for developing.

Team Backlogs – This backlog containing small stories based on the EPIC stories created at the previous level (Stories that are added to sprints). 

Friday, June 16, 2017

The complete Checklist for Mobile Testing | David Tzemach

Overview

During the last few years we can see that the software industry is going mobile, we can see it in the massive app releases where thousands of new applications are becoming available for us per week and enterprise users will use their phones to connect remotely to their company's services such as Mail and file sharing.

I created this checklist that should be used as a baseline when testers need to deal with the increasing challenge of testing mobile applications. 

תוצאת תמונה עבור ‪mobile testing‬‏

Checklist


Preliminary Questions before starting the tests

  • What are the supported devices that we need to use in the testing process?
  • Do you have the hardware to support the tests (Real Device/Simulators)?
  • How do you think that people are going to use the application?
  • What is the code that was used to create the application?
  • What are the supported platforms that we need to use in the testing process (Symbian, iOS, Android etc.)?
  • Do you need to support tablets?
  • What is the application design?


Application interface

  • Validate that the application contains the company logo.
  • Validate that there are no spelling mistakes.
  • Validate all buttons and menus.
  • Validate all string and fonts.


Installation/uninstallation

  • Validate that you can uninstall the application.
  • Validate that you can reinstall the application.
  • Validate that you can install the application.
  • Validate that the application is not affected in a case of failure during the update process.
  • Validate that the user receives notification when the application is going to be uninstalled.
  • Validate that you notify when one of the predefined requirements (Disk Space, Permissions Etc.) is not fulfilled before the start of the installation process.


Application Updates

  • Validate that a new update will not affect the application performance.
  • Validate that the user receives only the relevant application updates.
  • Validate that the user is notified when a new update is available.
  • Validate that the application will support OS updates.
  • Can the user downgrade the System version?


Accessibility

  • Can the user manipulate the main functions using voice activation?
  • Validate that the color contrast can be changed.
  • Can the user use the Zoom in/out function?
  • Can the user change the size of the text?
  • What are the size screen buttons, will they allow the user to access the major functionalities?   


Security

  • Validate that the APP authentication process is secured (External Channels).
  • Validate that the default network that the application uses is secured.
  • How and where the application saves the user personal information?
  • How many log-in attempts are permitted prior to locking the app?
  • Validate that the user cannot access/modify the application files.
  • Validate that the application uses the relevant permissions.
  • Validate the application certificates (If relevant).
  • Validate that Device ID if used as an identifier.
  • The applications should not get access to the device information without the user approval.
  • Validate the user credentials before allowing him to access the App local information.
  • Validate that the user receives notification when he changes to unsecured network.
  • Validate that the APP is not storing any payment information (If it does, how well it's secured?).


Social and External connections

  • Can the user share the application data to external destinations (Files, Links etc.)?
  • Can the application be integrated with 3rd applications?
  • Can the user use the App to Log into remote services?
  • Can the user control the notification that he receives?
  • Test the integration between the app and different social networks (Twitter, Facebook etc.).


The Download Process

  • Can the user downloads the app at a reasonable time?
  • Is there any agreement/License that the user needs to sign/approve prior to download the application?
  • Validate that there is enough storage in the device prior to download the application.
  • Where is the source that the user can use to download the application (Website, AppStore etc.)?


Storage

  • What happens if the application cannot save data due to low space?
  • How the application beehives when the date is not accessible?
  • How the application beehives when the date is corrupted?
  • How the application backup and restore the user data?
  • What is the storage that the application uses to store data (Cloud, Local memory, SD card etc.)?


How the application handles interruptions?

  • Notifications from another application that is installed.
  • Connecting/Disconnecting the phone charger.
  • The User receives a Text message.
  • Music playing while using the app.
  • The User receives a phone call.
  • Switching between apps.
  • Voice mail notification.
  • System notifications.
  • Screen lock/unlock.
  • Battery warning.


Functional Testing

  • Validate that the application performs as defined in the requirements doc.
  • Validate that the user can start, Restart and close the application.
  • What is the expected behavior when the phone is locked?
  • Validate that the user can access all functions.
  • Validate that the user will follow the preliminary requirements prior to using the application (GPS, Wi-Fi etc.).
  • Validate that the application functionality on different orientation (Landscape/Portrait).
  • Validate that all functions will behave the same as used in a desktop version (If any).
  • Validate that the application displays informative errors in any case of failure.


Connectivity

  • Test the application with different networks (3G,4G etc.).
  • Does the Application interacts with the Device GPS?
  • Test the application with low connectivity.
  • Test the application with Airplane mode.
  • Test the application through a proxy.
  • Test the application with Wi-Fi.
  • Test the application with USB.
  • Test the application with NFS.
  • Test the application with BT.


Compatibility

  • Validate that the application can be used on different hardware versions.
  • Validate that the application supports different screen resolutions.
  • Validate that the application supports different time zones.
  • Validate that the application is multilingual.
  • Validate that the application can be used on different OS versions (Symbian, Android, Windows Mobile etc.).
  • Validate that the app supports different devices (Based on the predefined supported device list).
  • Validate that the application behavior is not affected when the user changes the Device settings.


Performance

  • Validate that the application is not consuming more memory than it should.
  • Test the application behavior with low memory in the device.
  • Test the application behavior with low CPU resources.
  • Validate the response time of the application.
  • In any case of performance degradation, you should display a notification to the user.

Friday, June 9, 2017

What is Equivalence Partitioning Technique? | David Tzemach

תוצאת תמונה עבור ‪equivalence partitioning‬‏

This Black-Box test technique can be used at any level of testing (Unit, Component, Integration and system). It is used to determine the set of valid and invalid inputs specified for the tested object and dividing it up into partitions of data inputs that according to the application requirements should behave the same when used as an input (the application behavior should be the same when tested with these inputs).

The main advantage of this method, is that it allows the tester to validate the tested object with a narrow set of test inputs because he will use a single condition from each class instead of all available inputs (remember that we assume that all inputs in a single class will behave the same, therefore we can test only single value).

The assumptions are:
If a single value from a class is working, then we can assume that all values of the class will work the same once used as input.

If a single value from a class is NOT working, then we need to validate the object with further inputs of the same class. 

Advantages
  • The probability of uncovering defects with the selected test inputs are higher.
  • We will cover different domain inputs (Valid/Invalid).
  • We will reduce the number of test cases.
  • We will reduce the testing time.

Disadvantages
There is one main disadvantage in ECP that you must remember, assuming in testing is a big mistake! Therefore, you should use this method wisely, and test more than a single value if you know that a specific area has more chances to trigger defects or when you know that there is a higher risk.  

So How can we use this method?
The tested object is an input field where the user needs to specify is age, the requirements are: 
  • The user can insert any number between 25 – 100.
  • The user can insert any number between 5 – 15.
  • The user cannot use negative numbers.

As you can see, we will not want to test all inputs that are available for testing; therefore, we will use the EP method to create the following partitions:

Class no'1: 25 <= Input <= 100 (Positive)
Class no'2: 5 <= Input <= 15 (Positive)
Class no'3: 16 <= Input <= 24 (Invalid)
Class no'4: Input > 100 (Invalid)
Class no'5: Input < 0 (Invalid)
Class no'6: 0 <= Input <= 4 (Invalid)

Now, all you need to do to validate the tested input field is to use one set of dates that belongs to each partition (six values in total), and you can see, we covered the main scenarios in 6 tests instead of running a large number of tests that will not add any real benefit/value to the testing effort.

Thursday, June 8, 2017

Selenium WebDriver - How to Identify Web Elements Using Selenium XPath (Text Method)

Sometimes, you will need to locate elements that do not contain any attributes, this issue will make it really difficult to locate those elements in the ordinary strategies.

To overcome this issue, we can use the XPath/CSS text methods that will help us to locate elements using a particular text value.

When using the text function, the locator query the element for its text content and if the element contains the relevant text, it will return the element.
תוצאת תמונה עבור ‪selenium webdriver‬‏


Code Examples


HTML:
<a href="http://www.machtested.com/p/blog-page_11.html">Quality Assurance</a>

Locating elements using exact text value

On the following example, we will specify the full text of the element which will be used by the XPath locator.

WebElement = Firefox.FindElement(By.XPath("//a[.='Quality Assurance']"));

Locating elements using the text function

The text () will return the full string of the element, and the "Contains" filter will validates if the requested string is matched to the search query.

Code:

WebElement = Firefox.FindElement(By.XPath("//a[contains(text(),'Assurance')]"));
Or
WebElement = Firefox.FindElement(By.XPath("//a[contains(text(),'Quality')]"));



My Presentations