Management 3.0, Project Management, Research work

“Build the right software” with the “Need for speed” and “Do it the right way”.

I have always asked myself during the period of my studies: Are agile methodologies good for software projects? My answer is “Yes”, they are good but not enough. And then I asked myself why they are not enough? What I have seen in the last 10 years shows that just following the agile methodology does not solve all problems. Let’s take a closer look in the three fundamental goals of agile software development to move forward into the future mentioned in Michael Dubakov’s post “The future of agile development”. Every other company in the market wants to „Build the right software” which is also the ultimate goal to generate revenue by catering their users with what they want to see and use. Most of the companies following scrum methodology have done reasonably good and has also generated huge public interest. To understand the needs of its customers, they have created a feedback cycle where the customers are also involved directly or indirectly. These interactions with the customers provide valuable information and many of them are golden opportunities to improve.
The second goal which arises is „Do it the right way”. Often when you create the right software, the job is half done and if it is not done the right way your mission is not complete. Users might be able to solve their problems but with an in-stable software which might crash now and then. When software is poorly coded it is very ambiguous, it might look good on the user interface and also might prove helpful but a reality check could reveal it is a train-wreck which could rattle anytime.
Most of the software companies have already implemented a methodology with a goal to test ideas first and check its viability, which also highlighted the third goal of agile software development: “Need for speed”. Normally these test ideas are transformed into working software with very few unit tests and a lame architecture/framework in the need to launch the idea to a targeted audience as fast as possible and prove that the product concept is viable. Eventually, when the product concept works, the whole software block is rewritten right from scratch, keeping in mind the architecture, framework, scalability, and performance with lots of unit tests which might take a few more sprints. So this shows that „Do it the right way” is time-consuming and sometimes fails to catch up with the needs of the users.
When projects are getting complex, the speed drops due to the various factors attached to “Do it the right way” and this speed factor is very important for any competitive company. It is necessary to create software fast so that the firm can test the product concept and its viability. Once this is done the company gets a second chance to try various options to tune it to the user’s behavior and also “Do it the right way”. If a firm does slow work, there would be no second chance and probably would fall to the competition in the market.
Therefore, agile development process should “Build the right software” with the “Need for speed” and “Do it the right way”. Thus we have a development process with clear goals which should guarantee success (hypothetically). But the question that arises in my mind now is: How do we keep all these three goals in sync?

Representation of Agile Development Goals

The circles in the above figure depict how the three goals would overlap each other and also show some pros and cons. It also shows the ideal situation for software development. When “Build the right software” overlaps “Need for speed” without taking “Do it the right way” into consideration it would work for trying out new product concepts. But it would also mean putting off problems to a later date if the product concept is viable. This could be expensive at times.
When “Build the right software” overlaps “Do it the right way” without taking “Need for speed” into consideration it would mean that the company is likely to hit the jackpot if it has no competition. But the firm could completely miss out on market opportunities if the product concept is viable due to slow speed or the company would make huge losses if the product is not accepted in the market.
When “Do it the right way” overlaps “Need for speed” without taking “Build the right software” into consideration meaning the company will have a wrong product in the market which no one needs. The company could learn from the market reaction and understand what went wrong and make fast changes. Ideally, this situation should never happen if the product team has done its homework.

Uncategorized

Writing good tests (part 2) — Zooplus Tech Blog

Last time I just barely scratched the topic of writing test scenarios. I briefly gave only a few hints like “avoid unnecessary information”, “don’t include implementation details” or “don’t repeat yourself in different scenarios”. This time I’d like to dig deeper and present results of discussions we had in the team. Note: Like I mentioned…

via Writing good tests (part 2) — Zooplus Tech Blog

Uncategorized

Test data management and regulatory compliance

Test data management plays a crucial role in ensuring the success of testing any application. Most of us spend a lot of time searching for an accurate test data satisfying the test case pre-requirements. A pre-requisite before procuring test data, would be to sit down during the planning phase with the entire team and document all the scenarios that are to be covered during the course of the test execution. This would eliminate the chances of missing out on any critical/non-critical scenarios in the future. Test data may be contained in a database table or any kind of file or even spreadsheet. It can also be of any format for example xml test data, system test data or even SQL test data, etc. Generation of test data involves a sanity, accuracy and integrity check of the test data in all related database tables. This means before test case execution the existing data is extracted from the database and therefore edited or conditioned to fulfill the test case requirements. Test data can also be categorized to ensure complete functional test coverage. Testers can also be creative, use their own skill and judgments to create different data sets instead of relying on standard production data while testing.

