Epic Story > Get a Git server running on an AWS hosted Linux server

New Year's resolution: git (see what I did there?) started on source control.

As a Test Automator
I want to have a Git server running on my own AWS hosted Linux server
So that I'll always have complete and up-to-date access to all my source code

C# > Code Smells

From Adaptive Code via C# by Gary McLean Hall

Code smells:

• Static methods
• Static classes (including singletons = classes which can only be instantiated by one object)
• Object construction that uses new
• Extension methods

Code perfumes:

• Interfaces
• Dependency injections
• Inversion of control
• Factories

C# > Setting up NUnit in a solution

How to get NUnit working in a Visual Studio 2015 solution:

1. Create a new solution
2. Create under that solution two projects: YourApplication and YourApplicationTest
1. In this setup we'll write our unit tests in a separate project (YourApplicationTest). Whether the unit tests are written in the same project (pro: code can test itself, con: double the namespace filled up) is a matter of personal preference.
3. In YourApplicationTest do the following:
1. RightClick the project in the solution explorer and choose 'Manage NuGet Packages'
2. Using the NuGet Package Manager:
1. Install NUnit version 2.6.4(!!)
2. Install NUnitTestAdapter 2.0.0
4. If all went well then it's now possible to write unit tests in the YourApplicationTest project. The problem remaining is that we want to write the unit tests for YourApplication in YourApplicationTest and encapsulation will prevent that out of hand. Therefore
5. In YourApplication do the following:
1. In assemblyinfo.cs add:
1. [assembly:InternalsVisibleTo("YourApplicationTest")]
6. In classes which contain unit tests in YourApplicationTest add:
1. using YourApplication

Done :-)

First steps in C# (from a Java perspective)

• const keyword (as opposed to 'final'?)
• C# is 'pass by value' unless otherwise specified:
• use the ref keyword with parameters AND arguments to 'pass by reference'
• use the out keyword with parameters AND arguments to 'pass by reference' without being able to access the old pre-method value
• Overloading the constructor:
• public Constructor (params) : this (params) {}
• Pay extra note: the constructor calls are BEFORE the block
• Implementing an interface:
• public class MyClass : IMyInterface {}
• pay note to the 'I' in front of MyInterface. Good convention.
• Inheriting a class:
• public class MyChildClass : MyParentclass {}
• the fact that there is no difference in syntax between inheriting a class and implementing an interface is an EXTRA (good) reason to obey the 'I in front' naming convention for interfaces.
• Overriding a Parentclass method:
• Parentclass method must have the keyword 'virtual'
• Childclass overriding method must have the keyword 'override'
• This make the default 'behavior' of ParentClasses that they CAN'T be overridden. Probably more secure :)
• Again: the keyword 'virtual' and 'override' form a pair which is needed to override methods.
• Calling the Parentclass method from within the Childclass: 
• base.parentMethod(args)

Tosca tips and tricks: printing reports via TCShell

Tosca has built-in reporting functionality. To be able to generate these report via TCShell one can use the syntax:

task "Print Report ... ExecutionEntries with ActualLog" "Report.pdf"

But this won't work until you add the following to your TCShell.exe.config:<Tricentis.TCAddIns.Reporting.Properties.Settings>

  <setting name="DefaultPrintOutputFormat" serializeAs="String">

       <value>ASKUSER</value>

  </setting>

</Tricentis.TCAddIns.Reporting.Properties.Settings>

And - which I found out today to my own detriment - after you install a new Tosca upgrade or release this file will be overwritten by the default and consequently break your TCShell reporting functionality. Something to be aware of.

This is all perfectly described in the following Tricentis documentation:

https://support.tricentis.com/community/manuals_detail.do?sysparm_document_key=u_webhelp,25d579ec37e78640a30fa16043990e3c

https://documentation.tricentis.com/en/900/content/tchb/commander_config.htm#DefaultPrintOutputFormat

https://documentation.tricentis.com/en/900/content/tchb/configuration_files.htm#Structure_config

Note to self: add 'Output (print) reports' to the list of useful Tosca search terms.

Tosca Tips & Tricks: notes on Manual Testing module of TCP

Notes on Powerpoint Presentation by Tricentis as part of the 'Manual Testing' module of TCP:

