Components of a Defect Management Software

 Since software developers and testers work together in the Agile and DevOps environments, it gets challenging to cope up with the increasing competition. Development teams work in collaboration with various stakeholders to make the most of the testing efforts. Defects in software applications are a norm, the sooner you realize that better it is. It is impossible to have a 100% defect/error-free software application, but experts work to make the most of their efforts. The current need for faster delivery and quality products calls for robust software testing solutions that can meet customer expectations.

A defect management system is a defect repository where all the defects appearing in a system are identified, recorded and assigned for rectification. This system includes defect management software and defect management tools to achieve projects efficiently. 

How Does Defect Management Work?

A defect management system works in a systematic manner, and records all the defects in the system without duplicating defects, and maintaining a log for future use too. There are different steps involved in the defect management that are explained below”

Identification – First of all, testers identify the defects

Categorize – When it is reported, it is automatically assigned to a team member to assess whether to rectify the defect or leave it

Prioritize – The next step is to prioritize by assessing the severity of defect and its impact on the user. The prioritized defects are handled by a formal change control board. 

Assigning Defects – After   the defects, they are then assigned to developers or testers accordingly 

Resolving Defects – The develope resolves the defect and follows the process to move further in the defect management process

Verification – The software testing team verifies the environment in which the defect was found

Closure – Close the defects after completion

Reporting – Reports are then provided to the relevant stakeholders regularly. They can also be demanded according to requirements. 

The entire process sounds pretty simple and easy, although it is not so. Defect management is tricky but using the right type of defect management software and tools helps in achieving the desired results. These tools are also integrated with other software testing tools to enhance and align all the processes between testers, developers and other relevant stakeholders. It aids all experts and specialists in planning, building and developing a quality software product. Business analysts, product managers, developers, project managers, testers. etc. is operating in a single system by sharing the same information. Defect management tools are also integrated with the test management system, which helps testing teams to share the project status with other key stakeholders. 

All these stages of defect management process contribute to a defect management software. Generally, defects are always considered negative, which may not be the case in all instances. Sometimes a tester makes a mistake while recording the defect, which can affect the entire process. So we can’t truly say that a defect management software or tool alone is responsible for effective defect management, it is also important to handle the defects efficiently. 


This is a guest post by Ray Parker

Author Bio:Ray Parker is a senior marketing consultant with a knack for writing about the latest news in tech, quality assurance, software development and testing. With a decade of experience working in the tech industry, Ray now dabbles out of his New York office.

My experience speaking at Targeting Quality 2019, Canada

I am back from the trip to Canada which followed the big day that was #TQ2019. So, I finally have a chance to share my experiences. This event https://kwsqa.org/tq2019/schedule/ organised by KWSQA was special in a number of ways-

  1. It was my first international conference talk 🙂
  2. I was one of the few international speakers at the conference, and the one who traveled the farthest for it!
  3. I was the only speaker presenting 2 talks!

The travel was big too – with tonnes of visa processing, a 24 hour long flight to Toronto and then a bus ride from Toronto to Cambridge (which I nearly missed 😛 owing to the infamous Toronto traffic! )

Day 1 of the event was workshops that were in progress when we reached and we got a chance to informally meet the organizers at the desk. That evening they had planned a Speaker dinner which was a great idea. I got to interact and meet with all the speakers, made some friends and so the next day seemed a little less daunting having so many known faces.

24 Sep was the big conference day. Staying at the same hotel gave me the advantage to get ready at my own pace and be on time for the breakfast. The event began with a brief intro and then split into tracks. The first talk I attended was ‘Lean Coffee Facilitators Training’ by Matt Heusser. My first time hearing him speak. His session was fun and engaging and practical. I did #sketchnotes for the talk and also participated in the activity which was fun!

After that was my own session in the next room, so I hurried to setup and get ready. The best part was that the organisers had planned a 15 minutes gap between each talk for QA/Networking which gave the speakers and the delegates some breathing room and time to get to other sessions.