Sensitive personal, financial, and health information are governed by a variety of industry and governmental data privacy regulations like PCI, HIPAA, GLBA and SOX. They should be considered by Project managers when deciding upon test data and test environment.  It is essential that organizations protect their applications and databases from business users, production teams, DBAs, developers, and offshore and outsourced test teams, while allowing them to do their jobs. Basic security measures like authentication, authorization, and access control are not good enough to meet these various requirements. Organizations should consider advanced security measures like data encryption, auditing, data masking and real time monitoring to ensure data privacy and protection. Payment Card Industry Data Security Standard (PCI DSS) mandates strong data security measures. The top four PCI requirements that need attention are:

Requirement 3: Protect stored cardholder data. Sensitive data wherever it may be production or non-production, off-line or on-line, on-site or off-site, disk, tapes or devices. Recommended approaches to protect databases include data masking for non-production, data-at-rest and data-in-motion encryption for production environments. (Requirements and Security Assessment Procedures, 2013)

Requirement 11: Regularly test security systems and processes. All organizations dealing with credit card numbers regularly test their systems from a data privacy point-of-view. Recommended approaches include auditing, monitoring, and encryption. (Requirements and Security Assessment Procedures, 2013)

Requirement 8: Assign a unique ID to each person with computer access. Therefore, some organizations need to consider integrating application users with database user to keep track of who accesses private data. Recommended approaches include auditing and monitoring of sessions across applications and databases. (Requirements and Security Assessment Procedures, 2013)

Requirement 10: Track and monitor all access to network resources and cardholder data. Only authorized users can access networks. In addition, cardholder data needs to be monitored based on who is accessing or changing such information. To meet PCI DSS requirements, organizations must take steps to ensure they are protecting cardholder data with controls such as data masking, encryption and monitoring. (Requirements and Security Assessment Procedures, 2013)

HIPAA mandates all patient records be protected in all environments. All protected health information (PHI)-related data residing on any database needs complete data protection. The key requirements from a database point of view are in Section: 164.308 for administrative safeguards and Section: 164.312 for technical safeguards. (Security Standards: Administrative Safeguards, 2007)

Research work, Uncategorized

Fuzzy logic ..Neural networks… aha… Expert System?

“Expert systems belong to field of Intelligent Knowledge –Based Systems that constitute one of the principal fields of activity of computational intelligence has also been referred to as the science that attempts to make computers perform tasks at which humans, for now at least, are better!”. The objective of an expert system is to permit a non-expert user to exploit the accumulate knowledge and experience of an expert in a specific field of expertise. 

Knowledge-based expert systems use rules, data, events, simple logic and other forms of search techniques to arrive at decisions. Where an element of knowledge is missing then the expert system cannot but return a “don’t know” response, implying an inability to arrive at decision. An expert system cannot extrapolate data and infer from similar or adjacent knowledge.

When uncertainty and vagueness characterize the plant and its measurements, then such knowledge-based expert systems are not always able to arrive at a decisions  and are consequently unacceptable for real-time control purposes. It would be extremely frustrating to receive a “don’t know” or a conflicting decision in the case of an unforeseen emergency when immediate action is needed. In situations of uncertainty and vagueness, more effective mechanisms, capable of inferring decisions from incomplete data, are necessary. Fuzzy logic and artificial neural networks and their hybrids are the primary examples of techniques that posses appropriate mechanisms to deal with uncertainty and vagueness.

Zadeh has noted that for many complex processes a “high level of precision is not possible or even necessary in order to provide acceptable control”. This is a pivotal concept in computational intelligence and forms the basis of unconventional control. Fuzzy logic, which in no way replaces probability theory, is the underlying theory for dealing with approximate reasoning in uncertain situations where truth is the matter of degree.

