Redefined: Agile Testing Mindset & Role of an Agile Tester.

Agile Testing

Agile in Software Development is all about Value-Driven Development. Most of the Software Development companies are now following agile practices. Working in agile environment involves Continuous Learning, Discipline & Collaboration. A mind-shift is needed for testers to sustain Agile Teams:

Preventing the defects over Identifying the defects:

  • Rather than finding the defects, the focus of the tester should be on preventing defects and helping the team in delivering quality software which generates value for the customers.
  • Pair with the developers in the team and finalize the test scenarios. The idea is – Both team members (developers & testers) should ensure all scenarios are covered during development so that there should not be any surprises when the testers start testing.
Quality at Speed with Continuous Testing:
Principals of Continuous Testing:

Test early – to reduce the risks

Test often, faster and automate: Automate the tests so that tests get executes after every code check-in & get quicker feedback on the health of the software.

Continuous testing is required to reduce uncertainty and risks & achieve Continuously delivery

*Testers should think about ways to minimize the time spent on Manual UI testing and focus more on Continuous testing.

Be a Full Stack Tester:

  • Testers should keep growing their skills to match the new tech stack. How to test new technologies
  • Consider Non-Functional Aspects (Performance, Security, etc.)
  • Involvement in Design Discussions: Testers should understand the design, provide inputs on workflow, database design, test-ability so that unknowns can be identified as early as possible.
  • Understand the architecture: Testers should understand the architecture of the of software – the way it is designed how various layers are interacting with each other (UI, Database, API, etc.).
  • Learn – How testers can help in achieving continuous delivery (API, UI Automation & understand the who, what, when, why of Continuous delivery).
Moving from Quality Assurance toward Quality Assistance
  • The entire team is responsible for Quality. A tester assists the team in ensuring that a quality software is being developed. The Focus should be on how team members should help each other to meet the team goals/sprint commitments.
Testers should Desire continuous learning.
  • Always find better ways to work – Introspect and learn
  • Failures should be viewed as learning opportunities.

Hope this helps. We will talk more on these topics in details in upcoming posts.

Make Daily Stand-Up / Scrum Meeting effective

Project Management


Few tips to make your daily scrum meetings effective.First, let’s understand the goals of daily scrum meeting:
1. Allow the team to inspect and adapt daily.
2. Allow the team to share progress with each other every day.
3. Allow the team to surface blocks to each other every day.

Every day, at an agreed time and place, the team stands in a circle and reports three things:
1. What did I do since yesterday’s meeting? (These are Accomplishments)
2. What will I do by tomorrow’s meeting? (These are Goals)
3. What is blocking me or slowing me down? (These are Obstacles)

Sprint Team’s focus should be on the following-
– What we did/What will we be doing to meet the sprint goals.

– Remember that stand-up is not a place where you are giving your status to your project manager/scrum master. Its a ceremony where you are informing the team that how are you contributing to meeting the teams/sprint goals. DO not turn stand-ups into 1:1 chats with your managers. Whatever you say should generate some value for the team

There should not be any discussion hour debate on any features. Everyone should be in listening mode.

The stand-up duration should be 15 minutes maximum.

Hope this helps.


XPath for beginners | Selenium Automation Testing – Part 1

XPath for beginners | Selenium Automation Testing – Part 1

Uncategorized

Hey Guys, 

“XPath for beginners” articles are authored by our guest Megha Kharbanda. These awesome tutorials will help you to understand xpath from scratch.  

Part 1: About x-path and its basic syntax:

X-Path is used to navigate through web elements and attributes in an XML Document. From automation testing perspective (especially with selenium), xpath helps in identifying the web elements.

X-Paths can be created by:

  • Basic Syntax
  • Using AND & OR
  • Contains ()
  • Starts – With ()
  • Text ()
  • Following
  • Preceding
  • Ancestor


Basic x-path:

// : specifies that you want to search specific tag
Tagname: tag you are looking for
Attribute :  attribute in that tag
Value : value of that attribute
Example with a text field:
Consider a text field “Username”: Attributes of Username is:

The xpath of this field will be //input [@id = ‘username’]. Here @id will turn your focus on textbox
In case you do not have ID of the object:

EXAMPLE:  Attributes of a login button: 

xpath will be: //input [@value=’Login’]

Another example of xpath for image:

HTML Attributes of image is: 
< a title = ‘Powered by W’ href = ‘’http://www.wword.com’’/>
xpath will be: //a [@title = ‘Powered by W’]
If any attribute is not sufficient to identify a web element, you can take help of another element.
SYNTAX:  //tagname[@attribute1=’value1′] [@attribute2=’value2′]
Example: Attributes of a password field:

Since class is same for all textboxes on that page , so it is not sufficient to identify , therefore we take another attribute.
xpath will be: //input [@class = ‘input’] [@name = ‘password’]
It can also be used in this way:
Using OR in xpath: //input [@class = ‘input’ OR @name = ‘password’]
If any of the above can be true then it will identify the web element.

Using AND in xpath: //input [@class = ‘input’ AND @name = ‘password’]
Both of them has to be true in order to identify the web element.
In Part 2, we will explore advanced methods of xpaths.
Happy Testing,

Sprint Retrospectives – From Testing Team perspective

Agile Testing, Test Management


Retrospectives are carried out after every sprint. Basic purpose of this retrospective meeting is –

  • What went well – [Continue doing]
  • What didn’t went well – [Stop doing]
  • Improvement Areas – [Start doing]

Some common problems are seen across all teams –

  • Team members are not giving enough inputs in retrospective. How to get desired inputs from team members?
  • Improvement Areas are identified during retrospective, but How much improvement is made by team after each sprint? Answer is – Team does not know.
  • Retrospective meeting ended up in a blame game – Testers vs Devs. How to stop this?

