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.

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


Three Simple truths in Software Development ~ from The Agile Samurai by (Jonathan Rasmusson)

Agile Testing


Three Simple truths in Software Development1. It is impossible to gather all the requirements at the beginning of a project.
2. Whatever requirements you do gather are guaranteed to change.
3. There will always be more to do than time and money will allow.

– Accepting the first truth means you are not afraid to begin your journey without knowing everything up front.- Accepting the second means you no longer fear or avoid change. You know it is coming.

– And by accepting the third, you no longer get stressed when your todo list exceeds your time and resources to deliver.

Once you accept these three simple project truths, much of the stress and anxiety traditionally associated with software delivery disappears. You are then able to think and innovate with a level of focus and clarity that escapes most in our industry.

Source: The Agile Samurai – How Agile Masters Deliver Great Software (Jonathan Rasmusson)

Just love this book.. This book is must read for Agile practitioners.

You can buy this book from Amazon: 


Why start testing Early?

Agile Testing, Better Testing, Testing Basics, Testing Tips | 1 comment


Introduction :
You probably heard and read in blogs “Testing should start early in the life cycle of development”. In this chapter, we will discuss Why start testing Early? very practically.Fact One
Let’s start with the regular software development life cycle:

When project is planned

 

 
  • First we’ve got a planning phase: needs are expressed, people are contacted, meetings are booked. Then the decision is made: we are going to do this project.
  • After that analysis will be done, followed by code build.
  • Now it’s your turn: you can start testing.

Do you think this is what is going to happen? Dream on.

This is what’s going to happen:

This is what actual happened when the project executes

 

  • Planning, analysis and code build will take more time then planned.
  • That would not be a problem if the total project time would pro-longer. Forget it; it is most likely that you are going to deal with the fact that you will have to perform the tests in a few days.
  • The deadline is not going to be moved at all: promises have been made to customers, project managers are going to lose their bonuses if they deliver later past deadline.

Fact Two
The earlier you find a bug, the cheaper it is to fix it.

Price of Buggy Code

If you are able to find the bug in the requirements determination, it is going to be 50 times cheaper
(!!) than when you find the same bug in testing.
It will even be 100 times cheaper (!!) than when you find the bug after going live.

Easy to understand: if you find the bug in the requirements definitions, all you have to do is change the text of the requirements. If you find the same bug in final testing, analysis and code build already took place. Much more effort is done to build something that nobody wanted.

Conclusion: start testing early!
This is what you should do:

Testing should be planned for each phase
  • Make testing part of each Phase in the software life cycle
  • Start test planning the moment the project starts
  • Start finding the bug the moment the requirements are defined
  • Keep on doing that during analysis and design phase
  • Make sure testing becomes part of the development process
  • And make sure all test preparation is done before you start final testing. If you have to start then, your testing is going to be crap!

Want to know how to do this?
Go to the Functional testing step by step page. (will be added later)