CTAL - TA Cheat Sheet (Part 1)

V-Model

• System test planning occurs concurrently with project planning, and test control continues until system test execution and closure are complete. 
• System test analysis and design occur concurrently with requirements specification, system and architectural (high-level) design specification, and component (low-level) design specification. 
• System test environment (e.g., test beds, test rig) implementation might start during system design, though the bulk of it typically would occur concurrently with coding and component test, with work on system test implementation activities stretching often until just days before the start of system test execution. 
• System test execution begins when the system test entry criteria are all met (or waived), which typically means that at least component testing and often also component integration testing are complete. System test execution continues until the system test exit criteria are met. 
• Evaluation of system test exit criteria and reporting of system test results occur throughout system test execution, generally with greater frequency and urgency as project deadlines approach. 
• System test closure activities occur after the system test exit criteria are met and system test execution is declared complete, though they can sometimes be delayed until after acceptance testing is over and all project activities are finished. 

Involvement during Test Plan creation along with Test Manager:

• Be sure the test plans are not limited to functional testing. All types of testing should be considered in the test plan and scheduled accordingly. For example, in addition to functional testing, the Test Analyst may be responsible for usability testing. That type of testing must also be covered in a test plan document. 
• Review the test estimates with the Test Manager and ensure adequate time is budgeted for the procurement and validation of the testing environment. 
• Plan for configuration testing. If multiple types of processors, operating systems, virtual machines, browsers, and various peripherals can be combined into many possible configurations, plan to apply testing techniques that will provide adequate coverage of these combinations. 
• Plan to test the documentation. Users are provided with the software and with documentation. The documentation must be accurate to be effective. The Test Analyst must allocate time to verify the documentation and may need to work with the technical writing staff to help prepare data to be used for screen shots and video clips. 
• Plan to test the installation procedures. Installation procedures, as well as backup and restore procedures, must be tested sufficiently. These procedures can be more critical than the software; if the software cannot be installed, it will not be used at all. This can be difficult to plan since the Test Analyst is often doing the initial testing on a system that has been pre-configured without the final installation processes in place. 
• Plan the testing to align with the software lifecycle. Sequential execution of tasks does not fit into most schedules. Many tasks often need to be performed (at least partly) concurrently. The Test Analyst must be aware of the selected lifecycle and the expectations for involvement during the design, development and implementation of the software. This also includes allocating time for confirmation and regression testing. 
• Allow adequate time for identifying and analysing risks with the cross-functional team. Although usually not responsible for organising the risk management sessions, the Test Analyst should expect to be involved actively in these activities. 

Quantitative data - 

percentage of planning activities completed, percentage of coverage attained, number of test cases that have passed, failed.

After test planning TA uses scope definition to:

• Analyze the test basis 
• Identify the test conditions 

Entry criteria for test analysis:

• There is a document describing the test object that can serve as the test basis 
• This document has passed review with reasonable results and has been updated as needed after the review 
• There is a reasonable budget and schedule available to accomplish the remaining testing work for this test object 

Test conditions are typically identified by analysis of the test basis and the test objectives. 

Standard considerations about test conditions for TA:

• It is usually advisable to define test conditions at differing levels of detail. Initially, high-level conditions are identified to define general targets for testing, such as “functionality of screen x”. Subsequently, more detailed conditions are identified as the basis of specific test cases, such as “screen x rejects an account number that is one digit short of the correct length”. Using this type of hierarchical approach to defining test conditions can help to ensure the coverage is sufficient for the high-level items. 
• If product risks have been defined, then the test conditions that will be necessary to address each product risk must be identified and traced back to that risk item. 

The process of test design includes the following activities: 

• Determine in which test areas low-level (concrete) or high-level (logical) test cases are most appropriate 
• Determine the test case design technique(s) that provide the necessary test coverage 
• Create test cases that exercise the identified test conditions 

When designing tests, it is important to remember the following: 

• Some test items are better addressed by defining only the test conditions rather than going further into defining scripted tests. In this case, the test conditions should be defined to be used as a guide for the unscripted testing. 
• The pass/fail criteria should be clearly identified. 
• Tests should be designed to be understandable by other testers, not just the author. If the author is not the person who executes the test, other testers will need to read and understand previously specified tests in order to understand the test objectives and the relative importance of the test. 
• Tests must also be understandable by other stakeholders such as developers, who will review the tests, and auditors, who may have to approve the tests. 
• Tests should be designed to cover all the interactions of the software with the actors (e.g., end users, other systems), not just the interactions that occur through the user-visible interface. Inter-process communications, batch execution and other interrupts also interact with the software and can contain defects so the Test Analyst must design tests to mitigate these risks. 
• Tests should be designed to test the interfaces between the various test objects. 

