🚀 The Importance of Employing Shift Left Testing in the Testing of Modern Day Applications

 👉 Modern apps must be tested using a shift left methodology, especially when using agile and DevOps practices. It entails bringing the testing phase up front in the software development lifecycle,often beginning with the requirements and design phases and continuing through development. Shift Left testing is crucial for evaluating contemporary applications for the following main reasons:

 
👉 Early Issue Identification: Issues and flaws can be found and fixed at a stage in the development process when they are less expensive and time-consuming to fix. This is accomplished through testing early in the process. This reduces the likelihood of critical issues surfacing later in the development cycle or in production.
 
👉 Faster development Cycles: The creation and upkeep of modern apps frequently call for quick turnaround times. Shift Left testing shortens the development process by identifying problems early and allowing for quicker feedback and iteration.
 
👉 Greater Collaboration: Shift Left testing promotes cooperation amongst stakeholders in development, testing, and other areas. To establish test cases, requirements, and acceptance criteria, testers,developers, and product owners collaborate closely. This improves communication and understanding of the project's objectives.
 
👉 Enhanced Quality Assurance: By including testing in the development process, you can make sure that the application is created with quality in mind. This results in better user experience and higher-quality software with fewer bugs.
 
👉 Continuous Integration and Continuous Delivery (CI/CD) are common in contemporary development methodologies like DevOps. This strategy may test code continuously while it is being produced and integrated into the application thanks to shift left testing.
 
👉 Savings on costs: Resolving problems early in the development cycle can sometimes be more affordable than waiting until the end of the cycle or during production. By minimizing the need for time-consuming post-release issue fixes and maintenance, Shift Left testing can help organizations save money.
 
👉 Compliance and Security: Many contemporary applications work with sensitive data and are subject to security and compliance requirements. Shift Left testing can aid in the early detection of security flaws and compliance problems, lowering the likelihood of security breaches and compliance violations.
 
👉 Shift Left testing fosters an environment that values ongoing development. Teams can gain information from their testing outcomes and apply it to upcoming development tasks, resulting in continuing improvements to the testing procedure and overall software quality.
 
#softwarequality #shiftleft #qaphilosophy #Testingapproach

How to Deal with Not Reproducible Bugs???

As promised folks, come up with fresh article which every tester's face such situation across his career. I have tried enough efforts to highlight how to deal and what possible things you can try out to make it reproducible from not reproducible.

This kind of situation is nightmare for tester/QA community, specially when your application is live and customer is getting affected financially.As a Tester, i have come across of situations where some bugs won’t reproducible most of the times and i infer that many of the testers might have gone through the same situation multiple times across his/her testing career.Its tough to convince the developers from QA perspective for not reproducible bugs.When count of Not Reproducible getting increased, Chaos start from every end(Client,Third Party,Project Management Body,Top Management, Developer).Everyone is trying to prove that i'm not the culprit and QA is trying to find some support, most of the cases he won't get any.

Possible things you should try to reproduce the not reproducible.

1.Multiple post back via CTRL+F5 from browser - Check whether multiple request getting submitted or not. Ideally Duplicate request should not be submitted if you press CTRL+F5 from the page where you submitted the request already in on going session.

2.Due to caching of browser - Make sure you attempt clearing a browser cache. Might be caching data not allowing you to get the desired result.

3.Multiple insert on clicking button or link multiple times
4.Due to loose connectivity between DB and Server, Transaction is slow.Getting completed but not reflects to user.

5.Database table definition change i mean New Column introduced which is causing such behavior. Sometimes DB/Dev team has just altered the table definition or insert the new column or delete the new column but not communicated to QA and while testing with those changes showing some abrupt behavior.

6.Latest Store procedure/DB changes might throwing some non-sence :) 

7.Try entering the same data(Ditto) and enter the same record in the system.
Personal Observation : Same record getting displayed as success on screen but not getting reflected on the DB.

Demand/Things to do to reproduce the not reproducible:

