Search

Agility In QA Mindset Is A Key To Success In The Agile Era

Whenever it comes to Agile software development methodology, there are a few Manifesto and Agile Principles that comes to the mind.As we can see, Agile completely believes in“Customer Satisfaction, feedback loop, team collaboration, quick delivery, embracing change request, trust and support, face to face communication, working software, sustainable development, continuous attention, mentioning the simplicity, self-organizing team, reflect and adjust.”The intent behind coming up with Agile looks quite interesting.A quick view on Waterfall modelLet’s talk more from a QA standpoint. As we know, traditionally, in the Waterfall model of Software development workflow would typically look like this.In the traditional software development approach, the complete software development process is splitted into different phases. The output of one phase is acting as a Input for the next phase. This indicates that any phase is incomplete if the previous phase is not completed. That is the reason, the waterfall model is called a sequential model. In sequential approach, the phases flow towards the downward direction through the phases of Requirements, Design, Implementation, Verification, Maintenance as shown in figure above.  In traditional software development process, requirement would be frozen during the initial phase followed by which development of software would begin. Hence, Software testing life cycle will typically look like this-So a Qualitative Analyst (QA) would follow the below workflow-Requirement understanding -> Brainstorming -> Writing Test Scenario -> Writing Test Cases -> Verification -> ReTesting of defect (if any)The above workflow makes sense in the world of Waterfall model. However, with high Agile acceptance in the industry, a shift from Waterfall to Agile Mindset is required. In case of implementing QA Mindset for achieving Agile Manifesto, more of a ‘Shift-Left’ testing is embraced. The entire team is highly involved right from the  Requirement understanding phase to Delivery/Maintenance phase.So the bifurcation between the Software Developer and QA is not there in a team which truly follows Agile. The entire team works together towards a defect tracking instead of finding them and verifying during the verification phase.Steps Towards Developing QA Mindset for Successful Agile ManifestoLet’s talk more from Ground 0 now.During the Grooming phase, Developer and QA pair up with each other and come up with their set of understanding and discuss among themselves around the requirement. Once the brainstorming is done, a list of Open questions are posted to the client for clarification around the same.Post Grooming, the Sprint planning phase kicks in, wherein, based on the answers given by the client, the teams have a better visibility around the requirement. Hence, realistic estimates are given for the User Stories inclusive of Development/Quality Analyst/Business Analyst pairing.Post Planning, the QA starts with writing Test Scenarios/Cases activity. During the course of documentation, QA and Developer team collaborate with each other to ensure they are on the same page. In case of any scenarios that were missed by either of the team, they take care of the same during the Coding/Documentation phase itself. It helps in eliminating the late defect cost.Once the developer is done with Coding and is about to get started with dev testing, a QA member pairs up with the Developer to ensure things are working as expected at a high level.Once the Code is ready and is deployed to QA environment, QA starts with the end-to-end verification of the story. Hence, the possibility of discovering a defect decreases exponentially.QA in Waterfall vs. QA in AgileIn the Waterfall model, QA used to get appreciated based on the number of defects that were found during the verification phase. As a result, somehow teams use to work in a silo which would result in the change of the entire codebase, sometimes the architecture itself. As a result, cost of project would go up significantly as described in the below image.On the contrary, in case of a team which follows Agile truly, a Developer/QA gets appreciation based on Minimal code changes and less number of defects found. There is a high acceptance of Shift-left testing in the industry because of the amount of benefit it has brought in terms of effort saving for rework.So, Agile Testing is not a unique way. It needs to integrate successfully QA Mindset into Agile Manifesto. It is a kind of change in the mindset which does not happens overnight. Along with that, it requires knowledge, skill-set, and proper coaching. Hence, a shift in the Agile QA mindset is required to ensure a high throughput from a team. This article is focused on changing a mindset to Agile by providing the tips for implementing QA Mindset into the Agile Manifesto.Please share your thoughts in the comment section, we can connect on LinkedIn and talk more. If you enjoyed this post, it would be great if you’d help it spread it to your connections on LinkedIn or other channels.
Rated 3.5/5 based on 2 customer reviews

Agility In QA Mindset Is A Key To Success In The Agile Era

655
  • by Suraj Sharma
  • 07th Aug, 2018
  • Last updated on 11th Dec, 2018
  • 4 mins read