•  Hierarchy of elements TestCases section:
• TestCase Folder
• TestCase
• TestStepFolder
• Manual TestStep
• Manual TestStepValue
• The name of a TestCase should be unique
• A hand on a symbol -> manual
• Scratchbook is a temporary aid to execute teststeps
• Scratchbook results are not stored
• ActionMode
• Determines how to process value-entry for each TestStepValue
• Default ActionMode: DoNothing
• Hide DoNothing TestStepValues with F9
• Reset Value > Reset value in value field and set ActionMode to DoNothing
• ActionMode: Input
• ActionMode: Verify
• Verification type: ==, !=, < (if numeric), > (if numeric)
• Wildcards (*,?) possible
• Hierarchy of elements ExecutionLists section:
• ExecutionListFolder
• ExecutionList
• ActualLog
• ExecutionEntryFolder
• ExecutionEntry
• ExecutionList: test result colors:
• Green: passed
• Red: failed
• White: not executed
• Grey: no longer available in workspace
• ExecutionLists which have TestCaseFolder/TestCaseInstances added to them can be updated with synchronize
• Test Resuls can be set manually using the command set result
•  Manual Engine options:
• Add comment
• Pausing / Resuming
• Multipassing / Set passed until here
• Run from here (=rollback)
• Exit
• Take screenshots
• ExecutionList vs. RequirementSet
• If TestCaseLinks in the RequirementSet have their testcases included in multiple ExecutionLists which are added to the RequirementSet then the property 'ResultAggregation' gives you control over which results are displayed:
• First: only the topmost ExecutionList's results
• Each: self explanatory
• 
  

Notes on videos by Tricentis as part of the ''Manual Testing' module of TCP:

•  Element order:
• Testcase
• Teststep Folder
• Manual Teststep
• Manual Teststep Value
• Create Manual Teststep: Ctrl+N; Ctrl+M
• Create Manual TeststepValue: Ctrl+N; Ctrl+M
• Follow instructions at the top of the manual testing popup
• Click the green tick for success, and the red cross for failure
• At the bottom row of the popup colored blocks represent the different teststep results (green/red)
• ActionMode 'Verify'. Green colored. Speaks for itself. 
• Testcase vs. Requirements
• Drag and drop a testcase on a requirement and a 'Testcase Link' is created (yellow circular arrow with blue ribbon)
• Requirements column: Coverage Specified (%) & Testcase Link symbol vs. TestCaseWorkstate
• TestCase Workstate: PLANNED
• Coverage Specified: 20%
• Testcase Link symbol has a wrench pointing to three o' clock
• TestCase Workstate: IN_WORK
• Coverage Specified: 50%
• Testcase Link symbol has a wrench pointing to twelve o' clock
• TestCase Workstate: COMPLETED
• Coverage Specified: 100%
• Testcase Link symbol has no longer a wrench in it
• ExecutionList (green triangle with a shadow) 
• Has ActualLog where testresults are stored
• Column 'Loginfo' displays testresults (white/green/red)
• Loginfo also stores comments/errors of failed TestSteps/TestStepValues
• Testcase vs. ExecutionList
• Drag and drop a testcase on an ExecutionList and an 'ExecutionEntry' is created
• ExecutionList vs. RequirementSet
• Drag and drop an ExecutionList to a RequirementSet and
• The ExecutionList will appear underneath the RequirementSet
• The RequirementSet will compare the results of Testcases in the ExecutionList with the TestCaseLinks it has in its own requirement leafs
• And adjust the data accordingly in columns such as:
• Coverage Execution (%)
• Execution State (%)
• TestCaseLinks which are given an execution result by the ExecutionList get a green tick or a red cross in the right lower corner of their symbol
• If the RequirementLeafs have been weighted then the weights will be taken into consideration when adjusting the data in these columns
• You can drag and drop more than one ExecutionList to a RequirementSet
• This is not suprising, because the 'One Testsheet per Requirement' rule means there are several 'TestcaseTemplates' worth of testcases that need to be linked to one RequirementSet. And it would feel forced if you were to first put all those testcases in one and the same ExecutionList just to link them to the proper RequirementSet.
• Printing a report
• Make sure the view is set to the window you want to print
• Click 'print review'

Tosca Tips & Tricks: notes on TestCase Design module of TCP

Notes on Powerpoint Presentation by Tricentis as part of the 'TestCase Design' module of TCP:

• Testcase Design section elements (p.11)
• TestCase Design Folder => TestSheet => Attribute => Instance
• Attribute properties (p.12+)
• AttrType:
• Logical (grey top)
• Physical (red top / no coloured top)
• BusinessRelevant:
• No (white top)
• Yes (red top / no coloured top)
• Result (green top)
• Instance properties (p.15):
• Character (F7)
• Valid
• Invalid
• Straight Through
• Position (F8)
• Inner
• Boundary
• Equivalence class (p.16)
• Each representative produces the same error =>1 representative value per class
• Work because the same result is expected for each and every representative of the same class
• Equivalence Partitioning (p.17+)
• Boundary value errors are one-time errors and don't increase coverage (therefore: not part of regression)
• Floating attributes (numerical values)
• Non-floating attributes (enumeration of values)
• Avoid testing for all invalid values, only needed/requested ones
• Straight Through (p.27)
• It is the test case with the highest risk
• It is the test case which can be most easily implemented
• It is the test case which offers the best flexibility to be combined with the other attributes
• Standard TestSheet: subdivide attributes in:
• Preconditions
• The processes under test
• Verifications
• Linear Expansion
• One defined Straight Through
• One test focus per test case
• 
  

