by admin | Sep 5, 2018 | Agile, Blog, Quality Engineering
Let’s face it, Agile has some tremendous benefits. If you are practicing agile at your company, you know that firsthand. Agile also has some pitfalls that can be extremely deadly if they are not addressed properly. Most of us have learned how to avoid them by implementing costly mistakes.
Agile Pitfall #1: Lack of Integrated Software Testing
Agile Pitfall #2: Too Much Technical Debt
Agile Pitfall #3: Agile Team Silos
Agile Pitfall #4: Too Focused on Agile Team Roles
Agile Pitfall #5: Folks, It Isn’t All About Velocity!
Sure there are other things that agile has issues with, but we will cover those in subsequent agile posts.
Using the agile methodology, software can be developed very quickly, in fact, business needs demand it is produced as quick as possible. While there is nothing inherently wrong with that, it is important to develop it efficiently. Agile teams want to build the best designed and highest quality product possible. However, that isn’t always what happens. My team has recently been involved in leveraging a COTS product called Globalscape to consolidate all our B2B file transfer systems into a single solution. In fact, our company was acquired, so between both legacy companies we had four solutions which were being used. We selected Globalscape, but the product was brand new to our team. We didn’t have extensive experience but were driven to move off the other systems. We made the best decisions that we knew at the time, but looking back, there were some things that if we had better information and experience with the product, we would have certainly done differently. Naturally, we accumulated technical debt, and we created stories in our backlog to handle those. In certain sprints, we had to put more technical stories in place to implement the necessary changes. While our business partners weren’t thrilled, they understood those needed to be done.
In some situations, you can address technical debt issues as you are addressing stories in the backlog. For example, with our file transfer product, we created a generic function to address how email notifications were delivered, which was much more efficient. While we were moving other B2B files into the new platform, we would go ahead and make those changes, so that we would not have to revert and make those technical debt changes later.
It is also a good idea to keep 5 to 10 percent of your sprint capacity available to handle technical debt issues. If you have one story per sprint handling technical debt, then it will make it a lot easier in not having to deal with too much technical debt later.
Hopefully this real world example will help you avoid Agile Pitfall #2: Too Much Technical Debt!
by admin | Sep 5, 2018 | Agile, Blog
Most companies are using the agile software development approach in building great software. While agile has significant benefits, there are some dangerous pitfalls.
Agile Pitfall #1: agile has a lack of integrated software testing
Agile Pitfall #2: Too Much Technical Debt
Agile Pitfall #3: Agile Team Silos
Agile Pitfall #4: Too Focused on Agile Roles
Lack of integrated software testing is especially dangerous when companies have multiple products and are running multiple agile teams. The agile teams are often heads down and focused on their product only, and don’t have the time, energy or effort to understand how the systems interact with each other and what potential pitfalls are downstream. Most systems have dependencies with each other in terms of data or interfaces. Product teams today have subject matter development and testing experience, but may not understand other systems and how those interactions. If there are understood impacts, the responsibility usually is handed over to the team who is responsible for that product. It usually occurs with little to no planning, and typically little warning is done in advance. Something to the effect of: “hey can you perform some regression test this feature real quick and make sure it works, and provide me a sign-off before the end of the day since we are releasing into production tomorrow?” If you are in testing and a part of an agile team you understand that agile has a lack of integrated software testing.
Agile software development works great for the most part, but there are some pitfalls that will happen. Agile works well with a single product because there is essentially no integration points, however, most enterprise systems are going to have integrations with either other internal applications or third party applications. It is not sufficient enough to assume that is it is the responsibility of another product or team to ensure the quality is going to work from an end to end perspective. You certainly don’t want to have your business partners or end customers find out that something does not work properly.
I currently manage an agile team and my direction to them is to get the necessary access to all the interfacing systems and run the test to make sure it works properly. Our application is the upstream system, so if something goes wrong, we will be the group that will be held accountable, regardless if it is our system. Sure, it takes additional time and effort to perform that testing, but as long as we account for the work in the sprint, we are covered. I would much prefer to test it ourselves and be sure rather than suffer the consequences.
I encourage you to eliminate agile pitfall #1: agile has a lack of integrated software testing. If you can avoid this pitfall, you and your agile team will be successful!
by admin | Aug 27, 2018 | Agile, Training
If you are looking for some Great Agile Online Training, I have found a course on Coursera that will really help you. As you know, it is important to keep your skills current, and if you are in the software testing profession, you must learn Agile Testing, since most companies are using this methodology. Agile testing is here to stay, so the time to learn all you can is right now. The beauty of taking great agile online training, is that you can learn it from anywhere and you can engage with others who are seeking to learn more about this valuable skill. If you are a developer, you are also welcome to participate, as I think this course will be extremely valuable to you as well. Developers are also getting more involved in the testing process and sometimes it is necessary for the developer to take on the role as tester in order for the sprint work to be completed on time.
Testing with Agile
About this course: To deliver agile outcomes, you have to do more than implement an agile process; you have to create a culture of experimentation. It’s this commitment to experimenting that’s at the heart of a high-functioning practice of agile. This course shows you how to integrate the practice of experimentation across concept/feature testing, usability testing, and testing the software itself. Basically, you’ll learn how to answer these four big questions with experiments: 1. Should we build it? 2. Did it matter? 3. Is it usable? 4. Did it break? More specifically, after completing this course, you’ll be able to: – Identify where and how to invest your team’s scarce time and energy into better testing for maximum impact on outcomes – Coach your team on the relationship between idea, usability, and software testing to get the buy-in you need for strong interdisciplinary collaboration – Test ideas before you build them to avoid waste and help your team focus on what will really drive outcomes – Test alternative interface patterns before you build them to maximize both product usability and purposeful implementation – Understand your delivery pipeline and how to prioritize process and infrastructure improvements so you can deliver faster and more often As a Project Management Institute (PMI®) Registered Education Provider, the University of Virginia Darden School of Business has been approved by PMI to issue 20 professional development units (PDUs) for this course, which focuses on core competencies recognized by PMI. (Provider #2122) This course is supported by the Batten Institute at UVA’s Darden School of Business. The Batten Institute’s mission is to improve the world through entrepreneurship and innovation: www.batteninstitute.org.
Who is this class for: This course is aimed at professionals working in software and IT or interested in moving into this space.
Created by: University of Virginia
Click here to learn more!
by admin | Jun 8, 2018 | Agile
One of the elements of Agile, is to have an agile retrospective meeting after each sprint. Our team has been doing agile for over a year and here are the top 3 items we have discussed.
- Communication
The top issue over multiple sprints is lack of communication. It can come in multiple forms. Some of those include: lack of requirements, requirement ambiguity, improper assumptions made, and lack of understanding of the product. There are some things which you can do to improve communication. One item we did was to create a document which contains additional information that isn’t captured in JIRA. That seemed to really help. Another item was to have a meeting once that information is obtained to go over the document. While some may say documentation isn’t needed in agile, I believe it is to help reduce communication issues.
2. Lack of Unit Testing
Another fairly common theme throughout our agile retrospective was the concern the QA resources expressed was the identification of avoidable defects if unit testing was performed by the development teams. There are a few things we are currently working on which I expect will begin to pay dividends in this area. I have asked the QA resources to start building their automation scripts during the first week and once the code is ready they can run the scripts in the development environment to identify issues before the code is promoted to the test environment. This helps development and qa teams. In the event that it doesn’t make sense to create an automated script, I have asked the qa team to setup a meeting with the developer and work with them to perform testing earlier in the cycle. So when the code is ready, the resources will sit together and perform testing to identify any items before the code is delivered to the test environment. Once the code is delivered to the test environment, additional testing such as negative testing, regression testing, and end to end testing can occur and identify any additional defects which might be found.
3. Lack of Testing Time
This one is probably not surprising to most qa resources and another them during our agile retrospective sessions. There are several reasons for this, but the most common underlying reason is the struggle of identifying the requirements within the first few days of the sprint. While getting the document which has the requirement created helps, it still requires the information for it to be filled out. We are primarily migrating from several systems into one, so the initial documentation when those things were done is not existent. We currently have to go into that system and extract the information which takes time. This creates a waterfall effect which puts a pinch on the back of the sprint which causes us to scramble during the last few days of the sprint.
If your team struggles with one or more of these issues, hopefully the tips above can help your organization become more effective with agile. It is important to do the agile retrospective meetings, so you can uncover small improvements you can make along the way to make your team more effective.
by Ron Wilson | Apr 10, 2018 | Agile, Blog, Manual Testing
With software testing, and agile testing in particular, it is critical not to forget about the negative test scenarios. Agile forces teams to move a break neck speeds and often we are lucky to get the happy path scenarios tested, so you are probably thinking how in the world can we also have time to cover the negative test scenarios. Unfortunately, when there are production quality issues, the root of most of those defects is that the test scenario was not tested. Planning in agile, contrary to what many may think is that test planning is a critical piece of the overall process of quality.
I have been running an agile team for over a year now, and we have done a great job at covering happy path scenarios, or those items which we identified which need to be tested. However, we have done a very poor job of identifying and documenting negative test scenarios. For our product, we manage electronic file transfers between our customers and other internal systems. With this one scenario, two different files were received at the same time, and the second file ended up overwriting the first file. While we were able to reprocess the overwritten files, it was a painful lesson because we did not factor that negative test scenario in our testing.
While it is impossible to account for all the different negative test scenarios, it is possible to document those which might be most probable and automate as much of those scenarios that you can, so that you can speed up the testing process. In the event that defects are discovered like it happened on my team, it provides a great learning opportunity to grow and raise awareness which will help identify potential missed opportunities. I would venture to guess that most agile testing covers 90 to 95 percent of happy path scenarios. If we spend more time and identify 5 to 10 percent more negative test scenarios, then I believe our overall quality will increase.
by Ron Wilson | Oct 18, 2017 | Agile, Blog, Manual Testing
I am a firm believer that end to end testing is critical in Agile. I have personally experienced countless instances of where production issues could have been avoided if a few end to end tests would have been executed. Most of my professional career has been devoted to software testing and end to end best practices so I have a high degree of understanding of the testing process. Testing is a critical piece of the agile process but it is often misunderstood.
Here are some items that will help you determine if end to end testing is needed:
Dependencies: For the code change that is being made, is it isolated to a specific product or does the change impact another product or service? If the answer is no, then no end to end testing is needed. If the answer is yes, then end to end testing is required. This is the #1 factor when determining if end to end testing is required and it is often the primary reason why issues occur in production. It is important that the agile teams communicate both internally and externally. Often an agile team will make a change and not believe there is an impact to another product or service but the impact occurs because certain misunderstandings or incorrect assumptions are made.
Critical Business Workflows: If a code change is made within a critical business workflow, then it is always a good idea to perform end to end testing to ensure no adverse impacts occur. Often running a few end to end tests will prevent issues from occurring in production.
Billing/Payments: It is critical to run end to end tests anytime there is a change to billing or payments. Billing and payments can impact all businesses and it is important to spend the extra time performing end to end tests. I have personally experienced many issues with companies due to billing and payment related issues.
Customer Impacting: If the change has the potential to impact the customer, then end to end testing should be completed.
This end to end testing framework is not exhaustive, but it should cover the critical areas where performance testing is required. Always if you think there is a remote potential it is a good idea to run end to end testing. Most companies have test automation that will cover the critical business scenarios so it is always a good idea to run those automated regression tests to ensure you are covered. Many in agile believe that end to end tests are a waste of time and not needed but I have experienced too many issues. I also am a firm believer that if then agile team who has made the change has access to either an upstream or downstream system, then they should be able to perform the testing so they are not dependent on another team to perform the validation. I believe that as long as you are running end to end tests that cover the code change, you don’t need to run hundreds of tests to ensure that things are working. Run enough end to end tests but don’t run more that is needed.
Let’s face it, Agile has some tremendous benefits. If you are practicing agile at your company, you know that firsthand. Agile also has some pitfalls that can be extremely deadly if they are not addressed properly. Most of us have learned how to avoid them by implementing costly mistakes.
Comprehensive, detailed and well worth the time. Everyone in software development business should take this.