Agility In QA Mindset Is A Key To Success In The Agile Era

Whenever it comes to Agile software development methodology, there are a few Manifesto and Agile Principles that comes to the mind.

As we can see, Agile completely believes in

“Customer Satisfaction, feedback loop, team collaboration, quick delivery, embracing change request, trust and support, face to face communication, working software, sustainable development, continuous attention, mentioning the simplicity, self-organizing team, reflect and adjust.”
The intent behind coming up with Agile looks quite interesting.A quick view on Waterfall model

Let’s talk more from a QA standpoint. As we know, traditionally, in the Waterfall model of Software development workflow would typically look like this.
In the traditional software development approach, the complete software development process is splitted into different phases. The output of one phase is acting as a Input for the next phase. This indicates that any phase is incomplete if the previous phase is not completed. That is the reason, the waterfall model is called a sequential model. In sequential approach, the phases flow towards the downward direction through the phases of Requirements, Design, Implementation, Verification, Maintenance as shown in figure above.  

In traditional software development process, requirement would be frozen during the initial phase followed by which development of software would begin. Hence, Software testing life cycle will typically look like this-
So a Qualitative Analyst (QA) would follow the below workflow-
Requirement understanding -> Brainstorming -> Writing Test Scenario -> Writing Test Cases -> Verification -> ReTesting of defect (if any)
The above workflow makes sense in the world of Waterfall model. However, with high Agile acceptance in the industry, a shift from Waterfall to Agile Mindset is required. In case of implementing QA Mindset for achieving Agile Manifesto, more of a ‘Shift-Left’ testing is embraced. The entire team is highly involved right from the  Requirement understanding phase to Delivery/Maintenance phase.

So the bifurcation between the Software Developer and QA is not there in a team which truly follows Agile. The entire team works together towards a defect tracking instead of finding them and verifying during the verification phase.

Steps Towards Developing QA Mindset for Successful Agile Manifesto
Let’s talk more from Ground 0 now.

During the Grooming phase, Developer and QA pair up with each other and come up with their set of understanding and discuss among themselves around the requirement. Once the brainstorming is done, a list of Open questions are posted to the client for clarification around the same.

Post Grooming, the Sprint planning phase kicks in, wherein, based on the answers given by the client, the teams have a better visibility around the requirement. Hence, realistic estimates are given for the User Stories inclusive of Development/Quality Analyst/Business Analyst pairing.

Post Planning, the QA starts with writing Test Scenarios/Cases activity. During the course of documentation, QA and Developer team collaborate with each other to ensure they are on the same page. In case of any scenarios that were missed by either of the team, they take care of the same during the Coding/Documentation phase itself. It helps in eliminating the late defect cost.

Once the developer is done with Coding and is about to get started with dev testing, a QA member pairs up with the Developer to ensure things are working as expected at a high level.

Once the Code is ready and is deployed to QA environment, QA starts with the end-to-end verification of the story. Hence, the possibility of discovering a defect decreases exponentially.
QA in Waterfall vs. QA in Agile

In the Waterfall model, QA used to get appreciated based on the number of defects that were found during the verification phase. As a result, somehow teams use to work in a silo which would result in the change of the entire codebase, sometimes the architecture itself. As a result, cost of project would go up significantly as described in the below image.
On the contrary, in case of a team which follows Agile truly, a Developer/QA gets appreciation based on Minimal code changes and less number of defects found. There is a high acceptance of Shift-left testing in the industry because of the amount of benefit it has brought in terms of effort saving for rework.

So, Agile Testing is not a unique way. It needs to integrate successfully QA Mindset into Agile Manifesto. It is a kind of change in the mindset which does not happens overnight. Along with that, it requires knowledge, skill-set, and proper coaching. Hence, a shift in the Agile QA mindset is required to ensure a high throughput from a team. This article is focused on changing a mindset to Agile by providing the tips for implementing QA Mindset into the Agile Manifesto.

Please share your thoughts in the comment section, we can connect on LinkedIn and talk more. If you enjoyed this post, it would be great if you’d help it spread it to your connections on LinkedIn or other channels.

Suraj

Suraj Sharma

Blog Author