I talked on ‘The What, When and How of Test Automation’ which was a 45 minutes session. The room was full and there were lots of good questions and participation from the audience. I did feel that I handled it well and the topic as well as the proposed ideas were well received! 🙂 Here are a few glimpses into my talk-

Though I was relieved having just delivered a good talk, I still had one more to go! After that was lunch hour. A few participants from my talk invited me to sit at their table and we had so many discussions about work, testing as well as my travel plans 😛

Then we got back to talks- I also attended a talk on ‘Barriers in Accessibility Testing’ by Albert Gareev which I also #sketchnoted

Post that I rushed to the lightning talks track as I had to prepare for my next talk that was a 15 minute session on ‘Gamify your Agile Workplace’. As I got there I heard Richard Strang talk about ‘Implementing an Agile QA Guild’ and his experiences that were so varied and interesting. Then I got up to speak and since I was talking about an innovation game called speed boat, I had to first draw a big speed boat on the flipchart (with my limited drawing skills:P ) with a room full of people staring! I guess I managed well as the room MC Tina Fletcher (also president of KWSQA) was impressed with my masterpiece 😛 hehe

The session went well – the best bit being our Keynote speaker Damian Synadinos attending as well volunteering for the little game we played. It was an honor and an unforgettable experience. I hope the audience took back something tangible to try out gamification in their agile teams.

With both the talks done, it was now time to relax and network. I stopped by the booths by Oracle and NPM, chatted with fellow speakers and delegates, the organizers and also got real time feedback from the attendees who chose to attend my sessions.

Post the little coffee break was the grand closing keynote by Damian and it really was an experience. He mentioned in his intro that he had some improv experience and he really uses it to the best in his speaking! The talk was funny, intriguing, had loads of content, memorable quotes as well as an activity in which I volunteered! And a big Plus — Damian mentioned me and my talk too! 🙂 🙂 All in all it was an epic performance and really inspiring as a speaker. Kudos to the effort that went behind putting this together.

The best parts were getting to know so many wonderful people like Josh, Bailey and Dani, and getting to meet @Matt Heuser who I have had the chance to work with online. A face-to-face interaction makes things seem so real and people so approachable. He is a gem of a person and so encouraging too. I also made a friend @Emna who came from Tunisia to speak at the event! We roamed the streets of Cambridge and rode buses together and by the end seemed like we have known each other for so long. I surely hope to see her again at a future conference.

The organizers at TQ2019 had really worked hard and their efforts worked out so well with such a grand event pulled off with great ease, smooth flow and right on schedule. They welcomed us with warmth and helped throughout the day. At the end of the day we all got some time to cool off with a Social event where we mingled and got a chance to express our gratitude and say good byes. I would like to personally thank Greame Harvey, Sabina, Rob, Josh Assad , Jared and Tina Fletcher from the KWSQA committee who were all so helpful and kind.

I am thankful for getting this opportunity and look forward to staying connected with such awesome people. I am also thankful for my supporting hubby who tagged along so that we could make this into a trip – got a chance to explore Toronto, Montreal and Quebec city and of course the majestic Niagara Falls! 🙂

Cheers to @KWSQA #TQ2019 and many more to come! 🙂

I am speaking at ‘Targeting Quality 2019’ , Canada

I am super excited to be speaking at this grand event TQ2019 being organised by KWSQA on 23-24 Sep in Canada!

On top of that I get to present not one but 2 talks!! My topics are

“The What, When & How of Test Automation” 45 mins

In this I will talk about preparing robust automation strategies. Agile means pace and agile means change. With frequent time boxed releases and flexible requirements, test automation faces numerous challenges. Haven’t we all asked what to automate and how to go about the daily tasks with the automation cloud looming over our heads. Here we’ll discuss answers to some of these questions and try to outline a number of approaches that agile teams can take in their selection of what to automate, how to go about their automation and whom to involve, and when to schedule these tasks so that the releases are debt free and of best quality.

“Gamify your Agile workplace”    15 mins

In this I’ll present live some innovation games and have audience volunteers engage and play games based on known scenarios. Let’s Play and learn some useful Innovation Games that can help you gamify your agile team and workplace, making the team meetings shorter and communication more fun!