Test case design includes the identification of the following: 

• Objective 
• Preconditions, such as either project or localized test environment requirements and the plans for their delivery, state of the system, etc. 
• Test data requirements (both input data for the test case as well as data that must exist in the system for the test case to be executed) 
• Expected results 
• Post-conditions, such as affected data, state of the system, triggers for subsequent processing, etc. 

Test work products (created during Test Design) might be affected by:

• Project risks (what must/must not be documented) 
• The “value added” which the documentation brings to the project 
• Standards to be followed and/or regulations to be met 
• Lifecycle model used (e.g., an Agile approach aims for “just enough” documentation) 
• The requirement for traceability from the test basis through test analysis and design 

Test implementation 

includes creating automated tests, organizing tests (both manual and automated) into execution order, finalizing test data and test environments, and forming a test execution schedule, including resource allocation, to enable test case execution to begin. This also includes checking against explicit and implicit entry criteria for the test level in question and ensuring that the exit criteria for the previous steps in the process have been met. 

Five primary dimensions in which test progress is monitored:

• Product (quality) risks 
• Defects 
• Tests 
• Coverage 
• Confidence 

Test case information can include: 

• Test case creation status (e.g., designed, reviewed) 
• Test case execution status (e.g., passed, failed, blocked, skipped) 
• Test case execution information (e.g., date and time, tester name, data used) 
• Test case execution artefacts (e.g., screen shots, accompanying logs)

The Test Analyst should be actively involved in the following risk-based testing tasks: 

• Risk identification 
• Risk assessment 
• Risk mitigation 

Sample risks that might be identified in a project include: 

• Accuracy issues with the software functionality, e.g., incorrect calculations 
• Usability issues, e.g., insufficient keyboard shortcuts 
• Learnability issues, e.g., lack of instructions for the user at key decision points 

Factors influencing business risk include: 

• Frequency of use of the affected feature 
• Business loss 
• Potential financial, ecological or social losses or liability 
• Civil or criminal legal sanctions 
• Safety concerns 
• Fines, loss of license 
• Lack of reasonable workarounds 
• Visibility of the feature 
• Visibility of failure leading to negative publicity and potential image damage 
• Loss of customers 

During the project, Test Analysts should seek to do the following: 

• Reduce product risk by using well-designed test cases that demonstrate unambiguously whether test items pass or fail, and by participating in reviews of software artifacts such as requirements, designs, and user documentation 
• Implement appropriate risk mitigation activities identified in the test strategy and test plan 
• Re-evaluate known risks based on additional information gathered as the project unfolds, adjusting likelihood, impact, or both, as appropriate 
• Recognize new risks identified by information obtained during testing 

Each future planned test cycle should be subjected to new risk analysis to take into account such factors as: 

• Any new or significantly changed product risks 
• Unstable or defect-prone areas discovered during the testing 
• Risks from fixed defects 
• Typical defects found during testing 
• Areas that have been under-tested (low test coverage) 

Working with ZIP in terminal

Couple of days ago wanted to use ZIP in OSX terminal and realised that I don't have examples really (yes U can check manuals etc.) so I've decided just to note most common / usable ones:

- zip --encrypt file.zip files - will create an encrypted zip archive (files won't be removed automatically after compressing);

- zip -r archive.zip directoryName - will compress whole directory at once. U can add --encrypt flag here as well

- unzip file.zip - extracts file from archive into current directory

That's it for now although most likely will have to add more later on.

Working with zipfile module Python

Memo related to zipfile module and most common methods from this module.

import zipfile

compressedFile = zipfile.ZipFile('test.zip')

compressedFile.namelist() - returns list of files and directories in archive

fileInfo = compressedFile.getinfo('file') - returns information about file in archive

fileInfo.file_size - returns size of the file

fileInfo.compress_size - returns compression ratio

compressedFile.extractall() - extracts everything from zip into current directory

compressedFile.extractall(path) - extracts everything from zip to destination directory

compressedFile.extract('file', path) - extracts exact file from zip to destination path


newZip = zipfile.ZipFile('test.zip', 'w')
newZip.write('test.txt', compress_type=zipfile.ZIP_DEFLATED)
newZip.close() - adding file to archive however this will overrides all archive

zipfile.ZipFile('test.zip', 'a') - adding file to archive without overriding 

Working with files in Python (part 2) - shutil, move2trash, os

In this memo I'll save some common methods related to shutil, move2trash modules and some more from os module.

shutil.

import shutil

shutil.copy('source', 'destination') - copies file or directory

shutil.copytree('source', 'destination') - copies directory with all subdirectories & files

shutil.move('source', 'destination') - moves file or directory

shutil.remtree(path) - remove directory with all subdirectories

send2trash.

import send2trash

send2trash.send2trash(path) - moves file or directory to the bin

os.

import os

os.walk(path) - returns list of all directories, subdirectories and files

os.unlink(path) - permanently deletes file

os.rmdir(path) - permanently removes directory

Working with files in Python

Some notes about working with files in Python.

How simply generate path:

import os
os.path.join('usr', 'user', 'Documents')

or if we need path to file:

os.path.join('home/Documents/work', important.txt)

os.getcwd() - check current directory

os.chdir('path to new working directory') - change directory

os.makedirs('home/docs/test') - create directory

os.path.abspath('path') - get absolute path

os.path.relpath('path', 'start point') - get relative path

os.path.dirname('path') - get directory name actually will return name with whole path

os.path.basename('path') - get file name

os.path.split('path') - to get both directory name and file name as a tuple

or 

examplePath.split(os.path.sep) - will return tuple where every directory and file name are separate strings (in OSX first item in the list will be '')

os.path.listdir('path') - list all items in the directory

os.path.getsize('path') - get file size in bytes

os.path.exists('path') - returns True if directory or file exists

os.path.isfile('path') - returns True if file exists

os.path.isdir('path') - returns True if directory exists

open('path') - returns file object if there's no such file Python will create that

read('path') or open('path', 'r')- reads file

file.readlines() - reads line by line from file

write('path') or open('path', 'w')- writes to file (simple usage will overwrite all content)

open('path', 'a') - will append text to the end of the file instead of overwriting

close('path') - closes file


Work with binary shelf files (can be used as dictionaries etc.):

import shelve
testFile = shelve.open('filename')
testValues = ['email', 'address', 'phone']
testFile['data'] = testValues
testFile.close()

testFile('data') - prints out values

list(testFile.keys()) - prints list of keys in our case it will be just 'data'

list(testFile.values()) - prints list of values ie ['email', 'address', 'phone']

import pprint
pprint.pformat(list) - will represent list / dictionary as a string for easier saving that to a file

And for the end short reminder about shelf files and plain text files: first used mostly for complex objects (ie file objects) while plain text files can be used for storing simple data (ie text, integers etc)

Regex rules for Python...

Something to keep in mind about Regex.

? - matches zero or one of the preceding group
* - matches zero or more of the preceding group
+ - matches one or more of the preceding group
{n} - matches exactly n of the preceding group
{n,} - matches n or more of the preceding group 
{,m} - matches 0 to m of the preceding group 
{n,m} - matches at least n and at most m of the preceding group
{n,m}? or *? or +? - performs a nongreedy match of the preceding group 
^spam - means the string must begin with spam
spam$ - means the string must end with spam
. - matches any character, except newline characters
\d, \w and \s - match a digit, word, or space character
\D, \W and \S - match anything except a digit, word or space character
[abc] - matches any character between the brackets
[^abc] - matches any character that isn't between brackets


In order to use  package re should be imported after that compile method can be invoked:

regex = re.compile(r'spam')

Some useful methods:

regex.search('abc') - returns first occurrence of matched pattern
regex.group(1) - returns first group in case of multiple of those ie re.compile(r'(\d\d)-(\d\d\d))
regex.group() - returns the entire matched text
regex.groups() - returns tuple of multiple values
regex.findall() - returns the strings of every match in the searched string ie list of strings if there's more than 1 match
regex.sub() - takes two arguments: first string for replacement and second string where to replace (in case of match) ie regex.sub(r'abc', 'abc is the most popular shortcut')

List is not complete and I will try to add some more examples later...

Math calculation with Bash in OSX

There are quite a few options how to calculate with Bash in OSX terminal but for reference I'd like to mention just several of them which can be used as a baseline.

echo "2 * 2" | bc

echo "scale=3; 1000/52 | bc" - will output result + 3 digits after comma

bc <<< "100 / 3"

bc -l <<< "sqrt(5)" (scale(3.3) - number of digits after comma, length(100) - number of digits)

awk "BEGIN {print 33 * 33}"