Suraj Sharma is working as a Full Stack QA Engineer with leading IT farm and is striving for bringing change in Industry. Strong believer of "Learning or Decaying" mantra. Technology explorer, Blogger and part-time cyclist by passion. Connect with him on LinkedIn.

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

How To Pass Leading SAFe® 4 Exam ?

Scaled Agile Framework is a roadmap that leads the organizations in implementing the Lean and Agile Practices. SAFe® includes the three foundational bodies of knowledge that are System Thinking, Lean Product Development, and Agile Software Development. It helps the organizations to improve themselves according to the business requirements, deals with challenges involved in developing and delivering ideal software and systems within a specified time. SAFe® practices are essential but, sometimes they can be complex and entail some challenges. It might be easy to deal with such challenges and move your enterprise towards SAFe® practices by becoming a professional SAFe® Agilist. Passing a SAFe® Agilist Certification exam proves that you are an expert in implementing Agile and improving the project you want to get involved in.Here, in this article, we will guide you through your Leading SAFe® 4 exam preparation.Firstly, the 2-day Leading SAFe® 4.6 training is the most crucial part of this certification. Join the course and ask all the doubts you have during the workshop without any hesitation. Make a note of all the important things which will be helpful for future references. After completing the course successfully, you should pass the exam to obtain SAFe® Agilist Certification.Exam DetailsFormat of the examThis is a web-based, timed, and closed book exam that will be conducted in English and delivered in the format of multiple choice questions. Upon completion of the Leading SAFe® training, candidates will get access to the exam within the SAFe® Community Platform. Candidates will have 90 minutes to finish the exam once it starts.The exam consists of 45 questions in total and you must answer a minimum of 34 questions correct out of 45. You can take the exam at any time and the fee for the first attempt will be included in the course registration fee only if the exam is taken within 30 days of course completion.Retake policy of the examIf the certification exam is not cleared in the first attempt, you can retake the exam again and again, but each retake costs $50.You can take the second attempt immediately after the first attemptYou need to wait for a minimum of 10 days to retake the exam for the third timeA minimum of 30-day wait is required to retake the exam fourth timeCandidates are not allowed to retake the exam, once they got a minimum passing score of 76% unless there are updates announced to the exam.Exam preparationThe exam is specifically designed to analyze the skills and knowledge of a particular candidate. Develop a study plan before going to take the exam.Here are a few important points you should remember-You should gain both practical and theoretical knowledge in order to pass the exam successfully.The course materials are more helpful to prepare for the exam and we at KnowledgeHut offer course materials authored by the Scaled Agile Academy. These materials can be used for referring the concepts that are presented during the training.Take the practice tests that are designed with the same level of difficulty, time duration, and the same number of questions. You can take the exam without any additional cost. The practice tests once completed, let’s you know the chapters you should study more in pink color. Study those topics again.  As a preparation, on scaledagileframework.com, on the big picture (framework) click on the words if have confusion/not sure and read the guidance article. It makes you prepare well for the main certification exam and boosts your confidence level.Choosing a right path takes you to important destinations in your career. Becoming a SAFe® 4 Agilist is a career path for many and it requires an excellent range of skills. The best institute guides you towards a bright career. So, choose the right and best institute that is authorized to do so and can help you reach your goals.
Rated 4.0/5 based on 15 customer reviews
3843
How To Pass Leading SAFe® 4 Exam ?

Scaled Agile Framework is a roadmap that leads the... Read More

Agile Project Management Vs. Traditional Project Management