Both these topics are close to my heart and I am looking forward to sharing my thoughts with a wider audience.

I am also excited to meet all the awesome speakers at the event , as well as get to know the fantastic team of organizers behind this event!

Check out the detailed agenda here – https://kwsqa.org/tq2019/schedule/

Follow me at @testwithnishi, @KWSQA and #TQ2019 on twitter for more updates on the event!

Also check out & support other initiatives by KWSQA at https://kwsqa.org/kwalitytalks/

Wish me luck! 🙂

What the NAPLAN Fail Tells Us About Testing in Education?

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.

Naplan’s online system was reviewed by PricewaterhouseCoopers to reflect these problems. The report nails down the cause of the issues to a lack of automation testing, “[Education Services Australia] continues to work with [Education technology provider] Janison and Microsoft to improve upon the current recovery time of 80 minutes and recovery point of 15 minutes, and believe that eventually an automated service may become possible, however, the current environment is unable to do so.” 

What do we learn?

Naplan’s fail tells us that software testing in the field of education is as important as in other industries like healthcare and banking. Modern school systems rely heavily on online resources, not simply for research but also for exam and course work. As schools shift from traditional paper-based teaching methods to electronic systems, they must remember to test their software in sync with technological demands.

Without robust testing, school systems can be severely impacted.

  • The administrative costs would go up in rescheduling exams for students.
  • The school would also lose credibility as students will mock the sluggish approach.
  • Students who are dedicated to working will become demotivated. ‌
  • Positive school culture is likely to dwindle.

Before that happens, educational institutions must think of software testing!

This is a guest post by Ray Parker

Author Bio:

Ray Parker is a senior marketing consultant with a knack for writing about the latest news in tech, quality assurance, software development and travel. With a decade of experience working in the tech industry, Ray now dabbles out of his New York office.

Interesting Podcast Recommendation- Melissa Eaden @Maintainable with Robby Russell

I recently came across this podcast which is a very interesting and thoughtful conversation. Hosted by Robby Russell , Maintainable is a podcast hosted about overcoming problems often associated with technical debt and legacy code.  In this episode, Robby speaks with Melissa Eaden, Tech Lead in Quality at Unity 3D. She shares her experience working with legacy code as it relates to testing. Hearing this conversation, I could not help nodding along and agreeing with each word about problems in testing, requirements for a tester and the best use of existing resources, communication and collaboration for a better quality initiative in your teams. Check out the podcast and listen to the episode here ->

https://maintainable.fm/episodes/melissa-eaden-its-never-a-one-person-job

Here are some key points that resonated with me-

  • Visibility , Communication and Research are the 3 most important arsenal for a tester
  • It’s never a one person job
  • The importance of communication and making connections
  • Information gathering via offhand conversations
  • Quality is a people problem!

Hope you enjoy it!

‘Co-opetetion’ Among Agile Team Members

Agile focuses on motivated individuals acting together toward a common goal. Consequently, agile needs people to collaborate and requires complete transparency, communication, and cooperation, within and across teams. But at the same time, individuals instinctively try to outperform others in order to stand out in their teams.

This transition from individual responsibility to collective ownership is often the hardest part of the cultural shift that teams face when adopting agile. I have looked at ways to encourage healthy competition, more cooperation, and a sense of community among agile teammates in my latest article for Gurock – TestRail blog, the main points being-

  • Showing People the part they played
  • Have Co-workers appreciate each other
  • Measuring personal growth
  • Motivating with extra initiatives
  • Encouraging Collaboration and healthy competetion

Check out the complete article at – https://blog.gurock.com/agile-co-opetiton/ to find ways to encourage healthy competition and better team dynamics in your agile teams!

Meeting James Bach at The Test Tribe Meetup @Bangalore

I got the opportunity to meet and listen to the test expert we all look up to – Mr. @James Bach at @The Test Tribe Community meetup organized at Bangalore on 23 June 2019.

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!

Cheers!

Using Mind Maps for Agile Test Planning