1.First steps to deal with such bugs as QA is, Keep yourself Calm and have patience.Don't get frustrated even after the multiple attempts from your end with all possible things you can try.

2.Ask dev team whether proper logging mechanism is in place and specially the bug reported event getting logged into the application logs.

3.Ask for the exact or around time when issue has occurred and investigate along with DBA what DB activity has happend during that time.

4.Observe the things precisely and take a note of output on each stage of the transaction.

5.Try looking into your test results and check whether you reported such incident which is occurring in a rarest case.

6.Demand for exact sequence and Screenshot/Video for the instance occurred at client end(Politely or in a way he doesn't get offended :)).

7.Try to replicate the bugs in all available environment(Dev,QA,Staging/Pre Prod/live)and check whether you are getting the same result on all environment,If not get deeper into the environment where you get the different results.

8.Check the Hardware/Software details of the environment on which not reproducible been spotted.

9.If your customer is supportive, ask him/her to show case the exact sequence via remote to you.But this is something which you should try when you are running out all the options.

10.Make sure customer is following the guideline sent to them along with the software delivery i mean Min System config,Hardware/Software recommended or any other prerequisite.

11.Client running the software with all proper system configuration.

My First Philosophy Post !!!

Hello Everyone,

Hi,this is Chintan Javia and am having an experience of 9 years in QA/Testing area. Across 9 years i have sailed through many domains and experience with working in each domain is thrilling so far. I will share all these testing memories in upcoming articles/post.Excuse for typos and terseness as am from vernacular medium :)

I was thinking to start writing the blog since long but lazy bones resides me always win over my idea to start the blog.But as old saying never say never late.This blog i don't want to limit to testing/QA will write on more wider range.

How QAPhilosophy born?

Don't put so much stress on figuring out why this names, i didn't do much for the same.I was looking for some fancy name and as usual google the savior. Initially i thought it to be some Greek name (Inspiration from my previous project's module name) but somehow its not went well and finally google search won.So this is the story behind the scene on how QAPhilosophy born...

What is My QAPhilosophy?

Generally when its come to QAPhiolosophy, I believe until the work is getting done all is fine.

Few points to consider to become a successful QA :

1.Always try to put attention on business requirement not the requirement stated by BA .Try to break all the so called bugs functional, requirement Gap,UI/GUI,Integration bla bla... in the first cycle itself, it will make your life more easier and everybody will realize this guy will make my go live smooth and you break the ice almost in the first shot.

2.Maintain healthy relationships with all the stack holder Starting from top management to trainee/intern.(This is in a good sense).I personally experienced the benefit of keeping the relationship.... As per the old saying you must be in war with dev with all the time.. I am able to recall the instances where i was stucked or in very pressure situation at client end/offshore and dev team help me to get hell out from there crossing their scope of work.By the way am i die hard tester still...

3.Be it QA engg/QA lead or any damn QA, Once you allocated with any project, try to verify all the aspect and scope and what client expect rather than just falling into the routine activity ---> Writing test Case >> Test Execution >> Defect Logging >> Defect Tracking etc etc...

Things taken into the consideration while jumping into the new project/product...

1.What work has been done and delivered before you entered that magical project/product.
2.What role you are going to play as QA?
3.What difference you are going to create with your injection(Manager's love this)

4.One thing i always see as a difference creator is client communication and i love this.Initially when i was in inception of my QA career i was kind of shy/afraid to face the client but over the years i have learn that i was able to think differently and got so many clear requirement after talking to client only.

Things I have learnt from constantly talking to client are :

1.Got the actual idea about what he require and what he wants us to do.
2.By asking the constant feedback, I was able to rectify the things which he doesn't want in early stage.
3.Able to understand user behavior and how the project/product is going to utilize in that geography.Every geography is having different pattern of accessing the product and you must consider it as one of the key aspect as your testing activity.

Okay folks,This is an end of my first post. Keep watching this space for more updates.
Have a Happy testing till then....