In this fast-moving world, project management has become one of the most important pillars that are helping businesses run without any glitch in their processes. Both small and large scale organizations around the world are exploiting technology and depending on project management systems to deliver the software development project successfully. Whether it is team workflow management or timing, these tools help to ensure that everything is going well without any obstacles. While there are tens of different project management approaches, Agile is considered one of the most practical and flexible software development mechanism that exist today. It is capable of executing a variety of tasks, but what sets it apart from others? Let’s find it out. Here’s a brief comparison of Agile management and traditional project management software:                                                                                                                    Traditional vs Agile Project Management Overview of Agile and Traditional Project Management What is Traditional Project Management? The traditional Project Management (waterfall) approach is linear where all the phases of a process occur in sequence. Its concept depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure above. The entire project is planned upfront without any scope for changing requirements. This approach assumes that time and cost are variables and requirements are fixed. This is the reason why traditional project management faces budget and timeline issues. What is Agile Project Management? When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile management gives prominence to teamwork, customer collaboration, and flexibility. It is an iterative approach that focuses more on incorporating customer feedback and continuous releases with every iteration of software development project. The basic concept behind Agile software development is that it delves into evolving changes and collaborative effort to bring out results rather than a predefined process. Adaptive planning is perhaps the biggest feature of Agile and one that makes it a crowd favorite among project managers. Scrum and Kanban are two of the most widely used Agile frameworks. They are very well known for encouraging decision-making and preventing time consumption on variables that are bound to change. It stresses customer satisfaction and uses available teams to fast-track software development at every stage. The table below shows the major differences between Agile project management and traditional project management.                                                                                Table: Agile project management vs traditional project management Why is Agile Preferred and why not the traditional project management? Agile is preferred by most developers and managers because of a variety of reasons. Let’s have a look at the most common ones: Project complexity Traditional: This method is the best fit for small or less complex projects as it follows linear approach. Sudden changes in the project or any other complexities can block the entire process and make the team go back to step one and start all over again. Agile: This is the best methodology to follow in case of complex projects. A complex project may have various interconnected phases and each stage may be dependent on many others rather than a single one as in simple projects. So, Agile methods are preferred for large complex projects, as they can respond better to such structures. Adaptability Traditional: This approach works with a belief that once a phase is done, it will not be reviewed again. So, it is not adaptable to rapid changes in the work plan. In case if any sudden situation arises or any change in the requirements from the client’s side, traditional approach fails to adapt to the new change. The only choice is to start from the very beginning once again. This wastes a lot of effort and time in the process. Agile: The adaptability factor is very high in this methodology since it is not linear. Complex projects consist of several interconnected stages, where a change in one stage can cause an effect on another. And the project managers can take calculated risks in such scenario, as there is a chance of high adaptability.  Scope for feedback and changes Traditional Each and every process is clearly detailed and defined at the start of the project in the traditional approach. It cannot deal with any big change or feedback that might require a change in the process. Mostly, the project delivery time and budget are fixed, allows change very rarely. Agile There is a high acceptance for feedback and change in this method. The process is very flexible and allows constant feedback that can help to provide better output within the fixed project delivery time. The main reason that managers or developers choose agile direction is for the flexibility it offers. Developers working with Agile management are able to respond to customer requests quickly as they are only addressing small parts of the project at a time and the customer validates each iteration or sprint before finalizing. Some of the important characteristics of Agile development Breaks project into parts Agile divides a project into parts (called iterations) where the release is sent to the customer after every single iteration. Additionally, the success of the project can be easily foreseen through the success of these iterations. This removes the need for upfront planning completely. Self-organized As mentioned above, Agile uses a parallel mode of management. Employees of a company are not managed by a central line of control, but by groups. For example, in Agile, there may be eight teams working on a single project. Each team is managed by itself without external guidance. The teams only interact with each other for project discussion and process linking as they are otherwise not self-sufficient. Generally speaking, an Agile project consists of three parts: The product owner – the expert on the project (for which the product is being developed) and is the main person who oversees the projects The scrum master – this person manages the process involved in Agile. He/she looks after the iterations and its completion The team – individuals who play significant and minor roles in the software development process Customer Engagement In Agile, customer engagement is at the very top. The customer is regarded highly in its frameworks as after every iteration, feedback is generated and acted upon. Overall, Agile is clearly the winner among project management systems. When compared with other traditional approaches, Agile’s features come to the fore and reiterate why it is one of the top software used by companies globally. Can Agile Coexist with Other Approaches? This is a question asked by many project managers, and opinions of experts seem to be divided. While some say it is possible for Agile to coexist with traditional project management systems, they suggest being cautious and using them for different terms. For example, using two different approaches on the same project can be counter-productive and highly explosive. As Agile and most other frameworks are totally contrasting to each other, the projects may go for a toss. On the other hand, some experts believe that it is not possible for Agile and other tools to co-exist because of their contrast. Using them together can cause disorder in the entire company system, making the productivity to go for a toss. Agile vs Traditional- Adoption Growth According to a recent online survey of 601 IT and development professionals, it is proved that Agile is the new typical formula for project success. The majority of projects and development teams are now adopting this methodology, while the traditional waterfall approaches have many flaws.    Traditional organizations vs. #Agile organizations #SALC16 pic.twitter.com/bBgxkQB1fI — Scrum Alliance (@ScrumAlliance) January 20, 2016 Agile was first introduced about 15 years ago as a substitute for traditional software development approaches. Many people considered it as challenging to implement traditional approach practices and Agile adopters stated that this new style of software development improves team collaboration and is more customer-centric.  Though Agile method was present more than a decade ago, the vast majority of organizations have adopted the practice in the last 5 years. Moreover, the survey reported that agile adoption saw an inflection point between the year 2009-2010. As shown in the above figure, agile adoption seems to have slow incremental growth till 2008 and then its growth was accelerated after gaining traction in the market. Reasons for the transition to Agile Most of the organizations who transitioned from traditional to agile project management have listed the following reasons: Improves collaboration between teams- 54% Enhances the quality level of software in organizations- 52% Results in enhanced customer satisfaction- 49% Speeds time to market- 43% Reduces development cost- 42% The Verdict In the traditional software development, the customer involves only before the start of the development process. So, there might be a number of mistakes and a large amount of money needs to be spent to rework on them. Since in the Agile software development, the customer involves at each stage, the corrections can be made once the defects are detected. This helps us in saving cost. As we can see, Agile project management is really in-demand for teams. It helps the team to work on the top priority ones at the right time and allows them to walk through the risks much faster than they would with traditional project management tools.  
Rated 4.0/5 based on 2 customer reviews
5986
Agile Project Management Vs. Traditional Project M...