Mind maps are a creative way of gathering ideas around a central theme and categorizing them in concrete branches. Mind maps can be useful for both personal and professional life as an organization and visualization technique. They’re descriptive, easy and even fun.

In my latest post for Gurock blog, I showcase the usage of mind maps as a technique for test planning and test design. This tool’s capabilities make your documentation leaner and ideas more visual, which benefits the whole agile team.
https://blog.gurock.com/agile-mind-map/

Be it test planning in an agile team which needs entire team’s insights and collaboration, or categorization of product features, test areas and backlog, Mindmaps can be used for all aspects and phases of the project.

Testers can generate their test ideas and have them categorized in a mind map around the central theme of the feature. The visual nature of a mind map helps them find more scenarios, see which parts are more heavily tested, and focus on main areas or branches. Once done, they can have other stakeholders take a look at it and get their opinions. This fosters brainstorming together and gathers the maximum number of ideas from the entire team.

Find useful tips to create your own mindmaps, as well as some samples for your reference in agile test designing as well as test planning. Read the complete article here ->
https://blog.gurock.com/agile-mind-map/

Share your thoughts!

Making the case for Usability Testing in Agile

My first experience with usability testing was on an agile team where the product we were building was being designed with the help of an in-house usability expert. He helped design the user interface (UI) of the application and conduct usability study on the beta version of the software to determine the ease of use of the application.

Though the experience was limited in terms of the interaction we had with the user representatives and the sessions conducted, the feedback we received opened up lots of new avenues for the tester in me around the learnability, understandability and attractiveness of the application I was testing.

Usability has matured a lot over the years. It’s now an essential software characteristic in today’s web and mobile applications. In my article published at the TestRail blog, I discuss ways of performing Usability tests and developing a mindset for Usability in an agile context.

https://blog.gurock.com/usability-testing-agile-projects/

We also discuss about Usability Study , how to set it up and achieve maximum benefits from it.

To read the complete article — (opens in a new tab)”>Click here –>


‘Just Enough’ documentation in an Agile Project

Agile poses many challenges to the development team, most of them pertaining to time. Teams are perpetually under pressure to deliver working software at a fast pace, leaving minimum time for anything else. When testing on an agile project, learning how to write lean documentation can save precious time. Furthermore writing lean documentation can help rework efforts by focusing only on what’s really necessary.

The Agile Manifesto emphasizes working software over comprehensive documentation, but most agile teams interpret this wrong and treat documentation as something to be avoided, owing to time constraints. The manifesto states a lesser focus on comprehensive documentation, but some documentation is still needed for the project and any related guidelines being followed. Attaining this balance is a challenge.

Documentation is a necessary evil. We may think of it as cumbersome and time-consuming, but the project cannot survive without it. For this reason, we need to find ways to do just enough documentation — no more, no less.

Read about how to focus on important areas like VALUE  , COMMUNICATION and  SUFFICIENCY when documenting in your agile project – in my article published at Gurock TestRail blog –> https://blog.gurock.com/lean-documentation-agile-project/

just enough

Click here to read the full article

For example, in a traditional test design document, we create columns for test case description, test steps, test data, expected results and actual results, along with preconditions and post-conditions for each test case. There may be a very detailed description of test steps, and varying test data may also be repeatedly documented. While this is needed in many contexts, agile testers may not have the time or the need to specify their tests in this much detail.

As an agile tester, I have worked on teams following a much leaner approach to sprint-level tests. We document the tests as high-level scenarios, with a one line description of the test and a column for details like any specific test data or the expected outcome. When executing these tests, the tester may add relevant information for future regression cycles, as well as document test results and any defects.

More examples and scenarios for learning leaner test document creation are included in the full article– Click here to read the full article

 

                 Are you interested in finding the right tool for your Agile processes? Here is a comprehensive assessment and comparison of the best agile tools available! 

https://thedigitalprojectmanager.com/agile-tools/

Prepared by Ben Aston, this list may be a useful guide for finding and selecting the best tool to support your agile journey. Check it out!

 

Happy Testing!

Nishi