Importance of good communication between Developers and QAs
Imagine that you’re getting to a bus to Pettah. If you don’t pay attention to the precise detail, you might find yourself in bus to Jaffna.
Imagine a Girlfriend and Boyfriend, living in the same building, are not communicating with each other. They just text each other if anything important needs to be taken care of. Otherwise, both are busy with their own lives and do not disturb/take care much about each other. What happens after days? A frustration rises, irritation multiplies, anger surfaces and finally an explosion occurs. Any relationship strengthens only if there are frequent communications, rare fights and multiple agreements and celebrations exist with each other.
It is an example when you are not speaking to someone face to face, can cause confusion.
Now, compare those situations with the software project lifecycle.
Communication is one of the most important soft skills a software tester must have. Communication between testers and developers is crucial, and it is definitely help to a successful projects.
Poor communication can lead to misapprehend, impact productivity, and cause a lot of rework, especially when reporting defects and working with remote teams as in what we do at Embla. Only Tools, Code, Budget or infrastructure cannot successful the project. That is always people who made the project successful. Basically a team is required and not an individual.
It was always real people who made the project successful. And to make something successful, a team is required and not an individual.
Today’s businesses are adopting DevOps and continuous delivery and demanding more releases with higher quality (not just finding bugs in JIRA), so it’s important for testers to constantly upgrade their skills.
You can take to build your career and make yourself (and the test team) more valuable to your organization. By leveraging the right resources, including developer and application performance management (APM) tools, you can play a bigger and more collaborative role in producing higher-quality output.
Most of the testers are following manual tests,one of the reason is they are afraid of using “tools a developer would use” to achieve top metrics. Most testers are not familiar with the terminology around JavaScript, CSS, XHR, Java, .NET, PHP, Nginx, node.js, Android, or iOS, and because they don’t speak the same language, they fear that they will not be taken seriously by developers if they present this new set of test results.
This is why testers should take advantage of the built-in browser diagnostics tools that come with Firefox, Chrome, Safari, and Internet Explorer. Click on the Network Tab and start executing your manual tests. After every click, check the information in the status bar. It will tell you how many roundtrips it took to load that page and how many bytes had to be downloaded.
If you see more than a hundred resources and 5 megabytes or more in page size, report that test as failed. If you let this build move on to the next testing phase (or into production), chances are very high that this web application will crash under load.
How to writing a rock-solid bug report
I have created a basic template with the help of Google to guide reporting bugs, it’s simple, efficient and most QA follows at the moment. Here you go the five essential steps
* Be specific: Clearly summarize what the problem is — get straight to the point.
* Be descriptive: Include every single step to reproduce the problem; add screenshots.
* Be focused: Pay attention to what really matters — the actual problem that needs to be fixed.
* Be organized: Report only one problem at time. If there’s more than one problem related to the feature you’re testing, split them into separate issues so they can be quickly fixed and tested.
* Take time: The title or subject is very important when triaging defects because it helps to instantly identify what the problem is without getting into details. So take time to write something specific; it will save you time in the long run. For example, saying that “the system is not working” is very vague and does not give developers enough information to help find the root cause in order to fix the issue.
Yawn…! It’s always better to discuses with your developers or the client then and there if you see a problem without keeping to yourself, that can save a lot of time of both development and testing, do it often,follow the requirements, changers happened during the sprints.recall it,same like you recall something happened in 3000BC when you fight with your girlfriend/ boyfriend.
