![\"a](\"https:\/\/www.argildx.us\/wp-content\/uploads\/2020\/02\/Optimized-communication1.jpg\")
A general challenge every QA team faces is maintaining flawless communication between all the parties involved in a project, i.e. developers, management and customers. An effective communication with the help of a process to follow and maintain helps in productive collaboration. Simple examples of communication include creating a model ticket, establishing code review procedures and clearing labeling schemes. Most teams fail to make proper use of available tools to have an effective communication<\/strong>. This in turn raises issues like sudden changes in the code or a minor change in the requirement that wasn\u2019t documented or mentioned in the user story. We believe in usability testing and like to find even the simplest of usability flaws in a software. However, on looking closer we find that the software was delivered by the development team without understanding the requirements. The issue is then classified as \u201cWorked as designed.\u201d We\u2019ll never be able to catch every weird, obscure bug, but there are always some design elements where they tend to lurk. By focusing our testing efforts on some of the following areas \u2014 or at least not neglecting them \u2014 we can catch more issues before our customers do: QA team can come up with new testing strategy in the agile world of short sprints to deliver the quality product. Some of the testing approaches can be: SBTM<\/strong>: Session-Based Test Management \u2013 It is \u201ca method for measuring and managing exploratory testing.\u201d In a nutshell, it is a Test Management Framework which is made for effective exploratory testing and finding results without executing test cases. Defect tracking is one of the most important aspects of the defect lifecycle. This is important because the test teams open several defects when testing a piece of software, application or website which will only multiply if the system under test is complex. In these scenarios, managing the defects and analyzing these defects to drive closure can be a formidable task. \u201cPriority\u201d is associated with scheduling the fix, and \u201cseverity\u201d is associated with standards. This is undoubtedly the most important of the best QA testing practices that every QA team should perform regardless of the type of project. There are standard ways to define Test strategy and Test plan that most companies are using to mention the pointers in the document and then dumping the same in the repository and never referring to the same. \n\nHow we like to use Test plan document is:\n\n<\/p>\n\n\n\n There are a lot of terms and phrases used in the world of software testing. From a wide range of different testing methods, to a variety of testing types, and many test case templates that make up a software or application test, it can be hard to remember what exactly each term means. We like to keep things simple at Argil DX and just focus on the core of testing. Take for example \u201cTest Cases\u201d and \u201cTest Scenarios\u201d; what\u2019s the difference and why are they needed? How does it help?<\/strong> So, these are the seven best QA testing practices that we follow at Argil DX.<\/p>\n\n\n\n Read about the implementation of Software Testing Life Cycle (STLC) here<\/u><\/a>. You might also be interested in reading our Testing Guide for improving website performance<\/u><\/a>. For any queries related to software QA testing principles or performance testing and enhancement, reach out to us. We’d be glad to help you!<\/p>\n","protected":false},"excerpt":{"rendered":"
Tickets in Pivotal Tracker or Defect Management Tools like JIRA are fundamental part of the best QA testing practices at Argil DX \u2014 we use them all day, every day. Whether you\u2019re describing a bug or a feature, ensure that the ticket you create is described in a detailed and easily understandable manner.
It\u2019s the ticket creator\u2019s job to give the exact details necessary to address the ticket<\/strong> – the title or summary, the body or description, the steps to reproduce the labels if required. It should clearly state the problem and\/or the expected outcome.
When creating a ticket, you can use sub-tasks<\/strong> if you feel that it’ll be helpful in breaking up the main task to create smaller tasks that are easier to achieve. Remember, never create an incomplete ticket. Sometimes, tickets are prepared hurriedly and on the go during a meeting or sanity testing and require more descriptions to be added later. That\u2019s OK<\/strong>. However, it\u2019s a common scenario where the description section is simply skipped over because it is assumed the title will infer the outcome.
Every time you create a ticket ask yourself the following questions before completing.
a. Will someone else easily understand this ticket?
b. Did you provide the detailed information and your own insight?
c. Could you easily give this ticket to a QA team member from another project and would he or she still be able to check it without any extra explanation?
If you answer these questions with an emphatic yes, especially the last one, then it\u2019s a good sign that the ticket is ready for the world.
Lastly and most importantly, always keep your tickets up to date<\/strong>. Always add information about changes in the project, even if they are small ones. For example, if you decide to change the content, mention it. Remember your QA pays attention to detail and after noticing the updates, they will decide if the particular changes were intended or not. If a new mockup is ready, always replace the outdated file with the latest version. <\/p>\n\n\n\n 2. Testing to meet the usability or UX standards your customers expect<\/strong> <\/h5>\n\n\n\n
This is where we must communicate more with our clients and understand what the best user experience will be<\/strong>, by keeping in mind the type of users who will be using the software and some day-to-day activities conducted on that software\/website\/application.
The most common thing in all top-notch testers is their laser-like focus on the user experience. It\u2019s far too easy for testers to get lost in the weeds of test cases and forget about the actual end user, however this is a fatal mistake.<\/p>\n\n\n\n![\"QA](\"https:\/\/www.argildx.us\/wp-content\/uploads\/2020\/02\/Optimized-QA-Graph-1.jpg\")
<\/figure><\/div>\n\n\n\n
a) Too many fields on a single page<\/strong>:
Your end users are probably doing multiple things at once, so if you give them more than 10-15 fields to enter before they can save, it is an issue. You can suggest using a multipage form or a method for the user to save a transaction in a temporary state. The idea is to create more user-friendly design and workflow of that module.
b)<\/strong> Authoring experience in CMS website<\/strong>:
So many companies have a separate team of content authors, and they are always putting content into the website daily. In scenarios like these, the content authors become your end users. It becomes imperative for any QA team member to put themselves into their shoes while testing a component and suggesting a change in the authoring experience. The authoring of any page or component should be easy to understand and the most important fields or options to be highlighted first and then user should move to the less important authoring fields.
c) User journey in a software, website or application<\/strong>:
This is a very important area of focus while testing any product as this is the foundation on which user experience or usability was introduced in the world of QA. There are many researches and reports of applications with good concept and idea failing in the market because of bad user experience caused by an unsatisfactory user journey. The user journey should be extremely simple and easy to understand with desired results displayed at every step of the way. Otherwise, the user gets exhausted because they are just selecting options and nothing relevant to their search is displayed.
<\/p>\n\n\n\n![\"metal](\"https:\/\/www.argildx.us\/wp-content\/uploads\/2020\/02\/gray-metal-building-structure-2308120.jpg\")
3. Build an exciting framework of testing approach:<\/strong> <\/h5>\n\n\n\n
a) QA team should develop a healthy relationship with Business Analysts.
b) Ensure that every user story is specific to what you want to tell the user. It should also be testable and include an acceptance criteria.
c) Don\u2019t ignore non-functional testing such as load, performance and security testing. Make sure that we do both functional and non-functional testing from the very start of the project.
d) Build meaningful end-to-end test scenarios by utilizing trends, data and analytics from the existing product to gather information about user activities and user journeys through the application.
e) Build a strong testing\/QA practice which drives development. Define an Agile QA Testing Strategy<\/strong> and adopt tools which have a good amount of customization available for the need of your project.
f) Conduct regular QA workshops within the team where the testers can improve their technical skills as well as soft skills.
g) Take advantage of technical architecture diagrams, models of the application and mind maps to implement suitable test techniques.
h) Embed QA within the teams with appropriate owners, so that they are aware of any changes to the application.<\/p>\n\n\n\n 4.<\/strong> Implement SBTM \u2013 Session Based Testing Management:<\/strong><\/h5>\n\n\n\n
Exploratory testing is always unscripted, unrehearsed testing. Its effectiveness purely depends on several intangibles: the skill of the tester, their intuition, experience, and ability to follow hunches and look for unexplored areas. It’s these intangibles that often confound test managers when it comes to being accountable for the results of the exploratory testing performed.
For e.g. at the end of the day, when a team lead or manager asks for the status from an exploratory tester, they may get an answer like “Oh, you know… I tested some modules here and there, just looking around as of now.” Even though the tester may have filed several bugs, the manager might have no idea what they did to find them. If the lead or manager was skilled enough to ask the right questions about what the tester did, the tester may have forgotten the details or may not be able to describe their finding in a quantifiable manner.
For this very problem, there is a framework named Session Based Test Management (SBTM). This framework can be used in the form of a template (Session Metrics \u2013 Derived from the sessions performed) which will document the effort spent on the exploratory testing. This documentation is named as session metrics which are the primary means to express the status of the exploratory test process. This contains the following elements: <\/p>\n\n\n\n 5. Effective use of severity and priority: <\/strong><\/h5>\n\n\n\n
It is a useful practice to add Severity & Priority to each of the bugs entered in the system for a project. It helps all the stakeholders to track and maintain the bugs and prioritize the fixes accordingly.
However, this is a very confused concept and almost used interchangeably by test teams as well as development teams. There\u2019s a fine line between the two (Severity & Priority) and it\u2019s important to understand that there are indeed differences between the two.
Let’s have a quick look at how these two differ from each other.<\/p>\n\n\n\n![\"defining](\"https:\/\/www.argildx.us\/wp-content\/uploads\/2020\/02\/Optimized-Picture2.jpg\")
<\/figure><\/div>\n\n\n\n
\u201cPriority\u201d signifies that something is important and deserves to be attended to before others.
\u201cSeverity\u201d is the state of being marked by strict adherence to rigorous standards or high principles.
The words priority and severity always come up in bug tracking. Determining the severity of a bug helps the development team to prioritize the bugs to be fixed. The priority status is often used by the product owners to determine which bug needs attention before going live.
You can find a range of software tools for commercial, problem tracking or management. These tools, with the detailed input of software test engineers, give the team complete information so that the developers can understand the bug, get an idea of its \u2018severity\u2019, reproduce it and fix it.
The fixes are based on project \u2018priorities\u2019 and \u2018severities\u2019 of bugs.
The \u2018severity\u2019 of a problem is defined in accordance with the customer\u2019s risk assessment and recorded in their selected tracking tool.
A software that contains bugs can affect your release schedules leading you to reassess and renegotiate the project priorities.<\/p>\n\n\n\n 6. Defining best test strategy and test planning<\/strong> <\/h5>\n\n\n\n
We should not only define the Test strategy and Test plan document but also review it constantly with our clients and update them according to the different phases of the project.
<\/p>\n\n\n\n![\"an](\"https:\/\/www.argildx.us\/wp-content\/uploads\/2020\/02\/test-plan-img-1024x683.jpg\")
<\/li>
– Unit Test Plan
– Integration Test Plan
– System Test Plan
– Acceptance Test Plan
– Story\/Module Test plan
<\/li>
Test Plan Guidelines<\/strong>
1. Make the plan concise. Avoid redundancy. If you contemplate that you do not need a section that has no use in your project, go ahead and delete that section from your test plan.
2. Be specific to every detail you provide in the test plan. For e.g., when you specify an operating system as a property of a test device, mention the OS Edition\/Version as well, not just the OS Name.
3. Make good use of lists and tables wherever possible. Avoid lengthy paragraphs and convert your information into bullet points.
4. Make sure that the test plan is reviewed by all the stakeholders several times prior to baselining it or sending it for approval. The quality of your test plan will entail the quality of the testing you or your team are going to perform.
5. Update the plan as and when required. An outdated and unused document is worse than not having the document in the first place. <\/li><\/ul>\n\n\n\n 7.<\/strong> Writing test scenarios instead of test scripts:<\/strong> <\/h5>\n\n\n\n
In brief, a Test Scenario is what <\/strong>to be tested and a Test Case is how <\/strong>to be tested. Moreover, a test scenario is supposed to be a collection of test cases. <\/p>\n\n\n\n![\"a](\"https:\/\/www.argildx.us\/wp-content\/uploads\/2020\/02\/Picture3-1024x605.png\")
Test Scenario<\/strong>
The purpose of writing test scenarios is to test the end-to-end functionalities of a software application, to ensure the business processes and flows are functioning as needed. In scenario testing, the tester thinks like an end-user and determines real-world scenarios (use-cases) that can be performed. Once these test scenarios\/use cases are determined, then these test scenarios can be converted into test cases for each scenario. Test scenarios are the high-level concept of what to test, covering the major functionality of any module of a project.
Test Case<\/strong>
The test cases are a bunch of steps to be executed by a tester in order to validate the test scenario. Wherein test scenarios are derived from use cases, the test cases are derived and written from those test scenarios. A test scenario can have multiple test cases associated with it, because test cases lay out low-level details on how to test those scenarios.
Example<\/strong>
Test Scenario: Validate the login page of a certain application.
Test Case 1: Enter a valid\/invalid username and password
Test Case 2: Reset your password or click on the reset password CTA. (Call to Action – Button)
Test Case 3: Enter invalid credentials in both the fields <\/p>\n\n\n\n