In this post we will focus on problem 1: Team members are not giving enough inputs in retrospective. How to get desired inputs from team members?
There is a famous quote – if you don’t ask you don’t get. Similarly, if you don’t ask your team about right questions you will not get desired inputs from team. Manager/Scrum master need to go through all phases of the sprint and get inputs from team. Manager/Scrum master should ask following questions to the team:

Note –
1. You may need to tailor these questions as per your need.
2. I understand that in many projects, there are time limitations and all these questions are not asked to every individual in one meeting. In this case you can give this questionnaire to team in advance to that they can participate effectively in the retrospective.
3. In upcoming posts, we will discuss with we can automate most the points from following questions, so that you can get information from Test Management/Project Management tools you are using.

 

Requirement Analysis Phase:

  • Are you satisfied with time given for R&D?
  • Has all necessary trainings been provided?
  • Has major conflicts and impacted areas been identified?
  • Has functional and non-function requirements been taken into consideration?
  • Has query sessions planned with BA/Product Owner?
  • Are we able to understand the functional and technical design?
  • Overall – any Learnings/Challenges from overall from this phase?
  • Are you satisfy with the quality of requirements/user-stories? Any rejected requirements?

Test Case Writing Phase:

  • Did we meet TCW deadlines?
  • Are reviews done on time?
  • Are we able to complete TCW before the feature/functionality is delivered for testing?
  • Any major functionality related issues reported which are not covered in the test cases? [I understand that testers cannot cover all scenarios in test cases. However, it’s good to a count if issues/scenarios which are not covered in test cases. Will discuss the same in upcoming posts]
  • Overall – any Learning/Challenges from overall from this phase?

Test Planning & Control:

  • Estimations – Team members involvement in providing estimations? Has tem members been involved?
  • Planning meeting happened on time?
  • Test Lead/manager identified risks, planned leaves, etc and communicated to stakeholders on time?
  • Has team members identified risks (not meeting deadlines, etc) and communicated to stakeholders on time?
  • Have we consider functional and Non-Functional testing into consideration?
  • Has team able to meet deadlines?
  • Overall – any Learning/Challenges from overall from this phase?

Test Execution:

  • Test Execution (Functional Testing, Regression, Integration, Staging) completed on time?
  • Any challenges faced while running Automation testing (in case of automated regression)
  • Any cases missed?

Bug Reporting Quality:

  • Has testing team provided all required details in issue reports?
  • Count of invalid defects?
  • Has Impact analysis been done by testing team based on product knowledge? (A common pain-point of developers is – While reporting a bug, Testers write that “bug persists in xyz page”. However, then again the bug is reopened because of different page. So it’s very important for testers to write all possible pages/areas where the bug is occurring)

Overall Quality of application under test:

  • Any critical/complex bugs reports in later phase (which can be found and reported earlier)
  • Any issues reported from sprint demos which are not caught during testing?
  • Any concerns with the quality delivered by developers? Any straight forward blockers encountered during testing?

Communication & co-ordination:

  • Communication & co-ordination between – Test Team and Dev Team, Test Team and BA/Product Owner, Tester-Tester,
  • Enough collaboration happening between tester and developer to understand the Application/Feature design and Testing strategy.
  • Overall – any Learnings/Challenges from overall from this phase?
  • Any concerns with Daily Scrum meetings/Stand-ups? Completed on time? Are we able to focus on each person accomplished?

Others:

  • Test Environment stability?
  • Any issues with Builds and deployments?

For Scrum Master / Managers – So now, if you don’t get desired information in retrospective from team then do not blame the team. Make sure you are asking right questions to get the desired inputs from the team.
 
In Upcoming posts we will discuss the following:

  • Ways to measure the improvement made by Test team in each sprint?
  • Sprint Metrics & how to automate?
  • Stop blame game – Testers vs Devs. Self-managed Teams.

– Happy Testing


Test Mobile Readiness of any website | Mobile-friendly testing tool

Mobile Testing


Mobile Friendly Websites are the Future. Mobile ecosystem is growing and it is very important for website owners and companies who provide online services/products to support their products/services on mobile browsers. According to a Google Report:

  • More than 60% of users leave a website/service if it is not mobile-friendly.
  • More than 65% of users give preference to buy from mobile-friendly website.
  • More than 70% of users more likely to return to a website if it is mobile-friendly.
  • Around 48% gets frustrated if website is not mobile-friendly.

Here is the list of handy tools which will tell you whether a website is mobile-friendly or not:

1. Google’s Mobile Friendly Testing tool – https://www.google.com/webmasters/tools/mobile-friendly/ This tool analyse whether the page is mobile-friendly or not. It tells how Googlebot sees this page. Also give some improvement recommendations.

2. W3C Mobile OK Checker – http://validator.w3.org/mobile/ This checker performs various tests on a Web Page to determine its level of mobile-friendliness. The tests are defined in the mobileOK Basic Tests 1.0 specification – http://www.w3.org/TR/mobileOK-basic10-tests/

3. mobiReady – http://ready.mobi/ A free tool for developers, designers and marketers to test website performance on mobile devices. Also give detailed technical results and recommendations. I like this tool very much It gives detailed test results and visualization w.r.t various displays.

4. MobileTest.me – http://mobiletest.me/ It’s an online mobile site emulator. It gives you option to select device and run tests on it. Also gives options of Orientation (Portrait/Landscape) and Emulation (Responsive/Mobile)

My vote goes to Google Mobile-Friendly test tool & mobiReady.