Are you testing with the sole purpose of finding defects? What if you don’t find any? Your testing should deliver more value than just finding bugs. In my article published at https://blog.gurock.com/, I examined the true goals of testing and how we can aim at achieving all four of them for the quality benefits of our software.
Gaining knowledge about defects
While there is more to testing than pinpointing bugs, finding defects and problems is the first instinctive goal. Looking for places where the functionality breaks or does not work as expected is key.
Testers can adopt a number of approaches, test techniques and strategies to find these problems before users do. This helps the team keep updated on the status of product quality, fix the problems, and improve the software for the users.
If you have been testing diligently and going through a bunch of test cases and various scenarios but haven’t yet found a defect, it doesn’t mean it was all for nothing! If a test doesn’t fail, that means it passed, and that is useful information, too.
Another major goal of testing is to prove that the functionality works fine, and it is that proof that helps us make decisions about its future. Without this proof, we would never have a clear picture of the software’s quality, its intended functionality or whether it’s fit for use. Many teams would also get into problems with regulations, audits, and compliance without this proof of functionality.
Testing also generates a lot more information than just passing or failing tests. Testers generally have loads of questions occur to them while testing. They may be about the need, implementation or design of the features, their related integrations with existing features, or actual usage scenarios. The answers to these questions are paramount in making the feature assimilate well within the software.
“Several core practices used by agile teams relate to testing.”
Programmers using TDD, code integration tests being written contribute to a successful project.
“Agile Testing just doesn’t mean testing on an agile project.”
Some testing approaches like exploratory testing are inherently agile, whether done in an agile project or not.
Testers are integral members of the customer team as well as development team
The best part of this chapter is Lisa and Janet’s wonderful stories on beginning with their first agile projects, and a realization by Janet’s co-worker, a developer in a team following XP on how they saw Janet’s contribution to the project.
“Testers don’t sit & wait for work; they get up and look for ways to contribute throughout the development cycle and beyond.”
Traditional vs Agile Testing
In Traditional approach – “Testing gets “squished” because coding takes longer than expected, and because teams get into a code-and-fix cycle at the end.
In Agile – “As an agile team member, you will need to be adaptive to the team’s needs
“Participants, tests, and tools need to be adaptive.”
“An Agile team is a wonderful place to be a tester”
The Whole-Team Approach –
“Everyone on an agile team gets “test-infected.”
“An agile team must possess all the skills needed to produce quality code that delivers the features required by the organization.”
“The whole team approach involves constant collaboration”
“On an agile team, anyone can ask for and receive help”
“The fact is, it’s all about quality – and if it’s not, we question whether it’s really an ‘agile’ team.”
Here we are gearing up for another new year! As time flies by, we may start to feel stuck in one place, unable to move forward in our careers. Testers can get bogged down by too much to learn, too many directions to take, and so many tools and technologies.
But that’s no reason to stagnate. By making some goals now, you can aim to start improving yourself and your career development right away on January 1st.
The first resolution should be to create and maintain a healthy mindset. Mental peace and team harmony should be the goal.
There must be a routine, a drive to better oneself and a constant search for improvement. All testers must resolve to take up some kind of continuing education so they can always be adding to their skill sets. Learning cannot be a one-time activity.
Get Better at Networking
The next resolution a tester must make is to participate in the community in some way. The knowledge you have is better shared with others, and the pace of learning in a community will be much faster than alone.
The bugs we find during
testing can tell us a lot about the application, the state of its quality and its
release-readiness. Bugs can also provide insights into our development
processes and practices — and lapses therein.
How can we study bugs to improve the overall state of our project? In my article published @Gurock TestRail blog, I have described three things to learn from the bugs you find. https://blog.gurock.com/three-learn-bugs/
As we log defects into a tracking tool or portal, teams
generally follow the practice of measuring relevant modules, components or
functional areas against each defect. When tracked over time, this information
can be real gold! It helps us track which areas of the application are having
Implications of Software Testing in the field of Education
The National Assessment Program – Literacy and Numeracy (NAPLAN) are school tests administered to Australian students. This August, the online program was offered to 1.5 million students. Students failed to log on.
Had the software undergone functional testing, the program could have launched successfully. A functional testing company verifies every function of the software function as per requirements. It is a black box type of testing where the internal structure of the product is not known to the tester.
Functional and Performance Issues – Naplan’s problem has been ongoing. In March, it took students 80 minutes to get to online tests. The requirement was of 5 minutes. The software performed shockingly different from what was planned. 30,000 students had to retake tests, which too were marred by technical glitches. The test data was not automatically saved. The data recovery time was 15 minutes compared to the requirement of zero minutes. Once again, the software did not perform as expected. Eventually, the problem was resolved, however, it came at the expense of dropouts and time lags.
Accessibility Issues – Naplan software had other errors that a functional testing company could have taken care of. The features that were designed for students with disabilities were not functional. Alternate text for students was missing, incorrect and inaccessible for students with auditory disabilities. The color contrast was poor. The color contrast was of immense importance to those who required accessibility help with seeing visuals.
In the Naplan case, a functional testing company would prepare several test cases to verify the functionality of the login page, accessibility features, load times and data recovery times against the requirements specified. Functional testing would cover unit testing, integration testing, interface testing, and regression testing. In addition to manual testing, a functional testing company would perform automation testing. Software testing tools automate tests to improve the accuracy and speed of execution.
It was a great talk by him on the topic ‘Testing vs Checking’ where he discussed the finer nuances of the testing craft and how automated checks are more explicit and fixed than the human brain and the thought process of a real tester.
Apart from the great content, I also observed and loved the presentation style, the ingenuity, the spontaneity, and the interspersed humor! His true passion for testing and the sheer amount of experience shines through each spoken word. We learn a lot just from being in the same room with such experts.
I tried my hands at #sketchnotes for the first time, trying to capture the gist of his talk.
Here is a glimpse into the event-
It sure was an awesome experience and a day well spent! I look forward to meeting him again and getting an opportunity to learn from him!
Every year we see the software industry evolving at a rapid pace. This implies changes in the way testing is conducted within the software lifecycle, test processes, techniques and tools, and the tester’s skill set, too.
I’ve been into agile for more than a decade, and I’m still learning, changing and growing each year along with our industry. Here are five of my key lessons and observations from 2018. I hope they help you in the coming year!
In my article published on Gurock blog, I talk about the 5 key learnings for Agile testers from the past year and how they will be key in planning your road ahead in 2019. The key learning areas discussed are —
The Agile Manifesto gives us 12 principles to abide by in order to implement agility in our processes. These principles are the golden rules to refer to when we’re looking for the right agile mindset. But are we getting the right meaning out of them?
In my latest article for Gurock TestRail blog, I examine what we mistakenly hear when we’re told the 12 principles, what pain points the agile team face due to these misunderstandings, and what each principle truly means.
Principle 1: Our Highest Priority is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software
What we hear: Let’s have frequent releases to show the customer our agility, and if they don’t like the product, we can redo it.
The team’s pain points: Planning frequent releases that aren’t thought out well increases repetitive testing, reduces quality and gives more chances for defect leakage.
What it really means: Agile requires us to focus on quick and continuous delivery of useful software to customers in order to accelerate their time to market.
Here we have for you another Innovation Game centered around prioritization. It is a visual and crisp way to chart out and understand priorities of upcoming tasks , features or stories.
Game : 20/20 Vision
Aim : To chart out the RELATIVE priorities of the tasks at hand
Method: The 20/20 game elaborates the prioritization of each task in relation to a benchmark task of medium priority and complexity.
Just like a visit to the Optometrist, where he makes you compare the various lenses to find the best suitable for your sight, in this game we make the team compare all stories / requirements / tasks and find the right place for them on the chart of priority in relation to the one benchmark level.
Description: Write down all stories on post-its. With the team’s consensus and decision, decide on one story which is of medium level and put in on the board in the middle.
Now the team goes through each story one by one, and places the story on the board as higher or lower priority in relation to the benchmark story. At the end of the exercise, we arrive at a visual representation of the story or task prioritization, giving us a clear road-map for future!
This game takes almost 15-30 minutes only depending on the number of tasks at hand, as compared to long planning meetings.
Hope you are enjoying our series on Innovation Games, and learning some new techniques to engage your Agile team. In Part 1 and Part 2 we discussed some really fun and interesting Agile Innovation games.
In this part we shall discuss a really unique Innovation Game which helps the team and stakeholders to gather a broader perspective on the product or project they are working on. While working on small components and intricacies of the project, it is possible for us to loose perspective and be confined in a narrow zone.Our game helps us to ‘Zoom-Out’ periodically and get a bird’s eye view of the project, its future and the road-map ahead. It is called –
Prune The Product Tree –
To identify the most important features, aspects of the product as per the stakeholders and to elicit feedback from the customers.
Draw a big tree on the chart and draw its branches. The thick branches represent the major functionalities of your system. The smaller branches are the functionalities within each branch.
Participants place the index cards in their respective branches after writing the new expected features.
We may also add apples for functionalities that will be very useful for next releases, and flowers for the good-to-have features that may wow customers!
This will give an overview of the future direction of the product and gives visual representation on which branch of the product tree is expanding the most.
Try this out with your team , and you shall see the benefits soon! 🙂