Rules form the basis for this fuzzy expert system to obtain fuzzy output. The rules in the fuzzy expert system originates from sources other than that of human experts and hence are different from other expert systems. These rules in the fuzzy expert system can be further optimized by using evolutionary algorithms which has generated considerable interest and excitement in the engineering community and is one of the ascending fields of control engineering. The technique can yield solutions to optimization problems that cannot be solved otherwise, issues concerning the best form of fuzzy sets to use in a fuzzy rule-based system are now being sought using evolutionary optimization technique. 

lazy code, Software QA, Uncategorized

Commonly Used Webdriver (Selenium 2) Commands for UI testing

Recently i moved from #.Net to Java for Functional UI testing and in this post you would find all the commonly used selenium/webdriver commands that i used in my test code.

Drag and Drop action

WebElement element = driver.findElement(By.name(“source”));
WebElement target = driver.findElement(By.name(“target”));
(new Actions(driver)).dragAndDrop(element, target).perform();

Keyboard key using Action builder class

Actions builder = new Actions(driver);
builder.keyDown(Keys.CONTROL).click(someElement).click(someOtherElement).keyUp(Keys.CONTROL).build().perform();

Deleting all Cookies 

 driver.manage().deleteAllCookies();

IsElementPresent/Text Present 

isElementPresent(WebDriver driver, By by)
try{
driver.findElement(by);
return true;
}
catch(Exception e)
{
return false;
}
}

(OR using size of TEXT)

if(driver.findElements(Locator).size()>0
{
return true
}else
{
return false
}
}

(OR using PageSource)

driver.PageSource.Contains(“TEXT”);

Inserting string

public static void insertText(WebDriver driver, By locator, String value) {
WebElement field = driver.findElement(locator);
field.clear();
field.sendKeys(value);
}

Reading ToolTip text 

public static String tooltipText(WebDriver driver, By locator){
String tooltip = driver.findElement(locator).getAttribute(“title”);
return tooltip;
}

Selecting Radio Button

public static void selectRadioButton(WebDriver driver, By locator, String value){ List select = driver.findElements(locator);
for (WebElement element : select)
{
if (element.getAttribute(“value”).equalsIgnoreCase(value)){
element.click();
}
}

Selecting CheckBox

public static void selectCheckboxes(WebDriver driver, By locator,String value)
{
List abc = driver.findElements(locator);
List list = new ArrayListArrays.asList(value.split(“,”)));
for (String check : list){
for (WebElement chk : abc){
if(chk.getAttribute(“value”).equalsIgnoreCase(check)){
chk.click();
}}}}

Selecting Dropdown

public static void selectDropdown(WebDriver driver, By locator, String value){
new Select (driver.findElement(locator)).selectByVisibleText(value); }

Selecting searched dropdown

public static void selectSearchDropdown(WebDriver driver, By locator, String value){
driver.findElement(locator).click();
driver.findElement(locator).sendKeys(value);
driver.findElement(locator).sendKeys(Keys.TAB);
}

Uploading file

public static void uploadFile(WebDriver driver, By locator, String path){
driver.findElement(locator).sendKeys(path);
}

Downloading file 

