In this post we will discuss the role of a tester in these phases and how to testers can prevent more defects in Defect Prevention phase and how testers can detect more bugs in Defect Detection phase
Role of a tester in defect prevention and defect detection.
Defect prevention – In Defect prevention, developers plays an important role. In this phase Developers do activities like – code reviews/static code analysis, unit testing, etc. Testers are also involved in defect prevention by reviewing specification documents. Studying the specification document is an art.
While studying specification documents, testers encounter various queries. And many times it happens that with those queries, requirement document gets changed/updated.
Developers often neglect primary ambiguities in specification documents in order to complete the project; or they fail to identify them when they see them. Those ambiguities are then built into the code and represent a bug when compared to the end-user’s needs. This is how testers help in defect prevention.
Defect Detection – In Defect detection, role of a tester include Implementing the most appropriate approach/strategy for testing ,preparation/execution of effective test cases and conducting the necessary tests like – exploratory testing, functional testing, etc.
To increase the defect detection rate, tester should have complete understanding of the application. Ad hoc /exploratory testing should go in parallel with the test case execution as a lot of bugs can be found through that means.
Defect Prevention early in the cycle has the following benefits:
Chrome can be used to simulate a slow connection. Install Chrome if it is not already installed on your system. After that, open a new tab and press CTRL + SHIFT + I to bring up the developer tools window, or click on the hamburger icon, then More tools, then Developer tools.
Now click on Network section – a drop-down menu of pre-configured speeds appears, which you can use to simulate a slow connection.
To add your own custom values, click the Add button under Custom. To create a new profile, click the Add Custom Profile button.
This is an excellent tool that is integrated into Chrome that you can use to determine the load time of your website on slower connections. Please feel free to leave a comment if you have any questions. Enjoy!
The purpose of the test pyramid is to provide a structure for designing and executing tests. It is also the cornerstone of testing at Google.
The test pyramid has four layers – unit tests, service tests, integration tests, end-to-end or acceptance tests. By dividing up the different types of tests into these levels, it becomes easier to decide what type of testing needs to be done when building and maintaining software.
To that end, Google employs a four-stage testing process for changes to the search engine, consisting of:
Testing by dedicated, internal testers (Google employees)
Further testing on a crowdtesting platform
“Dogfooding,” which involves having Google employees use the product in their daily work
Beta testing, which involves releasing the product to a small group of Google product end users
Facebook: Developer-driven testing
Facebook employs a wide variety of automated testing solutions. The tools that are used range from PHPUnit for back-end unit testing to Jest (a JavaScript test tool developed internally at Facebook) to Watir for end-to-end testing efforts.
Amazon: Deployment comes first
The feeling at Amazon is that its development and deployment processes are so mature (the company famously deploys software every 11.6 seconds!) that there is no need for elaborate and extensive testing efforts. It is all about making software easy to deploy, and, equally if not more important, easy to roll back in case of a failure.
Spotify: Squads, tribes and chapters
Testing at Spotify is taken very seriously. Just like programming, testing is considered a creative process, and something that cannot be (fully) automated. Contrary to most other companies mentioned in this article, Spotify heavily relies on dedicated testers that explore and evaluate the product, instead of trying to automate as much as possible.
Microsoft: Engineers and testers are one
Microsoft’s ratio of testers to developers is currently around 2:3 (SDETs)
Shift Left is a buzzword in Software Testing. It is not new, in fact it has always been around. Shift left is all about creating a culture where testers can be involved early in the software development life cycle to start testing activities early. Idea is to reduce the risks.
Perhaps inspired by the maxim, “a stitch in time saves nine”, Shift Left is a practical attempt to actually ensure a timely stitch; to check for errors in the software testing process earlier than the conventional time to do so. Shift Left testing means testing earlier in the software development cycle, so that risks and unknowns can be reduced which enables smooth deliveries to the clients.
Performing testing activities late in the cycle results into – failure at managing the evolving demands and requirements, and as such soon produces unhealthy consequences for the organization ranging from higher production costs to extended sales time, and accidental defects.
When Shift Left practices are put in SDLC, the software system testing activities takes place much earlier in software development life cycle. The goal is to fix any minor looming issues that might crop up in the future of the project, and thereby meeting the marks of quality in delivery. So when organizations adopt the Shift Left strategy, they are able to test, analyze project, pass judgment on the system and refine it into something much better bit-by-bit.
Few Examples of Shift Left:
Pair with the developers – More Collaboration and brainstorming on the requirements / test scenarios with the Team (including Devs and PO) so that unknowns and risks can be discovered earlier in the phase. Both Devs and QEs will have the same understanding on the requirements.
Rework (Issue fixing & retesting) will be less.
Scope creep will be less.
Test different layers – In SOA applications, APIs are developed first. Team should plan the API testing so that issues can be identified early in the cycle (rather than just testing from the UI).
Plan Non-functional Testing early in the cycle (Performance Testing, Security Testing etc) – Identifies issues early and reduces the risks.
Automate the “Automation Test Case Execution” – Integrate the automation scripts with Jenkins/any Build automation tools that automation scripts should run in CI region before the new code deployment. It will help in ensuring that new code change is safe or not.
Automate Unit Tests, Integration tests, API Tests – These tests runs faster and help in identifying the defects early in the cycle.
By carrying out a Shift Left operation, it is possible to efficiently improve the speed of delivery of the project. This is because they get to find out all the flaws quickly enough in the development phase of the software, reduce the time interval between releases while making the necessary adjustments, and finally producing a refined and quality software. A well-calculated procedure can in fact lead to the quality development and timely completion of tasks. The idea of Quality Assurance is the eventual improvement of these procedures after their development and documentation.
Software Development free of Hassles
All the project requirements become clear to every member of the organization when the errors are detected at an earlier time in the requirement phase.
Meeting Customer Demands sufficiently
Shift Left technique improves your client satisfaction mark, as the approach enables you deliver faster and more quality tasks.
Rework is reduced – Defects caused by humans to be minimized.
Time can be saved and team can focus more on Automation Testing.
Risk is reduced – Cut-down complications that could surface in the production phase.
To Summarize, Shift Left is a step towards:
Delivering QUALITY @ SPEED
Reduce the COST without cutting the RESOURCES
Here is an awesome video (less than 5 minute) to understand the Shift Left concept –
Sometime back, I was searching for “Software Testing Tips”, “How to become a smart software Tester”, “Tips for Software Testers”, etc on Google.com. I come across various websites and in most of the websites, I got these tips – “Have a good test plan”, “Learn & Improve Your Skills”, “Understand the product”, “Write clear, descriptive, unambiguous bug report”. BULLSHIT. These are required skills of a software tester. So here is my Part 1 of “Practical Software Testing Tips to become a Smart Software Tester.”
Tip 2: Before the developers deliver the code, have a discussion with them on the functionality/Business rules you have covered in the test cases. Ask them what addition rules they are covering in the code, how the UI will look. This discussion is very required if you want to reduce the QE / Dev conflicts and rework time during test case execution. In case you get conflicts, get it resolved from requirement owner.
Tip 3: Think technically – Try to understand how the application will be designed. Think and ask the developers/DBAs: What will be the db design? Any part of code is being reused in multiple places?
Tip 4: Before you report any defect/bug, Are you discussing/confirming it with Developers? If YES, then you are wasting your time. STOP DOING THIS. Be confident and Report defects promptly.
Tip 5: Whenever you got a new feature to test, do a 15¬20 minute high level test to make sure that newly implemented feature is stable. In case you encounter any blocker issue, send a high priority email to the Dev/QE group saying this need to be fixed on priority.
Tip 6: Before you start Test Case Execution, prioritize your test scenarios. For example ¬ scenarios related to Business rules can be of high priority and need to be tested on Priority. Usability or negative testing scenarios can be tested after that. [This is just an example, testers need to decide based on the scope of testing].
Recent Comments