Google has just released Chrome 10 beta (10.0.648.82 for all you perfectionists) and it brings with it a whole slew of new things to play with.
First off, there’s a significant JavaScript performance boost thanks to the updated V8 engine. According to Google, this version of the V8 engine offers a 66% performance advantage over the current stable release. That alone is pretty impressive.
Download Google Chrome beta 10 here.
This code sample library will help all developers to find useful code in various dot net areas. Microsoft goal is to centralized all codes in one place. This library having below things:
ASP.NET MVC 3 is a framework for developing highly testable and maintainable Web applications by leveraging the Model-View-Controller (MVC) pattern. The framework encourages developers to maintain a clear separation of concerns among the responsibilities of the application – the UI logic using the view, user-input handling using the controller, and the domain logic using the model. ASP.NET MVC applications are easily testable using techniques such as test-driven development (TDD). The installation package includes templates and tools for Visual Studio 2010 to increase productivity when writing ASP.NET MVC applications. For example, the Add View dialog box takes advantage of customizable code generation (T4) templates to generate a view based on a model object. The default project template allows the developer to automatically hook up a unit-test project that is associated with the ASP.NET MVC application. Because the ASP.NET MVC framework is built on ASP.NET 4, developers can take advantage of existing ASP.NET features like authentication and authorization, profile settings, localization, and so on. Go through this help to get started MVC 3.
MVC stands for model-view-controller. MVC is a pattern for developing applications that are well architected and easy to maintain. MVC-based applications contain:
When working with SQL Servers or other features that are version-specific, you often need to know what version of SQL Server is running on the target server.
For SQL 7.0 and earlier, You can query
SELECT @@VERSION
And the following query will work on SQL Server 2000 and up:
SELECT 'SQL Server '+ CAST(SERVERPROPERTY('productversion') AS VARCHAR) + ' - '+ CAST(SERVERPROPERTY('productlevel') AS VARCHAR) + ' ('+ CAST(SERVERPROPERTY('edition') AS VARCHAR) + ')'
Here is the description of all the status with its brief description
1. Bug: When QA files new bug.
2. Deferred: If the bug is not related to current build or cannot be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.
3. Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.
4. In Process: This is the state of issue when Developer starts working on the assigned issue.
5. Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
6. Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.
7. Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.
8. Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.
9. Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.
10. Rejected/Invalid: Sometimes developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.
11. Not a Bug: If the reported issue is not a bug or not for the current build then project lead or manager will set the status to 'NAB'
Here is the synopsis on writing a good bug report. Hope you all know about Bugs. Here I’ll tell you how can we write better bug reports and how to use bug tracker.
Why we need a good Bug report?
If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it. If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible.
1) Reproducible:If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.
2) Be Specific:Do not write a essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.
3) Having clearly specified bug number: When you are talking about the bug, identify it with bug number. Ex: Issue 101 etc. This will help to identify the bug record. Note the number and brief description of each bug you reported.
How to Report a Bug in Bug tracker?
While reporting a bug, don’t forget to mention version, Product, component or module, Platform (Ex: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’ etc.).
Operating system (Ex: Mention all operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc.)
Title: Should be easy specific to the bug.
Priority: When bug should be fixed? Priority is generally set from High to Low.
Status: When you are logging the bug in bug tracking system you can find different status, I have given more detail about test status in my blog here.
Comments: A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is.
A detailed description of bug. Use following fields for description field:
Reproduce steps: Clearly mention the steps to reproduce the bug.
Expected result: How application should behave on above mentioned steps.
Actual result: What is the actual result on running above steps i.e. the bug behavior.
URL: The page URL on which bug occurred is always helpful
All your comments will be seen in chronological order.
Attachments: Any screen shot or related document is helpful for developer or your manager. A picture is more powerful than mere words.
History: History will tell you all the activities related to the issue among the users.
Some Bonus tips to write a good bug report:
1) Report the problem immediately: If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.
2) Reproduce the bug three times before writing bug report: Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.
3) Test the same bug occurrence on other similar module:
Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.
4) Write a good bug summary:
Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.
5) Read bug report before hitting Submit button:Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.
Conclusion:
Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.
