Continuing the previous tip, I provide sample MS Word document template you may use for bug reporting. What does it have to do with Excel?

- You can use a single Excel document as a "one-stop-shop" container for the bug reports. And this is the idea of today's tip.



By following a simple one-time setup procedure you can embed the document template into your Excel report.

• Select the cell you want to contain the attached document(in the example that's an "Attached Documents" cell).


• In the Excel's Main Menu, select "Insert / Object".


• In the "Object" dialog, select "Create from File" tab.


• Keep "Link to File" option unchecked.


• Click "Browse", select the document in "Browse" dialog, and click "Insert".


• Click "OK" to embed the document.

Afterwards, you can create new copies of a template within the Excel report document as simple as "select template cell - Ctrl-C - select destination cell - Ctrl-V".

Today's tip is for those testers who use standalone Excel-based reports.



The picture above represents a typical "Summary" tab enlisting reported issues, status, short description, etc. Detailed descriptions along with the images are usually stored on a separate tab.

 

Now what you can quickly and easily do is to connect 2 data rows from separate tabs with a hyperlink.

• Select the cell you want to use as a navigation control (in the example that's an "Issue #" cell).


• In the Excel's Main Menu, select "Insert / Hyperlink".


• In the "Edit Hyperlink" dialog, select "Place in This Document" tab.


• Select target tab name (in the example that's "Screenprints" tab).


• Type in the cell reference (in the example that's "A3").


• Click "OK" to save settings.

The harsh reality is that in the tech world, companies prefer to hire young, inexperienced, engineers.

This is the first statement given in article "Silicon Valley’s Dark Secret: It’s All About Age". The author also gives advices "to those whose hair is beginning to grey", where main of them is:

Move up the ladder

Move up the ladder into management, architecture, or design; switch to sales or product management. Build skills that are more valuable to your company, and take positions that can’t be filled by entry-level workers.

As I think this is an honest advice, I don't consider it the only advice. If you are passionate about your technical job you can keep up as long as this kind of job is needed - and that fully applies both to testing and programming.

More specific to testing, I want to note the following.

• Build and consistently demonstrate ability to accomplish more in less time. Maybe you can't always stay at work 60 hours a week but you will be able to get the job done in regular hours, if you practice time management, risk assessment, and problem-solving heuristics.


• Learn from projects you work on. Whether it's content management system, an online banking application, or back-end VOIP cluster, learn and consciously integrate into your expertise both domain-specific knowledge and "soft", transferrable, approaches.


• Learn about and try practicing technologies you work with. Use collaboration opportunities, talk with other passionate specialists - they will love to teach you.


• While developing technical skills build big picture vision as well. Technologies come and disappear, problems and problem-solving techniques remain.


• Stay passionate.

The other day 1202Performance had an interesting post on how Citrix improves response times. While I don't think the post addresses the subtleties of how Citrix works, I think the simplification might be useful to those new to Citrix. You can check it out here.

Today's tip comes from Peter Kartashov's article in his AT4QA blog.

One day, our team was not ready to run on time full regression tests against fresh build because of recent changes in DOM tree for many objects. We were in need to invent something robust, not silent and not verbose; this mechanism should report something into logs when a control was not found directly but it should attempt to recognize that control using set of provided properties.

After a short experience report on maintenance problems caused by large volume of automation scripts and complexity of GUI DOM tree, Peter provides analysis of downsides of default GUI recognition logic, and shares solution example - as the functional diagram and code snippet.

In the nutshell, the idea is brilliantly simple: supplying more than a minimal set of object recognition properties greatly improves automation scripts' robustness and enables automatic cross-checking between object's location and object's properties.