In this fast-moving world, project management has ... Read More

Product Backlog Refinement in Scrum

Product Backlog Refinement, also referred to as Product Backlog Grooming, is a method for keeping the backlog updated, clean and orderly. It is a basic process in Scrum. PBR is a collaborative discussion process which starts at the end of one sprint to confirm whether the backlog is ready for the next sprint. Backlog can be defined as a set of user stories which are not present in the current sprint that defines project’s scope context. The stories which are left unattended, may interfere with the functioning of the development team.When this happens, the status of user stories will not be clear, and even the team can lose focus and fail to deliver within the project completion date. The backlog grooming meeting is attended by the scrum master, who facilitates everything for team members, the team and the product owner. They decide among the top items from the product backlog. The team comprises mainly of Developers, testers and Scrum Masters. The team can raise queries during the sprint planning session if they find any unresolved issue. The expected doubts can arise in the following forms : How to handle the situation if the user enters invalid data? Which part of the system are the users authorized to operate on? For the product owner, it will be easy to get the conclusion over the queries, by asking these questions in the early stages. If there is a question which is unanswered by too many people, it is time to make some changes in your backlog items by curating higher priority items to the top of the list and assigning highest priority to the unanswered questions. The Objective of PBR meeting: A lot of time is saved at sprint planning meetings, if the backlogs are well maintained. If the backlog item is clearly specified in the acceptance criteria and cross-checked properly by the team members, the planning process can be accomplished prior to the meeting. PBR offers the team members the opportunity to interact with each other regarding stories. Why is PBR important?  PBR and its sessions are important mainly due to the following features- It increases the efficiency of the team by reducing uncertainty Properly refined stories are easy to estimate, test and implement. PBR session increases the efficiency of the team due to the knowledge shared among the team members. If PBR meeting is maintained properly, it helps reduce the time for a Sprint planning meeting. The Product Backlog grooming can be made effective if the following aspects are considered- Do not schedule backlog refinement meeting during the first and last 20% of the Sprint Planning session. Backlog refinement meeting should be considered as the first part of Sprint Planning. The backlog items’ list should be well understood by the PO, or development team member to work well in the meeting. Make sure that the set of predefined acceptance tests are present. Keep an eye on the meeting goals. Make sure to assign action items for any unknown thing. Do remember that the backlog items are a collaboration between the PO and the team. Feel free to break the product backlog items during the meeting. After the product backlog refinement meeting, the team can update the Product Backlog items in line, based on the discussions held. Finally, you can get a potentially shippable product, ready to be deployed in the market.
Rated 4.0/5 based on 20 customer reviews
1571
Product Backlog Refinement in Scrum

Product Backlog Refinement, also referred to as Pr... Read More

other Blogs