Notes on videos by Tricentis as part of the 'TestCase Design' module of TCP:

• First placeholder note
•  Arranging Instances (rightclick attribute => Arrange instances)
• Order: Straight through, Valid instances, Invalid instances, Boundary values
• Generating Instances
• Rightclick on attribute => Create instance (both in left- and right side of Tosca viewing screen - the latter even by just manually typing a new instance value in an attribute field)
• Combining attributes at a higher level
• Create Instance and delete the single empty instance at the desired combination level leaving only an Instance Folder
• Select the attributes to combine
• Rightclick the select instances -> Complete Instances -> Linear Expansion
• Instance Filter
• User the Filter column in the instance selection screen to select for particular attribute values
• Particularly handy when checking for reduntant testcases
• 'Reset Instance Filter' when done comparing
• Redundant testcases
• Just delete them
• Best Practices for Instances
• Naming: separate different aspects of an attribute value and/or instance with pipes
• Verification Attributes (green top)
•  (Often, always?) no need to create an instance at the top attribute (verifications are RESULTS of the instances, not instances themselves)
• Creating Instances on a Testsheet level
• Make sure the instances of the testsheets attributes (if any) are generated
• Rightclick -> Completed Instances -> Linear Expansion
•  Verifications will be ignored when it comes to the combinatorics
• Combinatorics
• Linear Expansion
• Contributions of an attribute with N instances to the total number of testcases of the instance above it: N-1 (with the '-1' being the straight through)
• Verifications
• Choose the value 'N/A' for verification attributes which are not relevant (such as error message for a valid instance or success messages for invalid ones).
• Best Practices
• Create one Testsheet per requirement
• TestCaseDesign vs. Requirements
• You can only drag-and-drop a Testsheet on a Leaf requirement and not on a branch requirement
• If a Testsheet is drag-and-dropped on a requirement a 'Testcase Substitute Link' is created for every Instance of the Testsheet (yellow circular arrow with red  ribbon)

Tosca Tips & Tricks: TCShell: 'Print options' popup while printing reports via TCShell

When printing reports via TCShell, for example via a command such as:
task "Print Report ... ExecutionEntries with ActualLog" "C:\\Reports\\ReportOfTestrun.pdf"
It might be that your run gets interrupted (and held up!) by a 'Print options' popup. To get around this and let your .tcs proceed past printing reports add the following to your TCShell.exe.config:

Add a new <section> within <configSections><sectionGroup>:
<configSections>
    <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="Tricentis.TCCore.Persistency.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
     <section name="Tricentis.TCAddIns.Reporting.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
   </sectionGroup>
  </configSections>

Add a new <setting> for this new <section> in the <userSettings>:
  <userSettings>
<Tricentis.TCAddIns.Reporting.Properties.Settings>
 <setting name="DefaultPrintOutputFormat" serializeAs="String">
        <value>ASKUSER</value>
      </setting>
 </Tricentis.TCAddIns.Reporting.Properties.Settings>
  </userSettings>

SHORT TERM GOAL

Since I'll be working rather intensively with Tosca in the foreseeable future and these days an inordinate amount of value is attributed to certifications: LET'S GET CERTIFIED!

Short term goal: Get 'Tosca Certified Professional'

Goal landmarks:

• Pass module 'TestCase Design'
• Pass module 'Manual Testing'
• Pass module 'Automated Testing (Cross Browser Testing)'

Goal deadline: Monday 7 September

Somewhere something went terribly wrong...

From my distant-in-the-past Bachelor degree in physics background I gathered some technical skills.

I took a job as a junior software tester at a bank.

I expected... Well, I'm not entirely sure anymore what it I expected.

But I definitely didn't expect what my job ended up being:

Manually clicking through websites.

A team of "functional" software testers all but one of which had never written a single line of code in their lives.

A super inefficient method of software development - which I later learnt is called 'waterfall'.

All software developers externally hired and offshore.

And these 'gods among men' delivered software with the most horrid bugs.

The "Have you even once tried this yourself?" kind of bugs.

The "Have you actually READ the requirements?" kind of bugs.

Somewhere something went terribly wrong...



It's been three years down the line and things have changed... a bit.

I completely shocked my entire team by developing a tiny tool which improved their quality of life a lot, which opened doors.

I somehow convinced my manager that we really needed test automation.

I am actually hired as the resident test automator.

We bought into a custom-built Selenium based test automation framework.

The project suffered gruesome and mutilating death in development.

We bought into Tosca as the test automation framework to use.

We have a Tosca Implementation Partner on site to help with the implementation.

Of course in many ways chaos still rules, but things seem not as terribly wrong as before.

Except for one thing: I am in need of acquiring a massive amount of knowledge in a variety of fields

And if it's all the same it would be nice if I acquired this knowledge yesterday.

And this blog will be the place where I log and keep track of my progress.