public static void downloadFile(String href, String fileName) throws Exception{
URL url = null;
URLConnection con = null;
int i;
url = new URL(href);
con = url.openConnection();
//  specifying the location to save the file.
File file = new File(“.//OutputData//” + fileName);
BufferedInputStream bis = new BufferedInputStream(con.getInputStream());
BufferedOutputStream bos = new BufferedOutputStream(
new FileOutputStream(file));
while ((i = bis.read()) != -1) {
bos.write(i);
}
bos.flush();
bis.close();
}

Implicit Wait

driver.manage.timeouts().implicitlyWait(10,TimeUnit.SECONDS);

Explicit Wait

WebDriverWait wait = new WebDriverWait(driver,10);
wait.until(ExpectedConditons.elementToBeClickable(By.id/xpath/name(“locator”));

Sleep 

Thread.sleep(time in milisecond)

 Page Navigation 

driver.navigate().to(Url);

Page Back

driver.navigate().back();

Browser Page Forward

driver.navigate().forward();

Page Refresh

driver.navigate().refresh();

 

 

 

 

 

Project Management, Software QA

Session Based Testing: A feasible solution for performing exploratory testing

Exploratory testing is a type of manual testing method where software is tested without a set of tests defined in advance. During an exploratory test session, you are not restricted to a script or a set of predetermined steps. When a QA engineer just goes Ad-hoc into exploratory testing without following any structure, it is very difficult to quantify what work was done, what parts of the software were tested and how much time was actually spent testing.

survey

Session Based Testing (SBT) is a framework that supports exploratory testing. From the semi-structured interviews that I performed I came to know that QA engineers where performing a lot of exploratory testing during the sprint but where not using SBT. This was also evident from the survey performed where about 80% of all the respondents including QA engineers and the team members working with QA engineers answered “No” to the question: Do you use Session based testing?
SBT framework helps bridle the randomness around exploratory testing without compromising on the methodology involved in exploratory testing. It also overcomes major issues involved with exploratory testing like a lack of structure that provides no visibility on the progress made with exploratory testing and test coverage achieved with it (Saxena, 2012).

Basic Elements of Session Based Testing

Charter

is the goal or agenda associated with the test session.

Session

is an un-interpreted period of time spent often time boxed to less than 2 hours.

Session Report

is a record of the time boxed test session containing the charter, area covered, how testing was conducted, list of bugs, risks and issues found, documentation of data files the tester used or created during the session, percentage of time the tester spent on the session vs. investigating new issues, session start time and duration etc. the session report can contain more information if required and can be customized to the needs of the project.

Debrief

is a short discussion between the Product Owner and the QA engineer about the session report.

Parsing Results

in exploratory testing using SBT is performed with a standardized session report. This report can be parsed with a software tool like Microsoft Excel to store results as aggregated data for reporting and metrics.

Planning

with the help of SBT, QA engineers can plan test sessions to fit the needs of the project. Charters can be added or dropped based on tests executed and changing requirements. (Saxena, 2012)

Representation of Session Report
Representation of Session Report

Proposed Usage of Session Based Testing (SBT)

SBT is a feasible solution for performing exploratory testing. Managers in the company like to see metrics because they like to see progress in the project. Using SBT, QA engineers would be able to provide this metric on testing efforts to the managers.There are several tools in the market that can assist SBT. I have also tried to perform a proof of concept with an open source tool called “sessionweb”. But the most feasible tools for a #.Net company could be “Microsoft Test Manager” or “Bonfire” also known as “Jira-Capture” which is an add-on for “Jira”. Both the tools were already available in the company I work. “Jira” is already used as a project tracker in the company and all the QA engineers have Microsoft Visual Studio installed in their standalone machines with which “Microsoft Test Manager” is pre-installed. Seeing the benefits of structured exploratory testing with the usage of “Session Based Testing” it is proposed as a feasible solution.

lazy code

Capture Screenshot with PhantomJS for RWD test

Here is a little script that could be used to capture screenshots for a responsive webpages with different view-ports and save them as *.png


var async = require('async'),
sizes = [
[320, 480],
[320, 568],
[600, 1024],
[1024, 768],
[1280, 800],
[1440, 900]
];


function capture(sizes, callback) {
var page = require('webpage').create();
page.viewportSize = {
width: sizes[0],
height: sizes[1]
};


page.zoomFactor = 1;
page.open('http://werkstatt.autoscout24.de', function (status) {
var filename = sizes[0] + 'x' + sizes[1] + '.png';
page.render('./screenshots/' + filename);
page.close();
callback.apply();
});
}


async.eachSeries(sizes, capture, function (e) {
if (e) console.log(e);
console.log('Captured');
phantom.exit();
});

Have fun

Management 3.0, Project Management

Behavior Driven Development with 3 Amigo’s task

In Scrum, a story is presented in planning with a story template that would look like:

As a [X]

I want [Y]

So that [Z]

This can be elaborated as the following, the person or the role “X” wants to have a feature “Y” so that he/she could be benefited by “Z”. But this could often lead to misunderstanding as depicted in figure below:

Representation of Communication Gap in a Story Grooming Meeting
Representation of Communication Gap in a Story Grooming Meeting

Everybody in the team could have a different understanding of the story being presented in the sprint planning and could de-scope some of the more esoteric requirements (North, 2006). This misunderstanding could be avoided with the help of sketches which could be presented in the sprint planning as depicted in figure below.

But a more feasible solution to this situation would be the use of a domain specific language (DSL). Every QA engineer knows that a story’s behavior is simply its acceptance criteria and if the system fulfills all acceptance criteria, then the system behaves correctly or vice versa. Therefore a QA engineer needs a template to capture a story’s acceptance criteria which could be done with Behavior Driven Development (BDD). (North, 2006)

Representation of Good Communication with Sketches
Representation of Good Communication with Sketches

BDD is usually done in DSL a very English-like language that helps the domain experts to understand the implementation rather than exposing the code level tests. It is defined in a GWT format, GIVEN WHEN & THEN (What is TDD, BDD & ATDD ?, 2012). The BDD template is loose and structured enough so that it could break the story into different scenarios based on its acceptance criteria. A scenario template would look like:

Given some initial context (the givens),

When an event occurs,

Then ensure some outcomes.

The QA engineer could develop these scenarios from acceptance criteria in collaboration with the Product Manager/Owner. The scenarios with “given”, “when an event”, “then an outcome” are fine-grained enough to be represented directly in the code. The QA engineer could collaborate with the developer to represent these scenarios in the code which would then be part of the acceptance test for the story. A simple representation of the scenarios in coded form would look like:

public class someinitialcontext implements Given {
public void setup(Someinitialcontextsomeinitialcontext) {
...
}
}


public class aneventoccurs implements When {
public void setup(Aneventanevent) {
...
}
}


public class ensuresomeoutcomes implements Then {
public void setup(Outcome outcome) {
...
}
}

Test Driven Development (TDD)
Test Driven Development (TDD)

BDD is test driven development (TDD) in many ways except that the word “test” is replaced by the word “Behavior” and is meant for a broader audience which include Product Owners and stakeholders. In both the methods of software development, the tests are written upfront and made executable, then implementation of a unit is done and finally the implementation of the unit is verified by making the test successful.

Implementation of 3 Amigo’s Task

The decision to implement the 3 Amigo’s task solely depends on the team if they want it. In my case the Scrum team wanted to try something new in the field of testing. The following process evolved which was loosely based on the  “Introducing the Three Amigos” by Ryan Thomas Hewitt. It was accepted as a sprint task and was defined and adopted by the Scrum team. The “3 Amigo’s” were the Product Managers/BA’s, the QA engineer, and a developer who collaborated together to define the scenarios from the acceptance criteria for a story.

Steps involved in 3 Amigo’s:

  • For every new story a task “3 Amigo’s” is defined in the sprint planning meeting.
  • “3 Amigo’s” task is considered to be the first task for every story in the sprint.
  • Immediately after planning the Product Owner, the QA engineer, and a developer create a meeting and collaborated together to define the scenarios.
  • The scenarios are represented as code by a pair of developers or a developer-QA engineer pair.
  • Development of the code is started parallel to or after the implementation of scenarios as executable acceptance test.

Advantages of Performing 3 Amigo’s Task:

  • Performing “3 Amigo’s” task within the sprint showed high level of collaboration between the three parties involved in the sprint: the Product Owner/Manager/BA, Developers and the QA engineer.
  • Performing this task also means that the acceptance tests were written and automated even before coding started.
  • The scenarios where written in Domain Specific Language (DSL), which means everybody in the team could understand the scenarios and no coding skills were required.
  • The QA engineer had more time performing exploratory test as story acceptance test was already automated.
  • The story was accepted automatically when all acceptance tests represented as scenarios were successful.
  • “3 Amigo’s” task could be a pre-planning task, where the QA engineer could collaborate with the Product Manager/BA and define scenarios for each acceptance criteria.
  • The scenarios could be presented directly in the sprint planning meeting to the whole team.

Future Experimental Work

  • “3 Amigo’s” task could be a pre-planning task, where the QA engineer could collaborate with the Product Manager and define scenarios for each acceptance criteria.
  • The scenarios could be presented directly in the sprint planning meeting to the whole team.